Re: [secdir] Review of draft-ietf-hip-hiccups-02

[Jan Melen <[e-mail]>]

Hi,

Now -03 version is available and this should address all your previously identified concerns:
http://datatracker.ietf.org/doc/draft-ietf-hip-hiccups/

  Regards,
    Jan

On Jul 1, 2010, at 4:02 PM, Jan Melen wrote:

> 
> Thanks for review. I will submit a new version as soon as I have gone through all the other review comments from other reviewers.
> 
> On Jun 15, 2010, at 12:38 AM, David McGrew wrote:
> 
>> 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.
>> 
> 
> Changed as proposed
> 
> 
>> 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)?
> 
> 
> Replaced with collision-resistance and added preimage requirements to security considerations.
> 
> 
>> 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 "
> 
> Done
> 
>> 
>> Section 4.1.  I suggest emphasizing the requirement for the "Sequence  
>> Number" fields in distinct SEQ_DATA parameters to be distinct.
>> 
> 
> Done
> 
>> 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.
>> 
> 
> Added to 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.
> 
> Done
> 
>> Section 4.3 nit: "Identifies the data that protected by this MIC." add  
>> "is".
> 
> Done.
> 
>> 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."
> 
> Done.
> 
>> 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.
> 
> That is already defined in 5.3.1 so I added reference to that.
> 
> 
>> 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.
> 
> It can be easily checked by comparing the MIC value and I added also a statement on that to section 5.3.1.
> 
>   Regards,
>     Jan
> 
>