headers
marcelo bagnulo braun | 1 Jun 2007 17:42
Picon

SeND & CGA Extensions BOF

Hi,

we have proposed a BOF on SeND and CGA extensions for the Chicago IETF. 
I attach the proposed charter below. There is a mailing list created 
for the discussion (https://www1.ietf.org/mailman/listinfo/cga-ext)

If you have comments about the proposed work, it would be appreciated.

Thanks, marcelo

Proposed charter for SeND & CGA Extensions BOF

Secure Neighbour Discovery (SeND) protocol as defined in RFC 3971
provides the security mechanisms to protecting the different
functions performed by the Neighbour Discovery (ND) protocol,
including the discovery of other nodes on the link and their
link-layer addresses, router discovery and reachability detection
for the paths to active neighbors. However, current SeND
specification lacks of support for ND Proxies as defined in
RFC 4389. The SeND protocol relies on the usage of
Cryptographically GEnerated Addresses (CGAs) to provide some of
these functions, in particular to provide IPv6 address ownership
proof to the other nodes on the link and authenticate node related
information of the ND protocol. CGAs are defined in RFC 3972 which
has been recently updated by RFC 4581 to define the CGA extension
format and by RFC-to-be draft-bagnulo-multiple-hash-cga-03.txt to
support multiple hash functions. While CGAs were originally
defined for the SeND protocol, they have proved to be a useful
security tool in other environments too, and its usage has been
proposed to secure other protocols such as the Shim6 multihoming
(Continue reading)

Permalink | Reply | 36 comments |
headers
Markus Stenberg | 4 Jun 2007 03:41
Picon
Favicon

Re: SeND & CGA Extensions BOF

Disclaimer: I mostly agree with the need for extra SeND/CGA work;  
these comments are the delta that I do not agree with :)

On 2.6.2007, at 0.42, marcelo bagnulo braun wrote:
> - Extensions to the IKEv2 protocol to create IPSec SAs associated to
> the CGA key. Because of their cryptographic nature, CGAs are
> inherently bound to the key pair that was used for their generation.
> This is used in existent protocols for proving address ownership.
> However, it would be possible also to use this cryptographic material
> to create a security association between peers. The key benefit of
> such approach is that it allows the creation of a security association
> that is cryptographically bound to the IP address of the end points
> without dependence on a common trust anchor point, eg. PKI. Such
> approach would provide additional protection compared to the
> opportunistic approaches. The proposed work will produce an analysis
> of this type of solution and the required extensions to CGAs and to
> the IKEv2 protocol in order to be able to create IPSec SA using the
> CGAs keys.

Maybe it is just a matter of wording, but the additional protection  
compared to opportunistic approaches seems slim to me. Certainly, you  
have CGA-IP as bound entity as opposed to someone on return-routing  
path, but you still don't have faintest idea who is using the IP. And  
I thought that (for most part) security authorization issues required  
something concrete to be identified (whether it is a machine, or user  
of the machine), and not just 'oh, he went through CGA process to get  
that IP'.

> - DHCP support for CGAs. An analysis of possible approaches to allow
> the usage of the DHCP protocol to assign CGAs will be produced. The
(Continue reading)

Permalink | Reply | 23 comments |
headers
marcelo bagnulo braun | 4 Jun 2007 12:25
Picon

Re: SeND & CGA Extensions BOF

Hi Markus,

thanks for your comments, see reply below...

El 04/06/2007, a las 3:41, Markus Stenberg escribió:

> Disclaimer: I mostly agree with the need for extra SeND/CGA work; 
> these comments are the delta that I do not agree with :)
>

great

do you think of any additional work that do you think would be 
interesting to work on and that has not been included in the proposed 
charter?

> On 2.6.2007, at 0.42, marcelo bagnulo braun wrote:
>> - Extensions to the IKEv2 protocol to create IPSec SAs associated to
>> the CGA key. Because of their cryptographic nature, CGAs are
>> inherently bound to the key pair that was used for their generation.
>> This is used in existent protocols for proving address ownership.
>> However, it would be possible also to use this cryptographic material
>> to create a security association between peers. The key benefit of
>> such approach is that it allows the creation of a security association
>> that is cryptographically bound to the IP address of the end points
>> without dependence on a common trust anchor point, eg. PKI. Such
>> approach would provide additional protection compared to the
>> opportunistic approaches. The proposed work will produce an analysis
>> of this type of solution and the required extensions to CGAs and to
>> the IKEv2 protocol in order to be able to create IPSec SA using the
(Continue reading)

