RE: [CGA-EXT] proposed csi charter text

[Sheng Jiang <[e-mail]>]

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:[e-mail]] 
*Sent: Friday, December 28, 2007 9:30 PM
*To: Jari Arkko
*Cc: [e-mail]
*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
*[e-mail]
*https://www1.ietf.org/mailman/listinfo/cga-ext
*



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