Re: [CGA-EXT] proposed csi charter text

[Jari Arkko <[e-mail]>]

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