Subject: [CGA-EXT] proposed csi charter text

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 18 Dec 2007 15:07:45 +0100

Hi all,

the bof in vancouver was very successful and we got very good  
feedback from the AD and the IAB. so the next step is to agree on the  
changes on the charter that were suggested on the BOF.

After discussing with the Ad and the chairs, we propose to include in  
the charter a new item on certificate management to provide cert  
profile, cert validation and cert porisioning.

We think that the anycast case that was suggested is not strictly  
clear that is within the scope of our work, so we prefer not to  
mention it explicitly in the charter, while it is possible to  
evaluate if the proposed solutions do work with anycast and  
eventually recharter later to include this work.

the proposed charter so far is the following:

We would like to send the charter to the AD in a week or so, so  
please provide feedback during the next week.

Regards, marcelo

Proposed charter for Cga & Send maIntenance (CSI) BOF

The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971
provides security mechanisms protecting different functions of the
Neighbor Discovery (ND) protocol defined by RFC 2461.  This includes
address resolution (discovering link layer address of another node
attached to the link), router discovery (discovering routers attached
to the link), and neighbor unreachability detection (detecting that a
node attached to the link is no longer reachable).  SEND protection of
address resolution and neighbor unreachability detection functions
relies on IPv6 address proof-of-ownership and message integrity
protection provided respectively via Cryptographically Generated
Addresses (CGAs) and RSA Digital Signatures.

CGAs are defined in RFC 3972, and are extended with a CGA extension
format defined in RFC 4581, and a support for multiple hash functions
defined in RFC 4982. 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 protocol and the Mobile IPv6
protocol. While there is very little deployment of SEND to date,
there are a number of implementations, recommendations in the NIST
and DOD profiles call for use of SEND, and operating system vendors
are considering adding SEND to their next releases. As a result, it
is desirable to review the current state of the SEND and CGA
specifications, maintain and complement them where necessary. Up to
date cryptographic algorithms are needed, and the protocols need to be
able to deal with certain common situations currently not supported.

Specifically, the WG will look at the following issues:

- Develop an informational document analyzing the implications of recent
   attacks on hash functions used by SeND protocol. Current SeND
   specification uses the SHA-1 hash algorithm and does not provides
   support for hash algorithm agility, hence the critical need for
   understanding the impact of the attacks on the SeND protocol. In
   addition, if as a result of the aforementioned analysis it is
   deemed necessary, standard-track extensions to the SeND protocol to
   support multiple hash algorithms will be defined.

- Specify a standards-track CGA and SeND extensions to support multiple
   public key algorithms. As currently defined CGA and SeND can only use
   RSA keys, and they lack support for other public key algorithms
   (e.g. Elliptic Curve Cryptography -- ECC). The main motivation for
   this work is that RSA keys are not well suited for environments with
   resource restrictions (CPU, storage, power) such as the ones  
considered
   by the 6lowpan working group. ECC is much well suited for such
   environments and the lack of support of ECC in CGAs and SeND is a
   deployment blocker in these environments.

- Definition of X.509 Extended Key Usage for SeND. SeND utilizes X.509v3
   certificates for performing router authorization.  It uses the X.509
   extension for IP addresses to verify whether the router is authorized
   to advertise the mentioned IP addresses.  Since the IP addresses
   extension does not explicitly mention what functions the node can
   perform for the IP addresses it becomes impossible to know the reason
   for which the certificate was allowed.  In order to facilitate  
issuance
   of certificates for specific functions, we need to encode the  
functions
   permitted for the certificate into the certificate itself.

- Develop X.509 certificate management tools for SeND. SeND utilizes  
X.509v3
   certificates for performing router authorization.  It uses the X.509
   extension for IP addresses to verify whether the router is authorized
   to advertise the mentioned IP addresses.  Since the IP addresses
   extension does not explicitly mention what functions the node can
   perform for the IP addresses it becomes impossible to know the reason
   for which the certificate was allowed.  In order to facilitate  
issuance
   of certificates for specific functions, we need to encode the  
functions
   permitted for the certificate into the certificate itself. The WG  
will
   develop a certificate profile, including a definition of X.509  
Extended
   Key Usage for SeND . In addition, the WG will recommend best  
practices for
   (1) enrollment, (2) revocation checking, and (3) publishing of
   certificates. This WG will ensure that the profile and recommended
   practices will cover usage by hosts in addition to routers.

- Develop a standard track document defining a mechanism to perform
   SeND certificate provisioning for routers. SeND protocol as defined
   in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised
   by a router. The solution is based on the use of the IP Address
   Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280).
   This work will provide the tools require to provision with the
   certificates to the routers in an automatic manner.

