Cryptographically Generated Addresses (CGA)
draft-ietf-send-cga-06
Yes
(Margaret Cullen)
(Steven Bellovin)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Harald Alvestrand)
(Jon Peterson)
(Ned Freed)
(Russ Housley)
Note: This ballot was opened for revision 06 and is now closed.
Margaret Cullen Former IESG member
Yes
Yes
()
Unknown
Steven Bellovin Former IESG member
Yes
Yes
()
Unknown
Thomas Narten Former IESG member
Yes
Yes
(2004-02-18)
Unknown
> 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?
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2004-02-17)
Unknown
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.