Permalink | Reply | 15 comments |
headers
Stig Venaas | 4 Jun 2007 12:51
Picon
Picon

Re: SeND & CGA Extensions BOF

marcelo bagnulo braun wrote:
[...]
>>> - DHCP support for CGAs. An analysis of possible approaches to allow
>>> the usage of the DHCP protocol to assign CGAs will be produced. The
>>> output of the analysis will be an informational document describing
>>> the recommended approaches that will be provided as an input to the
>>> DHC working group where the actual DHCP extensions needed for the
>>> recommended approaches will be defined.
>>
>> DHCP and security shouldn't be mixed
> 
> not sure what do you mean here, but considering that CGAs are addresses
> and that CGAs are used for security and that some folks may want to use
> dhcp for configuring CGAs, then it seems that there should be some
> relation here...
> 
>>  - for laughs, look at the current DHCPv6.. It basically assumes that
>> all network links DHCPv6 is used on are trusted,
> 
> that may be a reasonable assumption when current parameters are
> configured, but probably this is not a valid assumption when we want to
> configure cgas which will be used for security purposes, i guess
> 
>>  and effectively due to that anyone on the server-relay, or
>> relay-client legs could 'acquire' the CGA information if you really
>> pushed the address+key tuple that way.
> 
> this is certainly a model, but it is not the only one.
> 
> I mean, it really depends what are the motivations for using dhcp and
(Continue reading)

Permalink | Reply | 11 comments |
headers
Markus Stenberg | 4 Jun 2007 13:08
Picon
Favicon

Re: SeND & CGA Extensions BOF

On 4.6.2007, at 19.25, marcelo bagnulo braun wrote:
>> Maybe it is just a matter of wording, but the additional  
>> protection compared to opportunistic approaches seems slim to me.  
>> Certainly, you have CGA-IP as bound entity as opposed to someone  
>> on return-routing path, but you still don't have faintest idea who  
>> is using the IP. And I thought that (for most part) security  
>> authorization issues required something concrete to be identified  
>> (whether it is a machine, or user of the machine), and not just  
>> 'oh, he went through CGA process to get that IP'.
> but, the IP address is the identity at the IP level, right?
> I mean, from an architectural point of view, at the IP level what  
> is needed is to be certain of the identity of the peer at the IP  
> level. So using the CGAs would exactly provide that, an SA bound to  
> the IP level identity. This would suppress the leap of faith that  
> is needed in the opportunistic mode. I mean there are a number of  
> processes and security filters, ACL, that run based on IP addresses  
> because of this reason, so making certain that the peer is actually  
> the owner of the IP address it is claiming to, would provide trust  
> to this applications. It may well be the case that additional trust  
> is needed because additional information is needed. But building a  
> generic any to any trust model that requires no pre arrangement  
> (global PKI or shared secret) is a very complex task, and i think  
> this is a significant step on this direction. I mean, nowadays, or  
> either a global PKI is assumed or all you have is the opportunistic  
> mode with the leap of faith. This work would take a step further in  
> the deployment of this general any to any trust relations with no  
> pre arrangement with an extremely reduced cost. I mean, i would  
> expect that the changes required to support this are slim, minor  
> extensions to the IKE protocol and the output is the elimination of  
> the leap of faith in the opportunistic mode.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fred Baker | 4 Jun 2007 14:29
Picon
Favicon

Re: SeND & CGA Extensions BOF


On Jun 1, 2007, at 11:42 AM, marcelo bagnulo braun wrote:

> we have proposed a BOF on SeND and CGA extensions for the Chicago  
> IETF. I attach the proposed charter below. There is a mailing list  
> created for the discussion (https://www1.ietf.org/mailman/listinfo/ 
> cga-ext)

The SAVA BOF is bringing up another issue, that of source address  
validation. In theory, using SAA one could open a new address for  
each TCP session on a web client; more realistically, someone  
concerned enough to do such things would probably change their  
address once a minute and use the address for all TCP sessions  
started in that minute even if they lapped into a subsequent one. But  
if the first hop router is going to verify that the MAC Address and  
the IPv6 source address are those of the same machine, SeND or  
something like it is going to have to be used to notify the router of  
the changing mapping (else it is just an attack vector), or the  
router is going to put a stop to it pretty quickly.

It would be nice to verify that we can handle this with SeND, and  
make whatever adjustments are required.
Permalink | Reply | 7 comments |
headers
marcelo bagnulo braun | 4 Jun 2007 17:09
Picon

