Securing Mobile IPv6 Route Optimization Using a Static Shared Key
draft-ietf-mip6-precfgkbm-04
No Objection
(Alex Zinin)
(Bill Fenner)
(Brian Carpenter)
(Margaret Cullen)
(Sam Hartman)
Note: This ballot was opened for revision 04 and is now closed.
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
(was Discuss)
No Objection
No Objection
(2005-10-04)
Unknown
My Discuss is handled in to-come 04 (pretty simply because I just asked for a normative ref and didn't say how to couch it); I clear in advance because Sam added a more detailed Discuss related to BCP 107 issues after mine. (I replied on Oct 3 to email from Basavaraj Patil dated Sep 29, to all the Discussant ADs and author) From that mail: > > Allison Mankin: > Discuss: > [2005-07-07] I'll put in this Discuss because of Russ's absence. My=20 > attention has been drawn for some > Transport documents to the expertise in BCP 107 (RFC 4107), and=20 > especially given the fact that > there is self-definition of the applicability of the trust model for=20 > this usage, the manual keys > here at least seems to me to need to meet the cryptographic=20 > requirements in BCP 107, such as: > > When manual key management is used, long-term shared secrets MUST be > unpredictable "random" values, ensuring that an adversary will have > no greater expectation than 50% of finding the value after searching > half the key search space. > > There are other discusses like this, but I'm not sure if they call for > specifying the > key generation procedure to ensure randomness. There's also a SHOULD in > BCP 107 for a sufficiently long key. BCP 107 may need to be normative > here. Done.
Bert Wijnen Former IESG member
No Objection
No Objection
(2005-07-06)
Unknown
It seems to me that a normative reference to RFC2119 (use of RECOMMENDED and MUST) needs to be added. And a citation of course.
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
(was Discuss)
No Objection
No Objection
(2005-07-07)
Unknown
I received the following comments from Pekka Savola on the Ops Directorate: minor editorial issues ---------------------- When a Binding Update is to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present. The Nonce Indices option SHOULD NOT be present. If it is present, the nonce indices supplied MAY be ignored and are not included as part of the calculation for the authentication data, which is to be carried exactly as specified in [1]. ==> "MAY be ignored" ? What is the alternative? Shouldn't this be "MUST be ignored" or "SHOULD be ignored"? (This seems like an editorial issue, because AFAIR "may be ignored" in English can be interpreted with at least two levels of normativeness) A correspondent node and a mobile node MAY use a precomputable binding management key (Kbm) to manage the authentication requirements for binding cache management messages. ==> I'd replace "MAY" with "may", because this doesn't seem to be something that requires uppercasing.
Jon Peterson Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(2005-07-06)
Unknown
The Abstract might be a bit more concrete. Unusual way of splitting the references...
Margaret Cullen Former IESG member
(was Discuss, No Objection, Yes)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2005-10-05)
Unknown
I think I'm confused. The document says in the Introduction: This mechanism is also limited to use only in scenarios where mobile nodes can be trusted to not misbehave, as the validity of the claimed care-of addresses is not verified. In the applicability statement, it goes on to say: - The correspondent node has good reason to trust the actions of the mobile node. In particular, the correspondent node needs to be certain that the mobile node will not launch flooding attacks against a third party as described in [2]. But the Security Considerations don't contain any details about what happens if this trust is misplaced. draft-ietf-mip6-ro-sec-03 has quite a taxonomy of potential issues; I would have thought that a basic run-through of those would be useful. Not that it needs to go through the whole document, but a statement about whether any existing consideration (one of the flooding attacks?) are worsened by this approach or that none are would seem like a valuable addition. Charlie responded: do not agree with this. It would be wrong to repeat the contents of draft-ietf-mip6-ro-sec-NN here, and there isn't any real relevance. The point of the document is to provide a good way to secure Binding Updates, and in fact my major complaint with draft-ietf-mip6-ro-sec-NN was that it often seemed to imply that Mobile IPv6 was vulnerable to situations caused by insecure Binding Updates. That would be wrong, because a crucial point of the design of Binding Update was to ensure security. The cited document did not make that clear enough in my opinion, and as a result people would run around acting very worried. Keep in mind that the cited Internet Draft was written _years_ after the Binding Update was well-secured, so that this raised quite unwarranted fears. Nevertheless, if you would like to see some specific text in the current document under discussion, please send it to me and I reckon it would go in, as a way of eliminating concerns from future readers with similar worries.