Steven Bellovin writes: One last thing. My original comments included the following: There are a number of HMAC'd fields floating around. Some, at least, seem to have a distinguishing type value, such as 0 in the home keygen token. The Binding Update takes a parameter with a BU in the last byte. Is that intended to serve the same purpose? I don't see a value for BU defined anywhere -- is that the '5' in Section 14? If so, the 0 and 1 shouldn't overlap that type space, and there should be an explicit statement about the reserved values in Section 14, so that no future IANA assignments conflict with them. I'd also like the authors to verify that all HMAC'd fields have such such type code that is never used elsewhere. I couldn't easily verify that my concerns were satisfied -- do all HMAC'ed fields include some sort of type indicator? (There's a wonderful paper from 1994 by Abadi and Needham that explains why this is required.) I did not see any note in the IANA considerations, and my broader concern would be reflected by little changes throughout the document. ------------------- Jari Arkko writes: Ah, I see what you are getting at. We did change the text to make it clearer what was meant, but I guess we weren't fully successful. Plus there's one additional thing that I didn't think of, but it happens to be correct, more or less by accident Meaning of the BU BU does not stand for a number. It stands for the contents of the message itself. If you look at the way these HMAC fields are calculated in the protocol, there are currently two alternatives: 1. In a Binding Update: HMAC(Kbm, care-of address | correspondent | BU) 2. In a Binding Acknowledgement: HMAC(Kbm, care-of address | correspondent | BA) Here BU stands for the contents of the whole Binding Update message, and BA stands for the contents of the whole Binding Acknowledgement message. As explained in Section 6.2.7, these "whole messages" contain even the MH header. And MH header contains the type of the message, which is different for every message: BU (5), BA (6), and so on. Regular IANA rules prevent allocation of different messages for the same number, hence I don't think these MAC values can collide. Collisions in different MAC values But the HMAC fields discussed above are not the only HMAC fields in the whole protocol. The two HMACs discussed above will be put to the Binding Authentication Data option. Inside that option there can not be a collision. What we didn't think of during the construction of the protocol is that we should ensure HMACs made for different purposes and appearing in different places do not collide. An attacker might be able to use such a collision to his advantage. In our case there are the following additional two HMAC fields: 3. home keygen token = HMAC(Kcn, home address | nonce | 0) 4. care-of keygen token = HMAC(Kcn, care-of address | nonce | 1) Again, these values do not appear in the Binding Authorization Data option, but an attacker might be able to use them if they were constructed to collide with the values in that option. Luckily -- not by design -- the values can not collide. First of all, the nonce would have to collide with the address of the correspondent node, and this would be highly unlikely. Well, you could argue that the attacker sets his nonce according to his address, but I'm uncertain what that would achieve. It does not make sense for the correspondent node to attack against itself. Secondly, the "0" and "1" in the formulas 3 and 4 can never match "BU" or "BA" in the formulas 1 and 2. This is because "BU" and "BA" are always longer than a single octet. Conclusion I think the issue is in order, and no document changes are needed. All HMAC fields include a type indicator, either explicitly in the formula, or implicitly through the data included in the formula. ------------------- Steven Bellovin responds to Jari Arkko: OK -- I'm convinced about the HMACs. ------------------- Russ Housley writes: Do you believe that updates will be made to this document in the future? If so, then some of this information might belong in the security considerations or an appendix to aid the next generation. I am not pushing. Decide if updates are likely and if the information would be valuable to the people doing the updates. ------------------- Jari Arkko responds to Russ Housley: Now that you mention it, it might be useful to say something about the MAC field collisions in the security considerations section (meaning of "BU" is as clear as we can make it, imho). I will add a brief version of the discussion to the security considerations section. But I just submitted a new version yesterday, so assuming IESG will approve the document, I'm planning to do wait with the modification until AUTH48... ------------------- You made the following comment after Steven and I discussed the MAC field aspects in draft-ietf-mobileip-ipv6-23.txt: > Do you believe that updates will be made to this document in the > future? If so, then some of this information might belong in the > security considerations or an appendix to aid the next generation. > I am not pushing. Decide if updates are likely and if the > information would be valuable to the people doing the updates. I responded then that it would make sense to add some of the discussion to the security considerations, to avoid getting other folks ask the same questions as Steven did. However, I had by then submitted draft 23 already and I said that I'd add this material in AUTH48, assuming IESG approves the document. Since then I recalled that we actually have another document which might be a better place for the discussion of the MAC fields. Specifically, the security considerations in draft-ietf-mobileip-ipv6-23.txt gives an overview of the security properties and design of RR. But draft-nikander- mobileip-v6-ro-sec-00.txt gives a more in-deth view to the design of the RR mechanism. So my suggestion is that the MAC discussion be included in that other document (unless its already there). Gabriel is the current editor of that other document, and I think the plan was to make one more update once the busy Vienna period is over, and submit it as an informational RFC. In conclusion I *think* that you should be able to approve the MIPv6 base specification in the next IESG meeting. And next to the ha-ipsec document, where I still have one unanswered issue (touch-ipsec-vpn reference) pending, and Steven needs to think whether our responses regarding the API issue have been sufficient. ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- ------------------- -------------------