Re: SeND & CGA Extensions BOF


El 04/06/2007, a las 13:08, Markus Stenberg escribió:

> On 4.6.2007, at 19.25, marcelo bagnulo braun wrote:
>>> Maybe it is just a matter of wording, but the additional protection 
>>> compared to opportunistic approaches seems slim to me. Certainly, 
>>> you have CGA-IP as bound entity as opposed to someone on 
>>> return-routing path, but you still don't have faintest idea who is 
>>> using the IP. And I thought that (for most part) security 
>>> authorization issues required something concrete to be identified 
>>> (whether it is a machine, or user of the machine), and not just 'oh, 
>>> he went through CGA process to get that IP'.
>> but, the IP address is the identity at the IP level, right?
>> I mean, from an architectural point of view, at the IP level what is 
>> needed is to be certain of the identity of the peer at the IP level. 
>> So using the CGAs would exactly provide that, an SA bound to the IP 
>> level identity. This would suppress the leap of faith that is needed 
>> in the opportunistic mode. I mean there are a number of processes and 
>> security filters, ACL, that run based on IP addresses because of this 
>> reason, so making certain that the peer is actually the owner of the 
>> IP address it is claiming to, would provide trust to this 
>> applications. It may well be the case that additional trust is needed 
>> because additional information is needed. But building a generic any 
>> to any trust model that requires no pre arrangement (global PKI or 
>> shared secret) is a very complex task, and i think this is a 
>> significant step on this direction. I mean, nowadays, or either a 
>> global PKI is assumed or all you have is the opportunistic mode with 
>> the leap of faith. This work would take a step further in the 
>> deployment of this general any to any trust relations with no pre 
>> arrangement with an extremely reduced cost. I mean, i would expect
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 4 Jun 2007 17:13
Picon

Re: SeND & CGA Extensions BOF

Hi Stig,

thanks for the comments, see reply in line...

El 04/06/2007, a las 12:51, Stig Venaas escribió:
>
> I agree that there are some challenges, but we should work on
> understanding what those are, and see if it is worthwhile to work
> on it.

well the proposed work is to understand those rather than build 
solutions.

the main question at this stage is what are the motivations for a node 
that needs to use CGAs to use also dhcp

If we determine that there are relevant scenarios where a host needs to 
use CGA and dhcp simoultaneously, then we should explore how to make 
these two work togehter, which is the proposed work.

So as i understand it, if we see use cases for using cga and dhcp in 
the same node, then we have a motivation for this work item (in this 
bof or somewhere else, but this means that this is interesting  work)

> I for one would like to think more about that (I guess you
> may have thought more about this than me Markus :)
>
> I have only passing knowledge of CGAs, but I wonder if there could also
> be ways of proving that an address really was handed out by a given
> DHCP server.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Suresh Krishnan | 4 Jun 2007 17:44
Picon
Favicon

Re: SeND & CGA Extensions BOF

Hi Markus,

Markus Stenberg wrote:
> The question I was trying to phrase is this: If I connect to a network, 
> generate an arbitrary CGA, what value can someone else derive from the 
> fact that they do opportunistic encryption with me, with CGA-based auth 
> as opposed to some arbitrary 'uhm, I am someone. really.' identity scheme?

The value you gain is that once you start communicating with a node 
using your CGA address, nobody else can claim to be you and communicate 
with the same node. I think that counts for something.

> 
> The difference in the level of trust between return-routability and 
> actually confirmed IP address (given no other information) seems slim to 
> me, as I wouldn't trust either of them for about any purpose.

CGA based addresses can guard against on-link attackers which return 
routability cannot.

Cheers
Suresh
Permalink | Reply | 0 comments |
headers
Bernard Aboba | 4 Jun 2007 19:01

Re: SeND & CGA Extensions BOF

I have a basic concern with the use of CGA in the IETF, which is that the 
CGA design is not currently crypto-agile. 

Before we starting "extending" CGA usage, shouldn't we have a firm 
foundation for it first? 

I have read the rationale for why a single algorithm was 
selected, but frankly I don't find it convincing.  In almost every 
instance where a fixed algorithm has been "baked" into a protocol, at some 
point this turned out to be a mistake. 

As it stands, were we to require an alternative to RSA (ECC, for example?) 
or an alternative hash (do we really think that SHA-1 is likely to remain 
viable forever?), CGAs as currently defined will fold like a house of 
cards, and the "extensions" with them.
Permalink | Reply | 6 comments |

Gmane