For some reason, in your response, my "bulletization" of the list of the new status codes somehow got "re-paragraphed" - hopefully my version below does not suffer the same fate. Typographical "resets" should be absolutely disallowed in E-Mail. :-) To the casual reader, it may otherwise be unclear exactly what change I was suggesting... > -----Original Message----- > From: Christian Vogt [mailto:chvogt@xxxxxxxxx] > Sent: Wednesday, January 31, 2007 12:48 PM > To: Eric Gray (LO/EUS) > Cc: Wassim Haddad (KI/EAB); Jari Arkko (JO/LMF); Mark > Townsley; gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART Last Call Review of > draft-ietf-mipshop-cga-cba-02.txt > > Hello Eric, > > thank you for taking your time to review draft-ietf-mipshop-cga-cba. > Please see my comments in-line below. > > Note I'm also sending a CC to ietf@xxxxxxxx as suggested in > the IESG's > Last Call announcement on the Mipshop working group's mailing list. > > > Summary: > > > > I have a small number of comments and/or questions on this > draft. From > > a generalist perspective, this is a very well written and - for the > > complexity of the protocol involved - relatively easy to > read document. > > > > > > Comments: > > ____________________________________________________________________ > > > > Security section (2.2), top of page 8, lists ability to "securely > > authenticate mobile nodes without preconfigured credentials or a > > public-key infrastructure" as an objective of this protocol. > > > > I don't see how it is possible to avoid requiring public keys for > > Cryptographically Generated home Addresses - in particular - since > > section 3.1 seems to say that CGA results in a binding between each > > mobile node's home address and that mobile node's public key, thus > > allowing other nodes to securely authenticate the mobile node. > > > > Even though this is done infrequently to establish a semi-permanent > > security association, it is done at least once (during establishment > > of an initial registration association between a pair of mobile and > > correspondent nodes) - hence there seems to be some dependence on > > public key infrastructure. > > > > I don't know how to fix this - or even if it needs fixing - but it > > might be useful to qualify this "objective" using "ideally". If, on > > the other hand, this objective is actually met, I did not see where > > this is explained. Is it met, and - if so - is it explained? > > The objective is actually met, but I see your point that this is not > made clear in the draft. > > Specifically: It is true that a node needs a public/private-key pair in > order to generate a CGA and to prove ownership of this CGA to its peers. > Yet such an IP address ownership proof still does not require a PKI. In > general, a PKI provides a secure binding between a node's identifier and > public key, but in the case of a CGA, the CGA itself is cryptographically > bound to the CGA owner's public key. So where the CGA serves as an > identifier for its owner -- as is the case in an IP address ownership > proof --, no PKI is required. This is the primary advantage of CGA-based > authentication compared to other public-key approaches. > > To clarify this matter, I suggest to extend subsection 3.1. > ("Cryptographically Generated Home Addresses") in the > "Protocol Design" section as follows: > > OLD: > > [...] In general, a > CGA provides a strong binding between its interface identifier and > the CGA owner's public key. This enables other nodes to securely > authenticate the CGA owner as such, modulo the correctness of the > CGA's subnet prefix. [...] > > NEW (shortened): > > [...] In general, a > CGA provides a strong, cryptographic binding between its interface > identifier and the CGA owner's public key. This facilitates a > cryptographic home address ownership proof without a PKI, enabling > other nodes to securely and autonomously authenticate the CGA owner > as such, modulo the correctness of the CGA's subnet prefix. [...] > > > ____________________________________________________________________ > > > > I suggest changing the 2nd paragraph in IANA Considerations to read > > something like: > > > > This document allocates the following four new status codes for Binding > > Acknowledgment messages: > > > > "Permanent home keygen token unavailable", "CGA and signature > > verification failed", "Permanent home keygen token exists", and > > "Non-null home nonce index expected" "Permanent home keygen token unavailable", "CGA and signature verification failed", "Permanent home keygen token exists", and "Non-null home nonce index expected" > > > > The values to be assigned for these status codes must all be greater > > than or equal to 128, indicating that the respective Binding Update > > message was rejected by the receiving correspondent node. > > Yes, that would be more clearly arranged. Will change it. > > > ____________________________________________________________________ > > > > I also suggest that this document should be accompanied with an > > explicit RFC Editor's note to replace TBD with IANA assigned values > > (as identified by associated parenthetical value names) in several > > places throughout the draft. It would help if specific TBDs were > > distinct (e.g. TBD-1, TBD-2, TBD-3 and TBD-4) and these "variable" > > names then associated (perhaps in a table) with their meanings in > > the IANA considerations section. > > Ok. There are quite a number of numbers to be allocated by IANA, so > I see your point of making it a bit easier for IANA. And slightly easier (== less error-prone) for the RFC Editor as well... > > > ____________________________________________________________________ > > > > Reference 6 ("Cryptographically Generated Addresses (CGA)" - RFC 3972) > > should be Normative. > > Indeed. > > > ____________________________________________________________________ > > > > NITs: ==== > > > > In the 3rd bullet of section 2.2 (Security), on page 7, it should be > > "mobile or correspondent" verses "mobile and correspondent" (more > > inclusive as it is probably necessary only to victimize one or the > > other to effect a denial of service). > > Yes, will change it. > > > ____________________________________________________________________ > > > > In the first bullet of the last set of (3) bullets on page 18, it is > > really necessary to break this sentence up at least with commas - in > > order to make it so a reader can parse it. I suggest: > > > > "If the Binding Update message is complete, the care-of nonce index is > > taken from the Care-of Test option or Care-of Test message with which > > the care-of keygen token (used to calculate the authenticator for the > > Binding Update message) was obtained." > > > > Note that I use parens, rather than commas, to make the structure more > > readily apparent. > > This is easier to parse, yes. I'll change it. > > > ____________________________________________________________________ > > > > In section 6 (Security Considerations), the statement about changes in > > the security model - should the reference be [4], rather than - or in > > addition to - [1]? > > Yes, the reference should be [4], and it should appear after "security > model" rather than after "base Mobile IPv6". Thanks for catching this! > > Eric, my co-authors and I appreciate your review. Thanks again for > taking your time! :-) > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) > www.tm.uka.de/~chvogt/pubkey/ > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf