Subject: [CGA-EXT] BOF Date?

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Oct 2007 10:30:57 -0700

Has the BOF been approved and/or scheduled yet? If so, what day?

            jak

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

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Tue, 23 Oct 2007 22:31:13 +0200

Hi James,

the bof has been requested but still no news about whether it has been 
aproved or not, much less about the date

Regards, marcelo

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Oct 2007 10:37:23 +0200

Decision will be made on Thursday.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Oct 2007 12:05:17 +0200

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 24 Oct 2007 13:12:55 +0200

Hi Jari,

thanks for the feedback

i understand your point

Just a couple of obsrevations:

- do you think that the mib definition for SeND and CGAs are out of  
the scope? This seems to be not related to the usge of CGAs as a  
generic security tool...
- i think we should also include an item that perform the rescorla  
bellovin analysis on the SeND spec (rfc3971) and to evaluate its  
dependency on SHA1 algorithm and eventually update rfc3971 to support  
multiple hash functions
- in addition, we should also extend SeND spec (rfc3971) to support  
multiple public key algorithms, so send can use the other public key  
algorithms that are defind in the CGA update item...

do you think it would make sense to include these additional items?

regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Oct 2007 14:04:10 +0200

> the scope? This seems to be not related to the usge of CGAs as a

That's right. I only took it out to reduce the number of work items to
those that seemed highest priority. But this is certainly something that
we should talk about.

> dependency on SHA1 algorithm and eventually update rfc3971 to support

Didn't we do this already?

> do you think it would make sense to include these additional items?

Yes, definitely. I may have forgotten that one out of the revision I
made. If so, apologies. That should definitely be there.

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 24 Oct 2007 15:57:55 +0200

> those that seemed highest priority. But this is certainly something  

ok, i think we should do that, and i guess this shouldn't be too  
difficult

actually, i was reviewing rfc 3971 and it is written in such a way  
that would this work be quite straight forward imho... i mean, the  
"configuration" sections on each mayor part of the protocol basically  
defines the data strucutures that need to be managed, so this would  
simplify the task of defining the mib i think

> Didn't we do this already?

we have done that for rfc3972 but not for rfc3971

i have been reviewing rfc3971 and there is some encoding of the sha1  
algorithm in there and it may worthwhile to do the rescorla bellovin  
analysis for that spec and see if it is needed to provide hash  
function agility

> made. If so, apologies. That should definitely be there.

Actually this was my mistake (i forgot to include it in the charter  
proposal :-(

Regards, marcelo