- Produce a problem statement document for Neighbor Discovery Proxies
   and then specify standards-track SEND Extensions to support Neighbor
   Discovery Proxies:  SEND protocol as currently defined in RFC 3971
   lacks of support for ND Proxies defined in RFC 3775 and RFC 4389.
   Extensions to the SEND protocol will be defined in order to provide
   equivalent SEND security capabilities to ND Proxies.

- Develop an informational document analysing different approaches
   to allow SeND and CGAs to be used in conjunction with DHCP, and
   making recommendations on which are the best suited.  Recharter
   based on the result of the analysis.

- Update base specifications (RFC 3971 and 3972).

Goals and Milestones:

Jun 08	  	WG last-call on analysis of hash related threats in SeND
Jun 08    	WG last-call on Proxy-SeND problem statement
Dec 08	  	WG last-call on Proxy SeND
Dec 08	  	WG last-call on multiple hash function support in SeND, if  
required
Set 08	  	WG last-call on CGA-DHCP interaction
Set 08	  	WG last-call on multiple public key algorithm support for CGA
Set 08	  	WG last-call on multiple public key algorithm support for SeND
Dec 08	  	WG last-call on certificate profile definition for SeND
Dec 08	  	WG last-call on certificate provision mechanism for SeND  
routers
Dec 08	  	WG last-call on certificate management best practices for  
SeND routers
Feb 09	  	WG last-call on updated SeND specification
Feb 09	  	WG last-call on updated CGA specification

Jul 08	  	Submit draft on analysis of hash related threats in SeND to  
IESG
Jul 08     	Submit draft on Proxy-SeND problem statement to IESG
Jan 09	  	Submit draft on Proxy SeND to IESG
Jan 09	  	Submit draft on multiple hash function support in SeND to  
IESG, if required
Oct 08	  	Submit draft on CGA-DHCP interaction to IESG
Oct 08	  	Submit draft on multiple public key algorithm support for  
CGA to IESG
Oct 08	  	Submit draft on multiple public key algorithm support for  
SeND to IESG
Jan 09	  	Submit draft on EKU definition for SeND to IESG
Jan 08	  	Submit draft on certificate provision mechanism for SeND  
routers to IESG
Jan 08	  	Submit draft on certificate management best practices for  
SeND routers to IESG
Mar 09	  	Submit draft on updated SeND specification to IESG
Mar 09	  	Submit draft on updated CGA specification to IESG

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cga-ext

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Dec 2007 13:32:39 +0200

FWIW, this charter looks fine to me.

I have done one edit, however: I removed the argumentation about ECC. It
is already convincing enough argument that we need more than one
algorithm. No further arguments are needed.

I am now sending the charter to IESG and IAB discussion.

Jari

>   (e.g. Elliptic Curve Cryptography -- ECC).
>
>   for which the certificate was allowed.  In order to facilitate issuance
>   of certificates for specific functions, we need to encode the functions
>   for which the certificate was allowed.  In order to facilitate issuance
>   of certificates for specific functions, we need to encode the functions
>   permitted for the certificate into the certificate itself. The WG will
>   develop a certificate profile, including a definition of X.509 Extended
> Dec 08          WG last-call on multiple hash function support in
> SeND, if required
> Dec 08          WG last-call on certificate provision mechanism for
> SeND routers
> Dec 08          WG last-call on certificate management best practices
> for SeND routers
> Jul 08          Submit draft on analysis of hash related threats in
> SeND to IESG
> Jan 09          Submit draft on multiple hash function support in SeND
> to IESG, if required
> Oct 08          Submit draft on multiple public key algorithm support
> for CGA to IESG
> Oct 08          Submit draft on multiple public key algorithm support
> for SeND to IESG
> Jan 08          Submit draft on certificate provision mechanism for
> SeND routers to IESG
> Jan 08          Submit draft on certificate management best practices
> for SeND routers to IESG

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Dec 2007 14:30:03 +0100

Great, thanks!
regards, marcelo

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 28 Dec 2007 16:35:29 +0100

Hi,

sorry for the delayed reply.

> eventually recharter later to include this work.

If we don't mention this case in the charter, there will be nothing
about it in the PS document and this one will have to be updated later
to integrate this case. As the problem with anycast addresses is, more
or less, the same with ProxyND, IHMO, it would be preferable to have
this case in the PS to avoid an update of it in the future.

[snip]

>    equivalent SEND security capabilities to ND Proxies.

[snip]

Best regards and happy new year.

JMC.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Dec 2007 16:43:54 +0100

Hi,

> this case in the PS to avoid an update of it in the future.

