[CGA-EXT] Charter and scope

[Jari Arkko <[e-mail]>]

There's a bit of pushback from the security experts in
IESG and IAB to expand the scope of CGAs to generic
security mechanisms such as IKE. This pushback relates
to the question of key sizes as well as whether INT would
be the right place for such work. I tend to agree with this.

In addition, taking another look at the charter now it seems
that it has a fair bit material in it. It might be better to focus
the work on improving the use of SEND/CGA for IP layer purposes.
This by itself is already a big effort.

With that in mind, would the following reduced charter be
acceptable:

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 the to-be-RFC draft-bagnulo-multiple-hash-cga-03.txt.
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:

- 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
  the use of the DHCP protocol to assign CGAs, and making
  recommandations on which are the best suited.  The analysis will be
  provided as an input to the DHC working group where the actual DHCP
  extensions required to implemented the recommended approaches will
  be defined.

- Specify a standards-track CGA extension to support multiple public
  key algorithms. As currently defined CGAs can only use RSA keys in
  the CGA Parameter Data Structure, and thus cannot be generated using
  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.

- Update base specifications (RFC 3971 and 3972), if needed.

Related drafts:

draft-kempf-cgaext-ringsig-ndproxy-00.txt
draft-laganier-ike-ipv6-cga-02.txt
draft-jiang-sendcgaext-cga-config-00.txt



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