Last Call Review of draft-ietf-hip-hiccups-
review-ietf-hip-hiccups-secdir-lc-mcgrew-2010-06-20-00

Request Review of draft-ietf-hip-hiccups
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-15
Requested 2010-06-03
Authors Gonzalo Camarillo, Jan Melen
Draft last updated 2010-06-20
Completed reviews Secdir Last Call review of -?? by David McGrew
Assignment Reviewer David McGrew
State Completed
Review review-ietf-hip-hiccups-secdir-lc-mcgrew-2010-06-20
Review completed: 2010-06-20

Review
review-ietf-hip-hiccups-secdir-lc-mcgrew-2010-06-20

I have reviewed this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the  


IESG.  These comments were written primarily for the benefit of the  


security area directors.  Document editors and WG chairs should treat  


these comments just like any other last call comments.






There are several points where the draft could be made more clear,  


some of which might impact security.  I've listed those below,  


intermingled with some nits.






Abstract and Section 1.  "secure" is used where "authenticated" would  


be better, since this protocol does not provide any confidentiality  


services or encryption.






RFC 4949 lists "message integrity code (MIC)" as a deprecated term,  


but this term is defined and used.  In this case what is meant is  


"collision-resistant hash"; that phrase should be used in Sections 2  


and 7.  "Checksum" is an inappropriate term for a collision-resistant  


hash and it should be replaced in Section 4.   For the security  


considerations section: does the hash need strong collision- 


resistance, or just second preimage resistance (also called weak  


collision-resistance)?




Section 4 nits: "with help of MIC." -> "with the help of the MIC."
"HIP DATA packet"-> "The HIP DATA packet"


"Hash algorithm used to generate MIC is same " -> "The hash algorithm  


used to generate the MIC is the same "






Section 4.1.  I suggest emphasizing the requirement for the "Sequence  


Number" fields in distinct SEQ_DATA parameters to be distinct.






Section 4.3. says "Payload Data 8 last bytes of the payload data over  


which the MIC is calculated. This field is used to uniquely bind  


PAYLOAD_MIC parameter to next header, in case there are multiple  


copies of same type."   It seems to me that this uniqueness is not  


guaranteed, but that if the last-8-bytes is not unique, the MIC  


verification process would fail, but that there is no way that an  


attacker could exploit this fact.   I suggest noting this property in  


the security considerations.






Section 4.3: The PAYLOAD_MIC parameter has a field called "Payload  


MIC".  It would be less confusing if the latter was called "MIC Value"  


or some other named that is distinct from the parameter name.






Section 4.3 nit: "Identifies the data that protected by this MIC." add  


"is".


Section 5.1 nit: "A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA  


parameter if both parameters are missing then packet MUST be dropped  


as invalid." -> "A HIP DATA packet MUST contain either a SEQ_DATA or  


ACK_DATA parameter; if both parameters are missing, then the packet  


MUST be dropped as invalid."


Section 5.2 says "The receiver MUST validate these MICs."  It should  


also describe how to validate them, and S 5.3 would be a more  


appropriate place to detail that process.


Section 5.2 says " ... no SEQ_DATA sequence number is reused before  


the receiver has closed the processing window for the previous packet  


using the same SEQ_DATA sequence number."  Important question: what  


enables the receiver to tell the difference?   I assume that there are  


some other fields (e.g. nonces) associated with the connection that  


might serve this purpose; if that is right, I suggest documenting that  


fact.



regards,
David