but it is far from clear to me that the anycast case is similar to  
the one of proxynd and imho more analysis is needed
so i would really prefer to charter this work as it is curently  
defined and if people are interested on the anycast case and we do  
the anlysis and it seems that it is a possible to deal with the  
anycast case with the sam tools, we can easily recharter to cover  
this case

Moreover, there is a clear stage to do this, since we need to produce  
a problem statement for proxy send, so this would be a great moment  
to bring and discuss this issue and if during the proxy send pb  
statement disucssion we conclude that it would be ok to work on this  
we can try to recharter before starting the work on the acutal proxy  
send solution work

would that be ok?

Regards, marcelo

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 28 Dec 2007 16:51:23 +0100

Hi again,

> we can try to recharter before starting the work on the acutal proxy

It's fine for me.

Best regards.

JMC.

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 29 Dec 2007 09:02:05 +0800

Excellent, thanks!

Best regards,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product Line, Huawei
Technologies Co. Ltd.

*-----Original Message-----
*From: marcelo bagnulo braun [mailto:[email-masked]] 
*Sent: Friday, December 28, 2007 9:30 PM
*To: Jari Arkko
*Cc: [email-masked]
*Subject: Re: [CGA-EXT] proposed csi charter text
*
*Great, thanks!
*regards, marcelo
*
*
*El 28/12/2007, a las 12:32, Jari Arkko escribió:
*
*> FWIW, this charter looks fine to me.
*>
*> I have done one edit, however: I removed the argumentation 
*about ECC. 
*> It is already convincing enough argument that we need more than one 
*> algorithm. No further arguments are needed.
*>
*> I am now sending the charter to IESG and IAB discussion.
*>
*> Jari
*>
*>> Proposed charter for Cga & Send maIntenance (CSI) BOF
*>>
*>> The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 
*>> provides security mechanisms protecting different functions of the 
*>> Neighbor Discovery (ND) protocol defined by RFC 2461.  This 
*includes 
*>> address resolution (discovering link layer address of another node 
*>> attached to the link), router discovery (discovering 
*routers attached 
*>> to the link), and neighbor unreachability detection 
*(detecting that a 
*>> node attached to the link is no longer reachable).  SEND protection 
*>> of address resolution and neighbor unreachability detection 
*functions 
*>> relies on IPv6 address proof-of-ownership and message integrity 
*>> protection provided respectively via Cryptographically Generated 
*>> Addresses (CGAs) and RSA Digital Signatures.
*>>
*>> CGAs are defined in RFC 3972, and are extended with a CGA extension 
*>> format defined in RFC 4581, and a support for multiple hash 
*functions 
*>> defined in RFC 4982. 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 protocol and the 
*Mobile IPv6 
*>> protocol. While there is very little deployment of SEND to date, 
*>> there are a number of implementations, recommendations in the NIST 
*>> and DOD profiles call for use of SEND, and operating system vendors 
*>> are considering adding SEND to their next releases. As a result, it 
*>> is desirable to review the current state of the SEND and CGA 
*>> specifications, maintain and complement them where necessary. Up to 
*>> date cryptographic algorithms are needed, and the protocols need to 
*>> be able to deal with certain common situations currently not 
*>> supported.
*>>
*>> Specifically, the WG will look at the following issues:
*>>
*>> - Develop an informational document analyzing the implications of 
*>> recent
*>>   attacks on hash functions used by SeND protocol. Current SeND
*>>   specification uses the SHA-1 hash algorithm and does not provides
*>>   support for hash algorithm agility, hence the critical need for
*>>   understanding the impact of the attacks on the SeND protocol. In
*>>   addition, if as a result of the aforementioned analysis it is
*>>   deemed necessary, standard-track extensions to the SeND 
*protocol to
*>>   support multiple hash algorithms will be defined.
*>>
*>> - Specify a standards-track CGA and SeND extensions to support 
*>> multiple
*>>   public key algorithms. As currently defined CGA and SeND can only 
*>> use
*>>   RSA keys, and they lack support for other public key algorithms
*>>   (e.g. Elliptic Curve Cryptography -- ECC).
*>>
*>> - Definition of X.509 Extended Key Usage for SeND. SeND utilizes X. 
*>> 509v3
*>>   certificates for performing router authorization.  It uses the X. 
*>> 509
*>>   extension for IP addresses to verify whether the router is 
*>> authorized
*>>   to advertise the mentioned IP addresses.  Since the IP addresses
*>>   extension does not explicitly mention what functions the node can
*>>   perform for the IP addresses it becomes impossible to know the 
*>> reason
*>>   for which the certificate was allowed.  In order to facilitate 
*>> issuance
*>>   of certificates for specific functions, we need to encode the 
*>> functions
*>>   permitted for the certificate into the certificate itself.
*>>
*>> - Develop X.509 certificate management tools for SeND. SeND utilizes
*>> X.509v3
*>>   certificates for performing router authorization.  It uses the X. 
*>> 509
*>>   extension for IP addresses to verify whether the router is 
*>> authorized
*>>   to advertise the mentioned IP addresses.  Since the IP addresses
*>>   extension does not explicitly mention what functions the node can
*>>   perform for the IP addresses it becomes impossible to know the 
*>> reason
*>>   for which the certificate was allowed.  In order to facilitate 
*>> issuance
*>>   of certificates for specific functions, we need to encode the 
*>> functions
*>>   permitted for the certificate into the certificate itself. The WG 
*>> will
*>>   develop a certificate profile, including a definition of X.509 
*>> Extended
*>>   Key Usage for SeND . In addition, the WG will recommend best 
*>> practices for
*>>   (1) enrollment, (2) revocation checking, and (3) publishing of
*>>   certificates. This WG will ensure that the profile and recommended
*>>   practices will cover usage by hosts in addition to routers.
*>>
*>> - Develop a standard track document defining a mechanism to perform
*>>   SeND certificate provisioning for routers. SeND protocol 
*as defined
*>>   in RFC3971 specifies how IPv6 nodes can trust the prefixes 
*>> advertised
*>>   by a router. The solution is based on the use of the IP Address
*>>   Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280).
*>>   This work will provide the tools require to provision with the
*>>   certificates to the routers in an automatic manner.
*>>
*>> - Produce a problem statement document for Neighbor 
*Discovery Proxies
*>>   and then specify standards-track SEND Extensions to support 
*>> Neighbor
*>>   Discovery Proxies:  SEND protocol as currently defined in RFC 3971
*>>   lacks of support for ND Proxies defined in RFC 3775 and RFC 4389.
*>>   Extensions to the SEND protocol will be defined in order 
*to provide
*>>   equivalent SEND security capabilities to ND Proxies.
*>>
*>> - Develop an informational document analysing different approaches
*>>   to allow SeND and CGAs to be used in conjunction with DHCP, and
*>>   making recommendations on which are the best suited.  Recharter
*>>   based on the result of the analysis.
*>>
*>> - Update base specifications (RFC 3971 and 3972).
*>>
*>>
*>> Goals and Milestones:
*>>
*>> Jun 08          WG last-call on analysis of hash related threats  
*>> in SeND
*>> Jun 08        WG last-call on Proxy-SeND problem statement
*>> Dec 08          WG last-call on Proxy SeND
*>> Dec 08          WG last-call on multiple hash function support in
*>> SeND, if required
*>> Set 08          WG last-call on CGA-DHCP interaction
*>> Set 08          WG last-call on multiple public key 
*algorithm support
*>> for CGA
*>> Set 08          WG last-call on multiple public key 
*algorithm support
*>> for SeND
*>> Dec 08          WG last-call on certificate profile definition for  
*>> SeND
*>> Dec 08          WG last-call on certificate provision mechanism for
*>> SeND routers
*>> Dec 08          WG last-call on certificate management best 
*practices
*>> for SeND routers
*>> Feb 09          WG last-call on updated SeND specification
*>> Feb 09          WG last-call on updated CGA specification
*>>
*>> Jul 08          Submit draft on analysis of hash related threats in
*>> SeND to IESG
*>> Jul 08         Submit draft on Proxy-SeND problem statement to IESG
*>> Jan 09          Submit draft on Proxy SeND to IESG
*>> Jan 09          Submit draft on multiple hash function support in  
*>> SeND
*>> to IESG, if required
*>> Oct 08          Submit draft on CGA-DHCP interaction to IESG
*>> Oct 08          Submit draft on multiple public key 
*algorithm support
*>> for CGA to IESG
*>> Oct 08          Submit draft on multiple public key 
*algorithm support
*>> for SeND to IESG
*>> Jan 09          Submit draft on EKU definition for SeND to IESG
*>> Jan 08          Submit draft on certificate provision mechanism for
*>> SeND routers to IESG
*>> Jan 08          Submit draft on certificate management best 
*practices
*>> for SeND routers to IESG
*>> Mar 09          Submit draft on updated SeND specification to IESG
*>> Mar 09          Submit draft on updated CGA specification to IESG
*>
*>
*
*
*_______________________________________________
*CGA-EXT mailing list
[email-masked]
*https://www1.ietf.org/mailman/listinfo/cga-ext
*