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

Jan Melen <jan.melen@ericsson.com> Thu, 01 July 2010 13:02 UTC

Return-Path: <jan.melen@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DEA3A67EA; Thu, 1 Jul 2010 06:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.87
X-Spam-Level:
X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or7X1xNl9S4O; Thu, 1 Jul 2010 06:02:12 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 60DE63A67D0; Thu, 1 Jul 2010 06:02:10 -0700 (PDT)
X-AuditID: c1b4fb39-b7ceaae000004c90-33-4c2c91dd28c5
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.89.19600.DD19C2C4; Thu, 1 Jul 2010 15:02:21 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 15:02:21 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 15:02:20 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CD3A2372; Thu, 1 Jul 2010 16:02:20 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 438D14F268; Thu, 1 Jul 2010 16:02:20 +0300 (EEST)
Received: from esealmw967.eemea.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9ECB04E74E; Thu, 1 Jul 2010 16:02:19 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary=Apple-Mail-55--965571591; protocol="application/pkcs7-signature"; micalg=sha1
From: Jan Melen <jan.melen@ericsson.com>
In-Reply-To: <E14135F5-C08E-4B8E-A5C4-670C892A814D@cisco.com>
Date: Thu, 1 Jul 2010 16:02:18 +0300
Message-Id: <FD1ABD5D-E552-418F-9A0D-1F89B2E33395@ericsson.com>
References: <E14135F5-C08E-4B8E-A5C4-670C892A814D@cisco.com>
To: David McGrew <mcgrew@cisco.com>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 01 Jul 2010 13:02:20.0887 (UTC) FILETIME=[A425AE70:01CB191D]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Thu, 01 Jul 2010 06:04:23 -0700
Cc: "draft-ietf-hip-hiccups.all@tools.ietf.org" <draft-ietf-hip-hiccups.all@tools.ietf.org>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-hip-hiccups-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 13:02:14 -0000

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