Cryptographically Generated Addresses (CGA)
RFC 3972

Note: This ballot was opened for revision 06 and is now closed.

(Steven Bellovin) Yes

(Margaret Cullen) Yes

(Thomas Narten) Yes

Comment (2004-02-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>    SubjectPublicKeyInfo data structure. Future versions of this
>    specification may add new fields to the end of the CGA Parameters and
>    the verifier SHOULD ignore any unrecognized data that follows the
>    encoded public key.

I don't understand what this is trying to say. This document defines
what gets compared, used, etc. No reading of this spec should be taken
to mean that "extra stuff after the end of the defined fields" should
somehow be used as part of the SEND computations. Thus, the above
would be a MUST (rather than a SHOULD), but I'd really like to
understand why this needs mentioning at all?

What problem/concern is the above trying to warn about?

(Harald Alvestrand) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

(Ted Hardie) (was No Record, Discuss) No Objection

Comment (2004-02-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The following text is fundamentally good:

 Finally, some cautionary notes should be made about using CGA-based
   authentication for other purposes than SEND. First, the other
   protocols should include type tags and the sender address in all
   signed messages in the same way as SEND does. Because of the
   possibility of related-protocol attacks, it is advisable to use the
   public key only for signing and not for encryption. Second, CGA-based
   authentication is particularly suitable for securing neighbor
   discovery [RFC2461] and duplicate address detection [RFC2462] because
   these are network-layer signaling protocols where IPv6 addresses are
   natural endpoint identifiers. In any protocol that aims to protect
   higher-layer data, CGA-based authentication alone is not sufficient
   and there must also be a secure mechanism for mapping higher-layer
   identifiers, such as DNS names, to IP addresses.


In that it discourages folks from using CGA-based authentication alone.  I'd
suggest strengthing it even further, though.  Would something like the 
following text be acceptable?

CGA-based authentication should not be considered for purposes other
than SEND and closely related mechanisms.  CGA-based authentication 
is particularly suitable for securing neighbor discovery [RFC2461] and 
duplicate address detection [RFC2462] because these are network-layer 
signaling protocols where IPv6 addresses are natural endpoint identifiers. 
In any protocol that aims to protect higher-layer data, CGA-based authentication 
alone is not sufficient as there must also be a secure mechanism for 
mapping higher-layer identifiers, such as DNS names, to IP addresses.
Further, using CGA-based authentication for other purposes may
weaken the effectiveness of this mechanism for SEND, because of the
possibility of related-protocol attacks.  If another mechanism needs
to re-use CGA-based authentication, it must take care that it 
include type tags and the sender address in all signed messages in the 
same way as SEND does and  it must use the public key only for signing and 
not for encryption.

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection