From hipsec-admin@honor.trusecure.com Fri Oct 1 03:22:18 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01563 for ; Fri, 1 Oct 2004 03:22:18 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 951967365; Fri, 1 Oct 2004 02:14:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id 6EF737335 for ; Fri, 1 Oct 2004 02:13:46 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 6356F212CA3; Fri, 1 Oct 2004 10:21:22 +0300 (EEST) Message-ID: <415D056C.2070707@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yogesh Prem Swami Cc: ext Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> In-Reply-To: <414DF55F.7020802@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 01 Oct 2004 10:21:16 +0300 Date: Fri, 01 Oct 2004 10:21:16 +0300 Content-Transfer-Encoding: 7bit Yogesh Prem Swami wrote: > Okay, the minimal changes required in the present HIP key exchange is > to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in > the HMAC of message 4 (shown in the message exchange below). Note > that the present protocol in the draft looks fairly secure, but as SIGMA > paper points out encryption is not the right method to prove possession > of session key (but the attack that the paper describes in the presence > of stream cipher doesn't apply here). So while the encrypted token > { PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token > guarantees that identity mis-binding attack cannot be carried out, > it's still better to use HMAC, IMO. (Besides we have a proof that > HMAC based scheme is secure.) > > I have also added nonce-I and nonce-R in all these message. This is > important to allow parallel SA creation, and allow cases where both > initiator and responder choose pre computed g^i and g^r (this can > happen, unless the draft explicitly prevents it). The nonce should > be used in deriving the session keys. Currently we have the ECHO REQ/REPLY in R1/I2. This nonce would replace it. Any opinions on this list? > So the key exchange with minimum change should look something like: > > 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > > 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > SIG( HIT-R, g^r, PUBLIC_KEY-R) > > > 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > SIG( HIT-I, HIT-R, SPI, g^i, > { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > > 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > has changed */ > According to the new HMAC stuff (including NONCE parameter instead of ECHO parameters), packets would look something like: NONCE parameter contains both nonce-I and nonce-R values, zero if not available. HOST_ID contains both the PUBLIC_KEY and the Domain-ID I1: IP ( HIP ( NONCE ) ) R1: IP ( HIP ( NONCE, [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, HOST_ID, HIP_SIGNATURE_2 )) R1 signature: HIP packet with the following fields zeroed: HIT-I, header checksum and Random #I. NONCE also zeroed to support precreated R1s? I2: IP ( HIP ( NONCE, SPI, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, HIP_SIGNATURE, HMAC ) ) I2 signature: everything covered I2 HMAC: (g^xy, HIT-I, HOST_ID(initiator) ) R2: IP ( HIP ( NONCE, SPI, HMAC, HIP_SIGNATURE ) ) R2 HMAC: (g^xy, HIT-R, SPI-R, HOST_ID(responder) ) > Couple of observations about this key exchange: > > A) The identity of Responder cannot be concealed even against the > passive attack. The HOST_ID in message-2 is required so that the > Initiator can get the public-key to verify the SIGNATURE from > responder. > > B) The identity of Initiator cannot be concealed against an active > attacker unless g^r is covered in SIGNATURE calculation in > message-2. (So keep section-7 description and change section-4 text) > > (A) and (B) together means that if we want to get responders ID > protection then we need to severely reorganize the messages. I think that at this point we are not willing to make radical changes. Any opinions? > > Yogesh _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 1 05:24:13 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09459 for ; Fri, 1 Oct 2004 05:24:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 40E257341; Fri, 1 Oct 2004 04:16:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id AC3FA7335 for ; Fri, 1 Oct 2004 04:15:19 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 8B6E1212CA3 for ; Fri, 1 Oct 2004 12:23:00 +0300 (EEST) Message-ID: <415D21ED.1040205@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Basehip: pre1 version of 01 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 01 Oct 2004 12:22:53 +0300 Date: Fri, 01 Oct 2004 12:22:53 +0300 Content-Transfer-Encoding: 7bit I uploaded the pre1 version of basehip draft -01 to our server. There are some editions since 00. See the diff-file. http://hip4inter.net/drafts.php BR, Petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From ticsa-info-admin@honor.trusecure.com Fri Oct 1 06:08:59 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13111 for ; Fri, 1 Oct 2004 06:08:58 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 085FB73D3 for ; Fri, 1 Oct 2004 05:00:48 -0400 (EDT) Date: Fri, 01 Oct 2004 05:00:47 -0400 Message-ID: <20041001090047.18899.11391.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: probertson@trusecure.com To: hip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: ticsa-info-admin@honor.trusecure.com Errors-To: ticsa-info-admin@honor.trusecure.com X-BeenThere: ticsa-info@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk This is a reminder, sent out once a month, about your honor.trusecure.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hipsec-request@honor.trusecure.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to probertson@trusecure.com. Thanks! Passwords for hip-archive@lists.ietf.org: List Password // URL ---- -------- hipsec@honor.trusecure.com fewefo http://honor.trusecure.com/mailman/options/hipsec/hip-archive%40lists.ietf.org From hipsec-admin@honor.trusecure.com Fri Oct 1 12:20:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19615 for ; Fri, 1 Oct 2004 12:20:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0A37D733A; Fri, 1 Oct 2004 11:12:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 2EB467330 for ; Fri, 1 Oct 2004 11:11:36 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA20454; Fri, 1 Oct 2004 09:19:07 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i91GJ5307719; Fri, 1 Oct 2004 11:19:06 -0500 (CDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 09:18:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> Thread-Topic: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward Thread-Index: AcSnh1JtgV+m+iMTRiqDcnbt4WUKigARKHnQ From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" , "Yogesh Prem Swami" Cc: "ext Pekka Nikander" , X-OriginalArrivalTime: 01 Oct 2004 16:18:59.0256 (UTC) FILETIME=[5B74AB80:01C4A7D2] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 1 Oct 2004 09:18:58 -0700 Date: Fri, 1 Oct 2004 09:18:58 -0700 Content-Transfer-Encoding: quoted-printable A couple of questions about this nonce: - Does including the nonce in R1 affect the R1 properties of being stateless, precomputed? - One motivation for the nonce is for allowing parallel SA creation. Yogesh's example was having 3 different SAs between the same hosts at the same time, for three different TCP connections. How does this work after all of the HIP SAs are set up? It seems you need to use port numbers then to disambiguate which packets flow into which SAs/SPI. Would the port numbers need to be included in the HIP exchange, or how does the responding side (for example) know the specifics of how to set up its SAs and policies? -Jeff > > I have also added nonce-I and nonce-R in all these message. This is > > important to allow parallel SA creation, and allow cases where both > > initiator and responder choose pre computed g^i and g^r (this can > > happen, unless the draft explicitly prevents it). The nonce should > > be used in deriving the session keys. >=20 > Currently we have the ECHO REQ/REPLY in R1/I2. This nonce=20 > would replace=20 > it. Any opinions on this list? _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 00:56:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02392 for ; Tue, 5 Oct 2004 00:56:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id BABBF7302; Mon, 4 Oct 2004 23:48:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id BDF5772F4 for ; Mon, 4 Oct 2004 23:47:39 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA08822 for ; Mon, 4 Oct 2004 21:55:43 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i954tg305354 for ; Mon, 4 Oct 2004 23:55:43 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 21:55:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Thread-Topic: draft-ietf-hip-mm-pre to post Thread-Index: AcSqk+4cjhegfKdUQISdZCbU6+JCgQAAx7eA From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 05 Oct 2004 04:55:42.0352 (UTC) FILETIME=[910C9100:01C4AA97] Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 4 Oct 2004 21:55:41 -0700 Date: Mon, 4 Oct 2004 21:55:41 -0700 Content-Transfer-Encoding: quoted-printable I plan to submit this draft as WG version -00 in a few days, but have put it up for any early comments: http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt I have tried to address the issues that people have raised on the list, and issues that have been discovered upon implementing the previous draft version. Below is a summary of open issues: Update on HIP mobility management open issues --------------- Note: The first four issues are logged at the issue tracker. The remainder are issues that have arisen during revision of the text, and open issues raised on the mailing list. On the hip-mm issue tracker, I would suggest to keep issues 1, 2, and 3 open, close issue 4, and add 6, 10, and 11 (below) to the issue tracker. 1. (Roundup issue tracker #1): Potential conflict in updating SPI values Suggested resolution: Keep open. This issue pertains to whether=20 we can abandon the address group abstraction. We agreed to leave it open until we had more insight. 2. (Roundup issue tracker #2): Problems with middleboxes Suggested resolution: Keep open. Middlebox traversal needs to be considered more carefully before this issue can be closed. For example, should one-way REAs be deprecated? 3. (Roundup issue tracker #3): address check RR design Suggested resolution: Keep open. The use of ECHO_REQUEST/REPLY has plugged the main issue raised here, but additional work ongoing in mobike and multi6 design team on failover detection and validation of alternate addresses that may apply also to HIP. 4. (Roundup issue tracker #4): Use of multiple SAs Suggested resolution: Close this issue (resolved). 5. REA parameter type is "to be defined" Suggested resolution: Tentatively, we have used the value "3" in our implementation. The desire has been to keep REA forward in the list of parameters, to make middlebox parsing easier. Whether REA should precede SPI (value "1") or vice versa might be debatable. =20 6. Bidirectionality of NES conflicting with unidirectionality of SAs and REA in multihoming case Mika has suggested in a recent mail that, when there are multiple SAs in a REA, and REA is paired with NES, that it can become ambiguous as to which SA should be rekeyed upon receipt of a REA/NES. Suggested resolution: Add a note to the text that, in the case of multihoming with multiple SAs, it is RECOMMENDED to associate SAs in pairs, and that when a NES is received for a particular SA, the peer should rekey the paired SA. Also, state that using asymmetrically set up SAs is experimental,=20 and may fail to interoperate. Also, issue should be opened in issue tracker. 7. The issue was raised on the list whether there needs to be an API to allow an application to select the source or destination IP address when there are multiple choices. Suggested resolution: Should be left outside of the draft, or discussed in an appendix. For now, there is no proposed text that would address this issue. =20 8. Discussion on the use of multihomed SAs for load balancing Suggested resolution: There are many unsolved issues with respect to load balancing across multiple addresses. For now,=20 we recommend that multihoming is just used/specified for=20 failover purposes, although experimentation is recommended. 9. If HIP negotiates base exchange using link locals, and one host moves, it will not be able to find its peer Suggested resolution: State that a host SHOULD provide its peer with a globally reachable IP address instead of relying exclusively on link-local addresses. 10. Should REA be included in R2 or R1 (R1 is presently specified in text)? Note that there is some conflict in saying that, when REA=20 is included in R1 and it includes a new preferred address,=20 that the puzzle solution MUST be valid for both responder=20 addresses. The conflict is in using Appendix D (base spec)=20 mapping functions. Suggested resolution: Open, but leaning towards recommending inclusion in R2 instead of R1, unless the reason for putting it in R1 is (re)discovered. Also, issue should be opened in issue tracker. 11. Use of SPI parameter when REA is present-- is it necessary? Suggested resolution: Open until middlebox implications are better understood. Also, issue should be opened in issue tracker. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 03:14:40 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27252 for ; Tue, 5 Oct 2004 03:14:39 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3F02D7305; Tue, 5 Oct 2004 02:06:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id CEDB67304 for ; Tue, 5 Oct 2004 02:05:36 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1F8C12E07; Tue, 5 Oct 2004 10:12:19 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i957DgX18523; Tue, 5 Oct 2004 10:13:42 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 10:13:42 +0300 (EEST) Date: Tue, 5 Oct 2004 10:13:42 +0300 (EEST) On Mon, 4 Oct 2004, Henderson, Thomas R wrote: > 9. If HIP negotiates base exchange using link locals, and one > host moves, it will not be able to find its peer > > Suggested resolution: State that a host SHOULD provide its > peer with a globally reachable IP address instead of relying > exclusively on link-local addresses. (the same goes for site-local addresses) > 10. Should REA be included in R2 or R1 (R1 is presently > specified in text)? > > Note that there is some conflict in saying that, when REA > is included in R1 and it includes a new preferred address, > that the puzzle solution MUST be valid for both responder > addresses. The conflict is in using Appendix D (base spec) > mapping functions. > > Suggested resolution: Open, but leaning towards recommending > inclusion in R2 instead of R1, unless the reason for putting > it in R1 is (re)discovered. > > Also, issue should be opened in issue tracker. I'd vote for the inclusion in the R2. This way, the R1s don't have to be prebuilt every time the responder moves. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 03:37:40 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29068 for ; Tue, 5 Oct 2004 03:37:39 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 755D77305; Tue, 5 Oct 2004 02:29:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 662C17304 for ; Tue, 5 Oct 2004 02:28:55 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 21FE83239; Tue, 5 Oct 2004 10:35:38 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i957b2q20034; Tue, 5 Oct 2004 10:37:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Cc: Yogesh Prem Swami , ext Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <415D056C.2070707@nomadiclab.com> Message-ID: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <415D056C.2070707@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 10:37:01 +0300 (EEST) Date: Tue, 5 Oct 2004 10:37:01 +0300 (EEST) On Fri, 1 Oct 2004, Petri Jokela wrote: > > I have also added nonce-I and nonce-R in all these message. This is > > important to allow parallel SA creation, and allow cases where both > > initiator and responder choose pre computed g^i and g^r (this can > > happen, unless the draft explicitly prevents it). The nonce should > > be used in deriving the session keys. > > Currently we have the ECHO REQ/REPLY in R1/I2. This nonce would replace > it. Any opinions on this list? Seems like this won't affect the stateliness of responder, so I guess the change is ok. > > Couple of observations about this key exchange: > > > > A) The identity of Responder cannot be concealed even against the > > passive attack. The HOST_ID in message-2 is required so that the > > Initiator can get the public-key to verify the SIGNATURE from > > responder. > > > > B) The identity of Initiator cannot be concealed against an active > > attacker unless g^r is covered in SIGNATURE calculation in > > message-2. (So keep section-7 description and change section-4 text) > > > > (A) and (B) together means that if we want to get responders ID > > protection then we need to severely reorganize the messages. > > I think that at this point we are not willing to make radical changes. > Any opinions? Agree. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 06:22:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11150 for ; Tue, 5 Oct 2004 06:22:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E019F7304; Tue, 5 Oct 2004 05:14:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id BD55B72F2 for ; Tue, 5 Oct 2004 05:13:32 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i95ALcd6008878 for ; Tue, 5 Oct 2004 13:21:38 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 13:21:38 +0300 (EEST) Date: Tue, 5 Oct 2004 13:21:38 +0300 (EEST) One possible Denial of Service attack occurred in my mind: A host could fake a creation of a new SA causing resource consumption at the peer host. Host A sends UPDATEs according to section 5.2 Host multihoming, REA containing addresses as much as there are room in the UPDATE, NES with Old SPI=New SPI=some_index, and of course SEQ. Actually host A does not create any SAs, it just sets the SPI value. Then assume that host A is able to respond to B from the addresses included in the REA when B will be sending reply UPDATEs. When the peer host B receives the UPDATE, it thinks that the peer has really created a new SA, so it stores the addresses (memory usage) and creates a new SA (heavy operation, memory usage), and acknowledges the A's UPDATE. Then A acknowledges the B's UPDATE. At this time B is quite surely finished creating the SA, and it starts verifying the addresses. Now the evil host A repeats the procedure, with the only difference of just increasing the index number in NES. B creates again a new SA and stores the addresses. Repeat this for a long time and host B is out of memory. Surely host B will free the memory reserved for the addresses under verification, if it will not receive any ACKs for them. This will still be slower than A's ability to allocate B's memory using fake UPDATEs. Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs allowed (send NOTIFY if SA was not created ?). _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 06:45:39 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12888 for ; Tue, 5 Oct 2004 06:45:39 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8F8FF7304; Tue, 5 Oct 2004 05:37:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id 1F8F372F2 for ; Tue, 5 Oct 2004 05:36:23 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i95AiUd6031823 for ; Tue, 5 Oct 2004 13:44:31 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 13:44:30 +0300 (EEST) Date: Tue, 5 Oct 2004 13:44:30 +0300 (EEST) On Mon, 4 Oct 2004, Henderson, Thomas R wrote: -> 4. (Roundup issue tracker #4): Use of multiple SAs -> -> Suggested resolution: Close this issue (resolved). How was this resolved (I forgot..) ? The issue tracker shows only one posting about this issue. From the issue tracker #4: "is there still a need to create a new SA for each new address put in use?". Why create separate SAs even for the IP addresses ? If each address would have its own SA and therefore own SPI, how can you assign them to SPI groups as in Figure 2 ? Somehow I think creating one SA per one peer address is overkill. I've been playing with "same SA for all addresses belonging to the same SPI", as in Figure 2. I have managed to create multiple simultaneous SAs, but I do not have support for REAs yet. -> 6. Bidirectionality of NES conflicting with unidirectionality -> of SAs and REA in multihoming case -> -> Mika has suggested in a recent mail that, when there are -> multiple SAs in a REA, and REA is paired with NES, that -> it can become ambiguous as to which SA should be rekeyed -> upon receipt of a REA/NES. -> -> Suggested resolution: Add a note to the text that, in the -> case of multihoming with multiple SAs, it is RECOMMENDED to -> associate SAs in pairs, and that when a NES is received for -> a particular SA, the peer should rekey the paired SA. -> Also, state that using asymmetrically set up SAs is experimental, -> and may fail to interoperate. -> -> Also, issue should be opened in issue tracker. I would like to see what is the definition for a "paired SA". How it is related to the peer's SAs and how it is associated when a new SA is created. -> 11. Use of SPI parameter when REA is present-- is it necessary? I have no experience yet. -> Suggested resolution: Open until middlebox implications are -> better understood. -> -> Also, issue should be opened in issue tracker. Then we would have SPIs in three places in the same packet. REA, NES, and SPI. Messy ? Also the SPI selection algorithm for the parameter would be nice. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 09:03:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24469 for ; Tue, 5 Oct 2004 09:03:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AE91E7304; Tue, 5 Oct 2004 07:55:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id 8333672F2 for ; Tue, 5 Oct 2004 07:54:13 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i95D2Ld6005250 for ; Tue, 5 Oct 2004 16:02:22 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 16:02:21 +0300 (EEST) Date: Tue, 5 Oct 2004 16:02:21 +0300 (EEST) Comments on address verification: Looks like there is a lot of text which assume the situation as if there is always only one address listed in the REA. That causes misinterpretation (for me at least) in sentences such as: -Section 4.2 Address verification, "A simple technique to verify addresses is to send an UPDATE to the host at the new address." and "If the peer host is rekeying by sending an UPDATE with NES to the new address, the arrival of data on the new SPI can also be used to verify the address." Does this verify the reachability of all addresses listed in the REA ? No. Shouldn't this be "For each of the listed addresses in the REA, .." ? Something like in draft mm-00 section 4.3 Address verification: "To acknowledge that it has received the REA, and to initiate an address check, the HIP host receiving a REA immediately sends an AC to all addresses mentioned in the REA." -Section 5.1 Mobility with single SA pair, "Upon obtaining a new IP address, the mobile host sends a REA parameter to the peer host in an UPDATE message. The REA indicates the following: the new IP address, the SPI associated with the new IP address, the address lifetime, and whether the new address is a preferred address. .. The UPDATE messages sent from the peer back to the mobile are sent to the newly advertised address." And the "newly advertised address" is defined here as .. ? Preferred address in the REA, if there is any (and what if not) ? All of the addresses ? Hmm..but wait..ahh..the reader must notice the word "messages", so by deduction this section should also say "for all of the addresses a separate UPDATE is sent by the peer..", right ? _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 10:34:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03736 for ; Tue, 5 Oct 2004 10:34:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DB5A07304; Tue, 5 Oct 2004 09:26:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by honor.icsalabs.com (Postfix) with ESMTP id 8A00E72F2 for ; Tue, 5 Oct 2004 09:25:48 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i95EXtVF013394 for ; Tue, 5 Oct 2004 17:33:55 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 17:33:55 +0300 (EEST) Date: Tue, 5 Oct 2004 17:33:55 +0300 (EEST) In section 5.1 Mobility with single SA pair, "Readdress without rekeying, but with address check": When a mobile hosts sends UPDATE(REA, SEQ) (Figure 3), must it be processed in any state (established or rekeying) ? How it should be processed upon receive ? Can we skip some tests mentioned in the base draft's section 8.11 Processing UPDATE packets ? _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 14:46:45 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24609 for ; Tue, 5 Oct 2004 14:46:45 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AEBB2731A; Tue, 5 Oct 2004 13:38:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 2DCD37319 for ; Tue, 5 Oct 2004 13:37:42 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 45ECA220007; Tue, 5 Oct 2004 21:45:45 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id C6C108; Tue, 5 Oct 2004 21:45:45 +0300 (EEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review To: Mika Kousa X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 5 Oct 2004 21:45:52 +0300 Date: Tue, 5 Oct 2004 21:45:52 +0300 Content-Transfer-Encoding: 7bit > One possible Denial of Service attack occurred in my mind: I don't find this very serious. Firstly, the host must be already communicating in order for this to happen. Hence, there should be some minimum level of trust between the hosts. Secondly, creating an SA is not that heavy since it does not involve any public key crypto, just hash functions in order to generate new key material. > Solutions: rate limit UPDATE handling, mamimum amount of simultaneous > SAs > allowed (send NOTIFY if SA was not created ?). I agree that each implementation should have some sensible, configurable limit of how many SAs it by default is creating for peer hosts. I think something like 5 should be more than enough for the time being. Anyway, I think it would be good to have a brief explanation of this in the Security Considerations section, with a RECOMMENDATION of having an upper bound for parallel SAs per host, with some RECOMMENDED default value. Would you Mika be willing to write some raw text? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 5 19:41:47 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24522 for ; Tue, 5 Oct 2004 19:41:46 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 34E52730D; Tue, 5 Oct 2004 18:33:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by honor.icsalabs.com (Postfix) with ESMTP id 41530730A for ; Tue, 5 Oct 2004 18:32:38 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-2.hut.fi (8.12.10/8.12.10) with ESMTP id i95NeltY021789 for ; Wed, 6 Oct 2004 02:40:47 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Oct 2004 02:40:47 +0300 (EEST) Date: Wed, 6 Oct 2004 02:40:47 +0300 (EEST) On Tue, 5 Oct 2004, Pekka Nikander wrote: -> > One possible Denial of Service attack occurred in my mind: -> -> I don't find this very serious. Firstly, the host must be -> already communicating in order for this to happen. Hence, -> there should be some minimum level of trust between the hosts. Surely, but by assumption the evil host is willing to spend some cpu time needed for the base exchange. After a couple of seconds it can launch this long lasting attack against the victim. Compared to the effects this causes, the cpu power needed for the base exchange is close to zero. A really naive implementation might assume that if the base exchange was successful, then the rest of the communication could be consired as trustworthy. -> Secondly, creating an SA is not that heavy since it does not -> involve any public key crypto, just hash functions in order -> to generate new key material. Ah, all right then. But anyway, creation and updating SAs need quite a lot more resources elsewhere than just on HIP level, SA related stuff in the kernel etc. -> > Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs -> > allowed (send NOTIFY if SA was not created ?). -> -> I agree that each implementation should have some sensible, -> configurable limit of how many SAs it by default is creating -> for peer hosts. I think something like 5 should be more than -> enough for the time being. Assuming that each interface has its own SA, as described in the current draft, this might be sufficient. But if we follow the proposals which suggest own SA for each of the (IP) addresses, five might be too low. I do not know so much about real life situations, such as how many addresses some busy host might have at a time. Five SAs is probably sufficient for 99% of the time. Limit could also be dynamic, e.g. based on the trust. That is, policy issue. -> Anyway, I think it would be good to have a brief explanation -> of this in the Security Considerations section, with a -> RECOMMENDATION of having an upper bound for parallel SAs per -> host, with some RECOMMENDED default value. -> -> Would you Mika be willing to write some raw text? Let's see if I can write some short text about this issue during this week, something like we have been discussing right now. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 6 07:52:50 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15323 for ; Wed, 6 Oct 2004 07:52:49 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5CEFE7309; Wed, 6 Oct 2004 06:44:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 47BB972E0 for ; Wed, 6 Oct 2004 06:43:33 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 4BC87220009; Wed, 6 Oct 2004 14:51:47 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E316C8; Wed, 6 Oct 2004 14:51:47 +0300 (EEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review To: Mika Kousa X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Oct 2004 14:51:55 +0300 Date: Wed, 6 Oct 2004 14:51:55 +0300 Content-Transfer-Encoding: 7bit > Ah, all right then. But anyway, creation and updating SAs need quite a > lot > more resources elsewhere than just on HIP level, SA related stuff in > the > kernel etc. Depending on implementation that may or may not be that much. > Five SAs is probably sufficient for 99% of the time. Agreed. We need some conservative default; hence the suggestion for five. > Limit could also be dynamic, e.g. based on the trust. That is, policy > issue. Sure. The text should reflect this, being suggestive and outlining some sensible default values. > -> Would you Mika be willing to write some raw text? > > Let's see if I can write some short text about this issue during this > week, something like we have been discussing right now. Good! --Pekka PS. If you want me to react to your mail quickly, even if it is a mailing list reply, please make the To: directly to me (or at least CC: me). Otherwise my filters will direct it to a separate folder, and it may take a few days before I read it. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 6 10:24:49 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01233 for ; Wed, 6 Oct 2004 10:24:48 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 01F8172E6; Wed, 6 Oct 2004 09:16:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by honor.icsalabs.com (Postfix) with ESMTP id 6015572E0 for ; Wed, 6 Oct 2004 09:15:45 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id i96ENwF6025135 for ; Wed, 6 Oct 2004 17:23:59 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Oct 2004 17:23:58 +0300 (EEST) Date: Wed, 6 Oct 2004 17:23:58 +0300 (EEST) A conflict in 5th paragraph of section 7.1 Sending REAs: "All addresses corresponding to the SPI have the same lifetime." But the rest of the discussion on address lifetimes tells that each address have their own lifetimes. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 6 13:25:49 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14920 for ; Wed, 6 Oct 2004 13:25:48 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D869E72E6; Wed, 6 Oct 2004 12:17:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 8D1AA72E0 for ; Wed, 6 Oct 2004 12:16:10 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA12598 for ; Wed, 6 Oct 2004 10:24:24 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i96HOOs20494 for ; Wed, 6 Oct 2004 10:24:24 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 10:24:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> Thread-Topic: (corrected) preview of draft-ietf-hip-mm-00 for review Thread-Index: AcSqk+4cjhegfKdUQISdZCbU6+JCgQAAx7eAAExXHLA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 06 Oct 2004 17:24:19.0728 (UTC) FILETIME=[504DF900:01C4ABC9] Subject: [Hipsec] (corrected) preview of draft-ietf-hip-mm-00 for review Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 6 Oct 2004 10:23:19 -0700 Date: Wed, 6 Oct 2004 10:23:19 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Henderson, Thomas R=20 > Sent: Monday, October 04, 2004 9:56 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review >=20 >=20 > I plan to submit this draft as WG version -00 in a few days, > but have put it up for any early comments: >=20 > http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt >=20 I made a mistake and provided Petri with only a partially updated draft. He has now posted the draft I originally intended to preview post (open issues list is the same): http://hip4inter.net/documentation/drafts/draft-ietf-hip-mm-00.txt Below are the diffs from what was originally posted-- I haven't yet processed the comments that have been coming on the list. Key to this diff file: < Previously posted, modified draft-nikanker-hip-mm-02 > Updated version at new URL above (draft-ietf-hip-mm-00) 12c12 < draft-nikander-hip-mm-02 --- > draft-ietf-hip-mm-00 350,352c350,352 < In the HIP base protocol specification [3], it is defined how two < hosts exchange their Host Identifiers and establish a pair of ESP < Security Associations (SA). =20 --- > The HIP base protocol specification [3] defines how two hosts > exchange their Host Identifiers and establish a pair of ESP = Security > Associations (SA). =20 528a529,531 > It is not specified how a host knows whether or not middleboxes = might > lie on its path, so a conservative assumption may be to always > include the SPI parameter. 544a547,553 > In general, when multiple addresses are used for a session, there = is > the question of using multiple addresses for failover only or for > load-balancing. Due to the implications of load-balancing on the > transport layer that still need to be worked out, this draft = assumes > that multiple addresses are used primarily for failover. An > implementation may use ICMP interactions, reachability checks, or > other means to detect the failure of an address. 639c639 < about changes of IP addresses on one of its SPIs. The readdressing --- > about changes of IP addresses on affected SPIs. The readdressing 744a745,748 > Hosts that use link-local addresses as source addresses in their = HIP > handshakes may not be reachable by a mobile peer host unless a > globally routable address is provided either in the initial = handshake > or via the REA parameter. 791c795 < implicitly affiliated with different addresses. --- > implicitly affiliated with different source addresses. 803a808,813 > When rekeying in a multihoming situation in which there is an > asymmetric number of SAs between two hosts, a respondent to the = NES/ > UPDATE procedure may have some ambiguity as to which inbound SA it > should update in response to the peer's UPDATE. In such a case, = the > host SHOULD choose an SA corresponding to the inbound interface on > which the UPDATE was received. 881,890d890 < 5.7 Initiating the protocol in R1 or I2 <=20 < A Responder host MAY include one or more REA parameters in the R1 < packet that it sends to the Initiator. These parameters MUST be < protected by the R1 signature. If the R1 packet contains REA < parameters, the Initiator SHOULD send the I2 packet to the new < preferred address. The Responder MUST make sure that the puzzle < solution is valid BOTH for the initial IP destination address used < for I1 and for the new preferred address. The I1 destination = address < and the new preferred address may be identical. 899a900,908 > 5.7 Initiating the protocol in R1 or I2 >=20 > A Responder host MAY include one or more REA parameters in the R1 > packet that it sends to the Initiator. These parameters MUST be > protected by the R1 signature. If the R1 packet contains REA > parameters, the Initiator SHOULD send the I2 packet to the new > preferred address. The I1 destination address and the new = preferred > address may be identical. >=20 1040c1096,1098 < each of them must be matched with a NES parameter: --- > and at least one of the REA parameters is matched with a NES > parameter, then each REA must be matched with a NES parameter, to > avoid ambiguity: 1112c1168 < a REA with the SPI field within the REA set to the new address, and --- > a REA with the SPI field within the REA set to the new SPI, and = also 1181a1238,1239 > 5. Mark all addresses at the address group that were NOT listed in > the REA parameter as DEPRECATED. 1252c1324 < ICMP erro messages arrive that deprecate the preferred address, --- > ICMP error messages arrive that deprecate the preferred = address, 1377c1433 < return routability check provides some assurance that the given --- > address reachability check provides some assurance that the given _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 6 21:01:53 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05681 for ; Wed, 6 Oct 2004 21:01:53 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0D8177322; Wed, 6 Oct 2004 19:53:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by honor.icsalabs.com (Postfix) with ESMTP id 158677310 for ; Wed, 6 Oct 2004 19:52:47 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id i97113F6012983; Thu, 7 Oct 2004 04:01:03 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Cc: Pekka Nikander Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 04:01:03 +0300 (EEST) Date: Thu, 7 Oct 2004 04:01:03 +0300 (EEST) Here is the initial text to the Security Considerations section I wrote about the issue on maximum allowed outbound SAs. I'm not so familiar with the correct usage of these capitalized RECOMMENDED/SHOULD/MUST/etc. words, but you might want to edit this text anyway. The text digests the mailing list discussion, nothing new was added. When a host has an additional network interface to use, the host might want to inform its peer about it by sending the SPI of the newly created SA associated with the network interface. Consequently, information on this SA must also be stored in the peer host. Because this operation requires allocation and usage of limited resources, such as memory and cpu, it is RECOMMENDED that there is an upper bound limit for the number of simultaneous outgoing SAs a host is willing to create. Because the exact number of network interfaces the peer host could have is usually not known in advance, it is RECOMMENDED that this value is configurable during runtime or at least at compile time. The suggested RECOMMENDED default value of five (5) maximum outbound SAs is assumed to be enough for most of the situations. In general, the value depends on enforced policy and the level of trust a host has against its peer host. Lower level of trust SHOULD decrease the maximum value. For trusted systems the value could even be unlimited, but this is highly NOT RECOMMENDED. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 01:35:54 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26558 for ; Thu, 7 Oct 2004 01:35:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D86D27310; Thu, 7 Oct 2004 00:27:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id E58F472E6 for ; Thu, 7 Oct 2004 00:26:30 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id AB175220003; Thu, 7 Oct 2004 08:34:45 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 1D8668; Thu, 7 Oct 2004 08:34:46 +0300 (EEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D810CBE-1822-11D9-BF2A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] preview of draft-ietf-hip-mm-00 for review To: Mika Kousa X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 08:34:53 +0300 Date: Thu, 7 Oct 2004 08:34:53 +0300 Content-Transfer-Encoding: 7bit > Here is the initial text to the Security Considerations section I wrote > about the issue on maximum allowed outbound SAs. I'm not so familiar > with > the correct usage of these capitalized RECOMMENDED/SHOULD/MUST/etc. > words, > but you might want to edit this text anyway. The text digests the > mailing > list discussion, nothing new was added. Tnx. A slightly edited version below. --Pekka Managing multiple outgoing Security Associations for a peer host consumes some memory and also some CPU resources. Because the HIP protocol has been designed to support communication with peer hosts that are not fully trusted, there SHOULD be a means to limit the amount of resources reserved per any given peer. In particular, it is RECOMMENDED that there is a total upper bound limit and a per-peer upper bound limit for the number of simultaneous outgoing SAs a host is willing to create. Because the exact number of network interfaces a given peer host could have is usually not known in advance, it is RECOMMENDED that the upper limit values be user configurable. The RECOMMENDED default value of five (5) outbound SAs per peer host is assumed to be enough for most of the situations. In general, the value depends on the enforced policy and the level of trust a host has against the given peer host. Lower level of trust, e.g. HIP associations with hosts using non-public keys, MAY decrease the maximum value. For trusted systems the upper bound may be increased or even lifted. To support smooth handovers, the upper bound MUST always be at least two (2). [Rationale for the keywords: In general, these advice deal with local resource consumption, and do not directly affect interoperability. However, hosts that have a high number of IP addresses may need to be aware of these recommendations, in order to better react to their peer's behaviour. (The peer may be limiting the number of SAs.) Not following the advice may lead to DoS vulnerabilities, hence the RECOMMENDATION. On the other hand, decreasing the default value may lead to interoperability problems if the other host is expecting the default upper bound of five. Hence the MAY for reducing the upper bound, and MUST for at least two outgoing SAs per host.] _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 02:52:54 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15593 for ; Thu, 7 Oct 2004 02:52:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1F98B7310; Thu, 7 Oct 2004 01:44:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by honor.icsalabs.com (Postfix) with ESMTP id F239172E6 for ; Thu, 7 Oct 2004 01:43:53 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i976q7RU002379 for ; Thu, 7 Oct 2004 08:52:08 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 08:52:07 +0200 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J5M6NK6; Thu, 7 Oct 2004 08:52:07 +0200 Received: from ericsson.com (EFO9N000L5C7100.lmf.ericsson.se [131.160.31.224]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1E47318AAA; Thu, 7 Oct 2004 09:52:07 +0300 (EEST) Message-ID: <4164E796.6030603@ericsson.com> X-Sybari-Trust: 5848fa3f 74898554 21fb9c7e 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: David Ward , Pekka Nikander , Thomas Henderson Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2004 06:52:07.0906 (UTC) FILETIME=[29970420:01C4AC3A] Subject: [Hipsec] Agenda requests Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 09:52:06 +0300 Date: Thu, 07 Oct 2004 09:52:06 +0300 Content-Transfer-Encoding: 7bit Folks, we are officially starting to gather agenda requests for the HIP WG meeting in Washington. You should send your agenda request to the chairs indicating what you want to present, any related documents, and how long you want your agenda-slot to be. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 03:53:55 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20545 for ; Thu, 7 Oct 2004 03:53:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 331377310; Thu, 7 Oct 2004 02:45:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id D93A872E6 for ; Thu, 7 Oct 2004 02:44:05 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id AB2E2212C72; Thu, 7 Oct 2004 10:52:21 +0300 (EEST) Message-ID: <4164F590.9040204@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Cc: "Ahrenholz, Jeffrey M" , Yogesh Prem Swami References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] NONCE parameter in base exchange? Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 10:51:44 +0300 Date: Thu, 07 Oct 2004 10:51:44 +0300 Content-Transfer-Encoding: 7bit Ahrenholz, Jeffrey M wrote: > A couple of questions about this nonce: > > - Does including the nonce in R1 affect the R1 properties of being > stateless, precomputed? As far as I can see, it doesn't affect. > - One motivation for the nonce is for allowing parallel SA creation. > Yogesh's example was having 3 different SAs between the same hosts at > the same time, for three different TCP connections. How does this work > after all of the HIP SAs are set up? It seems you need to use port > numbers then to disambiguate which packets flow into which SAs/SPI. > Would the port numbers need to be included in the HIP exchange, or how > does the responding side (for example) know the specifics of how to set > up its SAs and policies? So, creating multiple SAs would require some information change between the hosts about the usage of the connections. I think that it is not feasible to include it in HIP v1. A "hack" would be to use multiple HIs (HITs) for creating separate SAs between the hosts. Not a nice solution and solves the problem only from the Initiator point of view, but it wouldn't require any additional negotiation between the hosts. There are not too many opinions on this issue on the list? What shall we do with it: 1) add the NONCE parameter and remove ECHO REQ/RESP, 2) leave the draft as it is now and think this again in HIP v2. /petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 04:33:52 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23318 for ; Thu, 7 Oct 2004 04:33:52 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C9D4D7310; Thu, 7 Oct 2004 03:25:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id BD1DD72E6 for ; Thu, 7 Oct 2004 03:24:56 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i978XFil011251 for ; Thu, 7 Oct 2004 02:33:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I57006KFH3EKR@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 02:33:15 -0600 (MDT) Received: from [10.0.0.29] ([194.2.198.253]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5700LT0H3AT4@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 02:33:12 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] NONCE parameter in base exchange? In-reply-to: <4164F590.9040204@nomadiclab.com> To: hipsec@honor.trusecure.com Cc: Petri Jokela , "Ahrenholz, Jeffrey M" , Yogesh Prem Swami Message-id: <200410071033.29140.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 10:33:28 +0200 Date: Thu, 07 Oct 2004 10:33:28 +0200 Content-Transfer-Encoding: 7BIT On Thursday 07 October 2004 09:51, Petri Jokela wrote: > Ahrenholz, Jeffrey M wrote: > > A couple of questions about this nonce: > > > > - Does including the nonce in R1 affect the R1 properties of > > being stateless, precomputed? > > As far as I can see, it doesn't affect. > > > - One motivation for the nonce is for allowing parallel SA > > creation. Yogesh's example was having 3 different SAs between the > > same hosts at the same time, for three different TCP connections. > > How does this work after all of the HIP SAs are set up? It seems > > you need to use port numbers then to disambiguate which packets > > flow into which SAs/SPI. Would the port numbers need to be > > included in the HIP exchange, or how does the responding side > > (for example) know the specifics of how to set up its SAs and > > policies? > > So, creating multiple SAs would require some information change > between the hosts about the usage of the connections. I think that > it is not feasible to include it in HIP v1. I agree. > A "hack" would be to use multiple HIs (HITs) for creating separate > SAs between the hosts. Not a nice solution and solves the problem > only from the Initiator point of view, but it wouldn't require any > additional negotiation between the hosts. You can create separate SAs based on different NONCES, and then the hack is when an outbound packet enters ESP, the SA selection is made locally, based on Traffic Selectors including TCP/UDP ports for example, and not enforced by the ESP receivers, which hence doesn't need to be aware of the local TSs used by the ESP sender. This allows for separation of multiple connexions by the sender, without having to negociate TSs with TCP/UDP ports numbers in HIP itself. > There are not too many opinions on this issue on the list? What > shall we do with it: 1) add the NONCE parameter and remove ECHO > REQ/RESP, 2) leave the draft as it is now and think this again in > HIP v2. I would vote for adding NONCE, as it make HIP SIGMA-compliant, and keep ECHO_REQ/REP. IMHO this is a minor addition which buys us provable security by conforming to the SIGMA core protocol, so I believe we don't need to wait until v2 to handle NONCEs. My 2 cents, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 07:18:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04915 for ; Thu, 7 Oct 2004 07:18:56 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 301457310; Thu, 7 Oct 2004 06:10:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id 7A9F572E6 for ; Thu, 7 Oct 2004 06:09:29 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 48501212C72 for ; Thu, 7 Oct 2004 14:17:50 +0300 (EEST) Message-ID: <416525B8.6090604@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: " " Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] BaseHIP Issue #42 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 14:17:12 +0300 Date: Thu, 07 Oct 2004 14:17:12 +0300 Content-Transfer-Encoding: 7bit The key exchange described on page 12 of the base draft was a bit unclear. So, a new proposal: 4.1 HIP base exchange The base HIP exchange serves to manage the establishment of state between an Initiator and a Responder. During the exchange, an IPsec Security Association is created between the hosts. The last three packets of the exchange, R1, I2, and R2, constitute a standard authenticated Diffie-Hellman key exchange for session key generation. The Initiator first sends a trigger packet, I1, to the Responder. The packet contains only the HIT of the Initiator and possibly the HIT of the Responder, if it is known. The second packet, R1, starts the actual exchange. It contains a puzzle, that is, a cryptographic challenge that the Initiator must solve before continuing the exchange. In addition to that, it contains the initial Diffie-Hellman parameters and a signature, covering the message partly. Some fields are left outside the signature to support pre-created R1s. In I2 packet, the Initiator must display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 contains also Diffie-Hellman parameter that carries needed information for the Responder. The packet is signed by the sender. The R2 packet finalizes the 4-way handshake, containing the SPI value of the Responder. The packet is signed. The base exchange is illustrated below. During this D-H procedure, the hosts create an IPsec session key. Initiator Responder I1: trigger exchange --------------------------> select pre-computed R1 R1: puzzle, D-H, key, sig <------------------------- check sig remain stateless solve puzzle I2: solution, D-H, {key}, sig --------------------------> compute D-H check cookie check puzzle check sig R2: sig <-------------------------- check sig compute D-H In R1, the signature covers the packet, after setting the initiator HIT, header checksum as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any TLVs that follow the signature In I2, the signature covers the whole packet, excluding any TLVs that follow the signature. In R2, the signature and the HMAC covers the whole envelope. In this section we cover the overall design of the base exchange. The details are the subject of the rest of this memo. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 08:15:54 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09749 for ; Thu, 7 Oct 2004 08:15:53 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5BC597310; Thu, 7 Oct 2004 07:07:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by honor.icsalabs.com (Postfix) with ESMTP id 5FC2D72E6 for ; Thu, 7 Oct 2004 07:06:49 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id i97CF8F6023780 for ; Thu, 7 Oct 2004 15:15:08 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] (corrected) preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-1.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 15:15:08 +0300 (EEST) Date: Thu, 7 Oct 2004 15:15:08 +0300 (EEST) 5.7 Initiating the protocol in R1 or I2: Should there be some explicit notes about the KEYMAT index to be used when retrieving keying materials for the SA(s) if the R1 or I2 contains (multiple) REA(s) ? Or do we just assume that the implementors know what they are doing without telling them. That is, they use the current KEYMAT index right after when the HIP keys were drawn. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 09:20:55 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14640 for ; Thu, 7 Oct 2004 09:20:55 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B62DA7310; Thu, 7 Oct 2004 08:12:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by honor.icsalabs.com (Postfix) with ESMTP id A6AB172E6 for ; Thu, 7 Oct 2004 08:11:46 -0400 (EDT) Received: from amandier.inrialpes.fr (amandier.inrialpes.fr [194.199.18.76]) by ebene.inrialpes.fr (8.13.0/8.13.0) with ESMTP id i97DJrA1029251 for ; Thu, 7 Oct 2004 15:19:53 +0200 (MEST) Received: from [194.199.24.112] (roswell2.inrialpes.fr [194.199.24.112]) by amandier.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id i97DJpm04351 for ; Thu, 7 Oct 2004 15:19:52 +0200 (MEST) From: Julien Laganier Organization: SUN Microsystems, Inc. To: hipsec@honor.trusecure.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410071521.16054.julien.laganier@sun.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (ebene.inrialpes.fr [194.199.18.70]); Thu, 07 Oct 2004 15:19:53 +0200 (MEST) X-GOTHMOG-MailScanner: Found to be clean Envelope-From: julien.laganier@sun.com Envelope-To: hipsec@honor.trusecure.com Subject: [Hipsec] Digital Signature Algorithms Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 15:21:15 +0200 Date: Thu, 7 Oct 2004 15:21:15 +0200 Content-Transfer-Encoding: 7bit Hi Folks, Looking at the paper "Experience with the Host Identity Protocol for Secure Mobility and Multihoming" by Henderson et al., I found that DSA signing and verification account for a huge part of the association set-up latency. Hence, I am wondering what is the rationale for HIP to specify DSA as a MANDATORY algorithm, although RSA signatures verification might be ten times faster than DSA? Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) which has reduced P.K. and signatures size, and can be as fast or faster than RSA? Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 09:28:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15037 for ; Thu, 7 Oct 2004 09:28:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EAFB17310; Thu, 7 Oct 2004 08:20:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id B0CF272E6 for ; Thu, 7 Oct 2004 08:19:12 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 52F8E898A3; Thu, 7 Oct 2004 16:27:34 +0300 (EEST) Message-ID: <416543F8.6040006@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms References: <200410071521.16054.julien.laganier@sun.com> In-Reply-To: <200410071521.16054.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 16:26:16 +0300 Date: Thu, 07 Oct 2004 16:26:16 +0300 Content-Transfer-Encoding: 7bit There used to be IPR concerns with RSA, but I believe the patents expired. ECC is a mine field of IPR, so I'd rather stay out of it if possible. I'd go for RSA, personally. --Jari Julien Laganier wrote: > Hi Folks, > > Looking at the paper "Experience with the Host Identity Protocol for > Secure Mobility and Multihoming" by Henderson et al., I found that > DSA signing and verification account for a huge part of the > association set-up latency. > > Hence, I am wondering what is the rationale for HIP to specify DSA as > a MANDATORY algorithm, although RSA signatures verification might be > ten times faster than DSA? > > Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) which > has reduced P.K. and signatures size, and can be as fast or faster > than RSA? > > Thanks, > > --julien > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 11:43:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28105 for ; Thu, 7 Oct 2004 11:43:56 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 689D07310; Thu, 7 Oct 2004 10:35:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 9286172E6 for ; Thu, 7 Oct 2004 10:34:02 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA26538; Thu, 7 Oct 2004 10:42:13 -0500 (CDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i97FgDD07441; Thu, 7 Oct 2004 08:42:13 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 08:41:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NONCE parameter in base exchange? Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE4@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] NONCE parameter in base exchange? Thread-Index: AcSsSFFrRaorIobZSEubMkux+aVYzAAOIXFw From: "Ahrenholz, Jeffrey M" To: "Julien Laganier" , Cc: "Petri Jokela" , "Yogesh Prem Swami" X-OriginalArrivalTime: 07 Oct 2004 15:41:59.0300 (UTC) FILETIME=[2EBCC440:01C4AC84] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 08:41:58 -0700 Date: Thu, 7 Oct 2004 08:41:58 -0700 Content-Transfer-Encoding: quoted-printable > You can create separate SAs based on different NONCES, and then the=20 > hack is when an outbound packet enters ESP, the SA selection is made=20 > locally, based on Traffic Selectors including TCP/UDP ports for=20 > example, and not enforced by the ESP receivers, which hence doesn't=20 > need to be aware of the local TSs used by the ESP sender. >=20 > This allows for separation of multiple connexions by the sender,=20 > without having to negociate TSs with TCP/UDP ports numbers in HIP=20 > itself. Using this method, with the receiver not aware of the sender's local TSs, you would probably have asymmetric return traffic (i.e., returning on another SPI)(unless the receiver sets up its own TSs that happen to exactly match the sender). But I would agree that this might be more elegant than using multiple HIs. > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and=20 > keep ECHO_REQ/REP.=20 Do we need both NONCE and ECHO? > IMHO this is a minor addition which buys us provable security by=20 > conforming to the SIGMA core protocol, so I believe we don't need to=20 > wait until v2 to handle NONCEs. I think this is a good argument too. I wouldn't mind adding the nonce. Maybe note its future usefulness. If it replaces the ECHO_*, then it is not very different from the ECHO_* parameter anyway. -Jeff _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 12:28:54 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02024 for ; Thu, 7 Oct 2004 12:28:54 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 86D3A7316; Thu, 7 Oct 2004 11:20:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 406457310 for ; Thu, 7 Oct 2004 11:20:00 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA23005; Thu, 7 Oct 2004 09:28:15 -0700 (PDT) Received: from XCH-NW-13P.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i97GSD309180; Thu, 7 Oct 2004 11:28:13 -0500 (CDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NW-13P.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6899); Thu, 7 Oct 2004 09:27:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] BaseHIP Issue #42 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE5@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] BaseHIP Issue #42 Thread-Index: AcSsX2L8MqqngHLgRki+d2tgRMJ3WQAJawhA From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" , X-OriginalArrivalTime: 07 Oct 2004 16:27:24.0396 (UTC) FILETIME=[87056AC0:01C4AC8A] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 09:07:46 -0700 Date: Thu, 7 Oct 2004 09:07:46 -0700 Content-Transfer-Encoding: quoted-printable Petri, > The key exchange described on page 12 of the base draft was a bit=20 > unclear. So, a new proposal: This new text is much clearer. I have a few suggested minor edits below. -Jeff The second packet, R1, starts the actual exchange. It contains a puzzle, that is, a cryptographic challenge that the Initiator must solve before continuing the exchange. In addition, it contains the initial Diffie-Hellman parameters and a signature, covering part of the message. Some fields are left outside the signature to support pre-created R1s. In the I2 packet, the Initiator must display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 also contains a Diffie-Hellman parameter that carries needed information for the Responder. The packet is signed by the sender. =20 In R1, the signature covers the packet, after setting the initiator HIT, header checksum, and the PUZZLE parameter's Opaque and Random #I fields temporarily to zero, and excluding any TLVs that follow the signature. =20 In I2, the signature covers the whole packet, excluding=20 any TLVs that follow the signature. =20 In R2, the signature and the HMAC cover the whole envelope. =20 In this section we cover the overall design of the base exchange. The details are the subject of the rest of this memo. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 17:22:59 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28549 for ; Thu, 7 Oct 2004 17:22:58 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2D2BF7316; Thu, 7 Oct 2004 16:14:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 41E0B7310 for ; Thu, 7 Oct 2004 16:13:50 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i97LME53021759 for ; Thu, 7 Oct 2004 15:22:14 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5800G87GP2UP@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 15:22:14 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5800L60GOZNG@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 15:22:14 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Recovery from state loss In-reply-to: To: Pekka Nikander , Petri.Jokela@nomadiclab.com, "Henderson, Thomas R" Cc: Erik Nordmark , hipsec@honor.trusecure.com Message-id: <200410072323.32301.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_slDDtQREaSofIkrNVClEkg)" User-Agent: KMail/1.7 References: <200407151325.14103.julien.laganier@sun.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 07 Oct 2004 23:23:31 +0200 Date: Thu, 07 Oct 2004 23:23:31 +0200 --Boundary_(ID_slDDtQREaSofIkrNVClEkg) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT On Friday 16 July 2004 19:00, Pekka Nikander wrote: > >> So here is my attempted approach and a close handshake that > >> can apply to HIP as well as NOID. The goal is to remove the case > >> when one end retains association state and the other end has > >> discarded it, since this seems to open up some DoS opportunity. > > > > IMHO, this scheme fills a hole in the HIP specification, > > particularly since we removed the RESYNC-related stuff. Hence, I > > am strongly in favor of adopting (and adapting) the proposed > > approach. > > > > There's a remaining question, though: Does it belongs to the > > base protocol spec, or rather to an extension? I would vote for > > the first but I'm not 100% sure... > > > > What do other people think? > > I don't have any strong opinion. If someone makes a good write up > for the base spec, I don't have anything against including it. Folks, Attached is an attempted write down containing additional sections complementing the HIP protocol specification with a CLOSE/CLOSE_ACK handshake, based on Erik's approach. Please let me know what you think, especially things still missing, and your opinion on its maturity for a possible integration within the base spec draft (-01 or later). Thanks, --julien --Boundary_(ID_slDDtQREaSofIkrNVClEkg) Content-type: text/plain; charset=iso-8859-1; name=hip_closeack.txt Content-disposition: attachment; filename=hip_closeack.txt Content-Transfer-Encoding: 7BIT The mechanism uses two time constant: UAL (Unused Association Lifetime) minutes and MSL (Maximum Segment Lifetime) minutes. ----------------------------------------------------------------- 5.4.1 HIP States UNASSOCIATED State machine start I1-SENT Initiating HIP I2-SENT Waiting to finish HIP R2-SENT Waiting to finish HIP ESTABLISHED HIP SA established REKEYING HIP SA established, but UPDATE is outstanding for rekeying CLOSING HIP SA closing, no data (ESP) can be sent E-FAILED HIP exchange failed ----------------------------------------------------------------- 5.4.2 HIP State Processes +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED Receive ESP for unknown SA, optionally send ICMP as defined in Section 6.3 and stay at UNASSOCIATED Receive CLOSE for unknown association, send CLOSE_ACK and stay at UNASSOCIATED Receive ANYOTHER, drop and stay at UNASSOCIATED +------------+ |ESTABLISHED | HIP SA established +------------+ Receive I1, send R1 and stay at ESTABLISHED Receive I2, process with cookie and possible Opaque data verification if successful, send R2, drop old SAs, establish new SA, go to R2-SENT if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPDATE, process if successful, send UPDATE in reply and go to REKEYING if failed, stay at ESTABLISHED Need rekey, send UPDATE and go to REKEYING No packet sent/received during UAL minutes, send CLOSE and go to CLOSING. Receive CLOSE, process if successful, send CLOSE_ACK and go to UNASSOCIATED if failed, stay at ESTABLISHED +---------+ | CLOSING | HIP association has not been used for UAL (Unused Association +---------+ Lifetime) minutes. Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive ANYOTHER, drop and stay at CLOSING Timeout, increment timeout sum, reset timer if timeout sum is less than UAL+MSL minutes, retransmit CLOSE and stay at CLOSING if timeout sum is greater than UAL+MSL minutes, go to UNASSOCIATED ----------------------------------------------------------------- 5.4.3 Simplified HIP State Diagram +-+ | | CLOSE received, send CLOSE_ACK V ^ +------------+ |UNASSOCIATED|<=================+-+ +------------+ | | ^ | | | CLOSE_ACK received, or | | | UAL+MSL minutes CLOSE | | | re-xmits | | CLOSE received, ^ | | send CLOSE_ACK +---------+ | | | CLOSING |>-------------------+ | +---------+ | ^ | | No packet sent/received | | for UAL min, send CLOSE | ^ | +------------+ | |ESTABLISHED |>-------------------+ +------------+ ----------------------------------------------------------------- 7.10 CLOSE - the HIP association closing packet The HIP header values for the CLOSE packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) ) Valid control bits: none The sender MUST include an ECHO_REPLY used to validate CLOSE_ACK received in response, and both an HMAC and a signature (calculated over the whole HIP envelope). The receiver peer MUST validate both the HMAC and the signature if it has a HIP association state, and MUST reply with a CLOSE_ACK containing an ECHO_REPLY corresponding to the received ECHO_REQUEST. ----------------------------------------------------------------- 7.11 CLOSE_ACK - the HIP closing acknowledgment packet The HIP header values for the CLOSE_ACK packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REPLY [, HMAC, HIP_SIGNATURE] ) ) Valid control bits: none The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope) if it has a HIP association state. The receiver peer MUST validate both the HMAC and the signature if present and it has an association state. ----------------------------------------------------------------- 8.16 Processing CLOSE packets When the host receives a CLOSE message it discards the HIP association state and responds with a CLOSE_ACK message. (The authenticity of the CLOSE message is verified using both HMAC and SIGNATURE). This processing applies whether or not the HIP association state is CLOSING in order to handle CLOSE messages from both ends crossing in flight. Once the HIP association state has been discarded any need to send data packets will trigger creating and establishing of a new HIP association, starting with sending an I1. A CLOSE message which is received when there is no HIP association state can not be verified but will result in a CLOSE_ACK response to speed up the peer discarding the HIP association in the presence of packet loss. ----------------------------------------------------------------- 8.17 Processing CLOSE_ACK packets When a host receives a CLOSE_ACK message it verifies that it is in CLOSING state and that the CLOSE_ACK was in response to the CLOSE (using the included ECHO_REPLY in response to the sent ECHO_REQUEST). It is possible to use stronger verification of the CLOSE_ACK based on optional HMAC and SIGNATURE but only for the first CLOSE message since the HIP state is discarded on its reception. Then, depending on policy, when the CLOSE_ACK response to the first CLOSE is lost, an implementation discards its HIP state by waiting for either subsequent not-signed and not-MACed CLOSE_ACK packets, or the full UAL+MSL minutes retransmission period. --Boundary_(ID_slDDtQREaSofIkrNVClEkg)-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 18:03:55 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02678 for ; Thu, 7 Oct 2004 18:03:55 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1DF94731B; Thu, 7 Oct 2004 16:55:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 420D67316 for ; Thu, 7 Oct 2004 16:54:51 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA07897; Thu, 7 Oct 2004 17:02:57 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i97M2us16304; Thu, 7 Oct 2004 15:02:56 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 15:02:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NONCE parameter in base exchange? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] NONCE parameter in base exchange? Thread-Index: AcSsSFFrRaorIobZSEubMkux+aVYzAAOIXFwAA3PYbA= From: "Henderson, Thomas R" To: "Ahrenholz, Jeffrey M" , "Julien Laganier" , Cc: "Petri Jokela" , "Yogesh Prem Swami" X-OriginalArrivalTime: 07 Oct 2004 22:02:37.0080 (UTC) FILETIME=[5B1D7180:01C4ACB9] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 14:58:24 -0700 Date: Thu, 7 Oct 2004 14:58:24 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ahrenholz, Jeffrey M=20 > Sent: Thursday, October 07, 2004 8:42 AM > To: Julien Laganier; hipsec@honor.trusecure.com > Cc: Petri Jokela; Yogesh Prem Swami > Subject: RE: [Hipsec] NONCE parameter in base exchange? >=20 >=20 >=20 > > > You can create separate SAs based on different NONCES, and then the=20 > > hack is when an outbound packet enters ESP, the SA=20 > selection is made=20 > > locally, based on Traffic Selectors including TCP/UDP ports for=20 > > example, and not enforced by the ESP receivers, which hence doesn't=20 > > need to be aware of the local TSs used by the ESP sender. > >=20 > > This allows for separation of multiple connexions by the sender,=20 > > without having to negociate TSs with TCP/UDP ports numbers in HIP=20 > > itself. >=20 > Using this method, with the receiver not aware of the sender's local > TSs, you would probably have asymmetric return traffic (i.e.,=20 > returning > on another SPI)(unless the receiver sets up its own TSs that happen to > exactly match the sender). But I would agree that this might be more > elegant than using multiple HIs. Although HIP does not have any requirements document, I don't think that managing multiple parallel SAs is a strong requirement to work for=20 HIPv1. It has been stated in the architecture document that there is=20 less policy granularity in HIP than in other key exchange protocols. =20 Maybe this gets revisited in the future. >=20 > > > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and=20 > > keep ECHO_REQ/REP.=20 >=20 > Do we need both NONCE and ECHO? I don't see why we can't replace ECHO_REQ/RESP with NONCE. They are functionally the same, right? (and define a NONCE within and outside of the signature, like ECHO_REQ is presently done). >=20 > > IMHO this is a minor addition which buys us provable security by=20 > > conforming to the SIGMA core protocol, so I believe we=20 > don't need to=20 > > wait until v2 to handle NONCEs. >=20 Agreed. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 19:24:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09958 for ; Thu, 7 Oct 2004 19:24:55 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 63A607316; Thu, 7 Oct 2004 18:16:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id BAE407310 for ; Thu, 7 Oct 2004 18:15:39 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i97NO453018083 for ; Thu, 7 Oct 2004 17:24:05 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I58007LTMC4XQ@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 17:24:04 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5800CABMC1E1@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 07 Oct 2004 17:24:04 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] NONCE parameter in base exchange? In-reply-to: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> To: hipsec@honor.trusecure.com, "Henderson, Thomas R" , "Ahrenholz, Jeffrey M" , Julien Laganier , hipsec@honor.trusecure.com, Petri Jokela , Yogesh Prem Swami Message-id: <200410080125.22712.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.7 References: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 08 Oct 2004 01:25:22 +0200 Date: Fri, 08 Oct 2004 01:25:22 +0200 Content-Transfer-Encoding: quoted-printable On Thursday 07 October 2004 23:58, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Ahrenholz, Jeffrey M > > Sent: Thursday, October 07, 2004 8:42 AM > > To: Julien Laganier; hipsec@honor.trusecure.com > > Cc: Petri Jokela; Yogesh Prem Swami > > Subject: RE: [Hipsec] NONCE parameter in base exchange? > > > > > > > > > You can create separate SAs based on different NONCES, and then > > > the hack is when an outbound packet enters ESP, the SA > > > > selection is made > > > > > locally, based on Traffic Selectors including TCP/UDP ports for > > > example, and not enforced by the ESP receivers, which hence > > > doesn't need to be aware of the local TSs used by the ESP > > > sender. > > > > > > This allows for separation of multiple connexions by the > > > sender, without having to negociate TSs with TCP/UDP ports > > > numbers in HIP itself. > > > > Using this method, with the receiver not aware of the sender's > > local TSs, you would probably have asymmetric return traffic > > (i.e., returning > > on another SPI)(unless the receiver sets up its own TSs that > > happen to exactly match the sender).=20 But IPsec is asymmetric, isn't it? You need two IPsec SAs, with two=20 SPIs, one in each direction to carry a single TCP connexion. Traffic=20 will return 'asymmetrically' to 'another' SPI, but return packets=20 might well flow 'symmetrically' on the IP network, i.e., on the same=20 path as forward packets (if both peers are using a single net_if wich=20 is assigned a single IP address). > > But I would agree that this=20 > > might be more elegant than using multiple HIs. > > Although HIP does not have any requirements document, I don't think > that managing multiple parallel SAs is a strong requirement to work > for HIPv1. =A0It has been stated in the architecture document that > there is less policy granularity in HIP than in other key exchange > protocols. Maybe this gets revisited in the future. I agree. For now, if one of the peers wants to spread connexions=20 amongst multiple SAs, he can use kind of "sender-side only" TSs.=20 It obtains part of the wanted effect. And if the other peer is willing=20 to play the same game then everything is fine: each TCP connexion=20 flow onto his own two IPsec SAs, on the same IP path, though the SPI=20 are different and it hasn't been specifically negotiated. =20 > > > > Do we need both NONCE and ECHO? > > I don't see why we can't replace ECHO_REQ/RESP with NONCE. They > are functionally the same, right? (and define a NONCE within and > outside of the signature, like ECHO_REQ is presently done)..=20 I dunno. BTW, NONCEs might also be useful if we add a CLOSE/CLOSEACK hanshake=20 to HIP: If a host is in state CLOSING but has data to sent, it can=20 initiates another HIP exchange with a newly created state and fresh=20 NONCE-I.=20 This way a responder receiving a packet might be able to differentiate=20 states which otherwise would have appeared to be the same. =2D-julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 7 20:17:57 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17100 for ; Thu, 7 Oct 2004 20:17:56 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1571B7316; Thu, 7 Oct 2004 19:09:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 0742B7310 for ; Thu, 7 Oct 2004 19:08:06 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA28760; Thu, 7 Oct 2004 19:16:28 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i980GS305351; Thu, 7 Oct 2004 19:16:28 -0500 (CDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 17:16:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] NONCE parameter in base exchange? Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE6@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] NONCE parameter in base exchange? Thread-Index: AcSsxL+RA00yEeSeQyu9f9pYeas3yQAAasyw From: "Ahrenholz, Jeffrey M" To: "Julien Laganier" , X-OriginalArrivalTime: 08 Oct 2004 00:16:23.0469 (UTC) FILETIME=[0B3735D0:01C4ACCC] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 7 Oct 2004 17:16:22 -0700 Date: Thu, 7 Oct 2004 17:16:22 -0700 Content-Transfer-Encoding: quoted-printable > > > Using this method, with the receiver not aware of the sender's > > > local TSs, you would probably have asymmetric return traffic > > > (i.e., returning > > > on another SPI)(unless the receiver sets up its own TSs that > > > happen to exactly match the sender).=20 >=20 > But IPsec is asymmetric, isn't it? You need two IPsec SAs, with two=20 > SPIs, one in each direction to carry a single TCP connexion. Traffic=20 > will return 'asymmetrically' to 'another' SPI, but return packets=20 > might well flow 'symmetrically' on the IP network, i.e., on the same=20 > path as forward packets (if both peers are using a single net_if wich=20 > is assigned a single IP address). Right, I meant/should've said "i.e., returning on a SPI other than the one paired with the outgoing SPI." As this seems relevant to multihoming, this "sender-side only" traffic selector concept might be noted in the hip-mm-00 draft, if we add the NONCE. (although this might alter the concept depicted in Figure 2 (Page 8) if we have multiple SPIs using the same address...) -Jeff _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 02:55:00 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28834 for ; Fri, 8 Oct 2004 02:55:00 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 283FA731B; Fri, 8 Oct 2004 01:46:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id DDF5D7316 for ; Fri, 8 Oct 2004 01:45:07 -0400 (EDT) Received: from n51.nomadiclab.com (n51.nomadiclab.com [131.160.193.51]) by n2.nomadiclab.com (Postfix) with ESMTP id E430C212C91; Fri, 8 Oct 2004 09:53:33 +0300 (EEST) From: Jan Mikael Melen To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] NONCE parameter in base exchange? User-Agent: KMail/1.6.2 Cc: Julien Laganier , Petri Jokela , "Ahrenholz, Jeffrey M" , Yogesh Prem Swami References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> <200410071033.29140.julien.laganier@sun.com> In-Reply-To: <200410071033.29140.julien.laganier@sun.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410080953.33603.Jan.Melen@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Oct 2004 09:53:33 +0300 Date: Fri, 8 Oct 2004 09:53:33 +0300 Content-Transfer-Encoding: 7bit Hi, On Thursday 07 October 2004 11:33, Julien Laganier wrote: > > There are not too many opinions on this issue on the list? What > > shall we do with it: 1) add the NONCE parameter and remove ECHO > > REQ/RESP, 2) leave the draft as it is now and think this again in > > HIP v2. > > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and > keep ECHO_REQ/REP. > > IMHO this is a minor addition which buys us provable security by > conforming to the SIGMA core protocol, so I believe we don't need to > wait until v2 to handle NONCEs. I would vote for option 1.5 so I don't have anything against renaming ECHO to NONCE if it is what makes people to sleep better ;) The functionality is the same with NONCE and ECHO as it has been pointed out several times on this list (s/ECHO/NONCE/g ;) But I won't be voting for having multiple SAs with different policies. IMHO before we can have multiple SAs with different policies we should be able to somehow inform the peer node that I'm going to use this SA only for ssh and would like to have the return packets through the SA paired to this one. Now if either end wants to use some other protocol they'll know that they'll have to create a new SA pair between the hosts or do some policy negotiation. I think that this kind of policy issues should be left to HIPv2. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 04:53:00 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04651 for ; Fri, 8 Oct 2004 04:53:00 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D7DD57316; Fri, 8 Oct 2004 03:44:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id AAE3E72F3 for ; Fri, 8 Oct 2004 03:43:26 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 1A4D1220007; Fri, 8 Oct 2004 11:51:47 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id C339FA; Fri, 8 Oct 2004 11:51:47 +0300 (EEST) In-Reply-To: <200410072323.32301.julien.laganier@sun.com> References: <200407151325.14103.julien.laganier@sun.com> <200410072323.32301.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , Erik Nordmark , Petri.Jokela@nomadiclab.com, hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Recovery from state loss To: Julien Laganier X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Oct 2004 10:53:11 +0300 Date: Fri, 8 Oct 2004 10:53:11 +0300 Content-Transfer-Encoding: 7bit >>>> So here is my attempted approach and a close handshake that >>>> can apply to HIP as well as NOID. The goal is to remove the case >>>> when one end retains association state and the other end has >>>> discarded it, since this seems to open up some DoS opportunity. >>> >>> IMHO, this scheme fills a hole in the HIP specification, >>> particularly since we removed the RESYNC-related stuff. Hence, I >>> am strongly in favor of adopting (and adapting) the proposed >>> approach. >> >> I don't have any strong opinion. If someone makes a good write up >> for the base spec, I don't have anything against including it. > > Attached is an attempted write down containing additional sections > complementing the HIP protocol specification with a CLOSE/CLOSE_ACK > handshake, based on Erik's approach. Looks good, thanks! The only thing I was left wondering is the overloading of the CLOSE_ACK message. In the text provided, CLOSE_ACK works both as an ack to a received CLOSE and as a kind of error message telling that there is no such association. In the former case, it is protected with HMAC and SIG, in the latter case it is not. Maybe it would be better to have different messages for these purposes? That is, in the UNASSOCIATED state, if you receive a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable error code. In that way the CLOSE_ACK message would be only used for acknowledging CLOSE. A related issue is whether we should allow/require a "CLOSED" state. A host sending a CLOSE_ACK would enter a "CLOSED" state for a certain period (2 * timeout?), and during that time it would be able to send further CLOSE_ACK messages in the case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) It would then automatically move to UNASSOCIATED if it receives no CLOSE messages within that period. I don't think the CLOSED state is necessarily needed, or should be mandated, but it sounds to be as a nice engineering optimisation that some implementations might want to do. --- We probably need also some text to the security considerations section, considering the potential DoS attacks related to the CLOSE mechanism. It should note that since the CLOSE (and CLOSE_ACK?) messages have HMAC, an outsider cannot CLOSE a connection. It has SIG, allowing middle boxes to inspect the messages and immediately close the related SAs. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 07:10:07 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14636 for ; Fri, 8 Oct 2004 07:10:07 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A646A7316; Fri, 8 Oct 2004 06:01:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id E709272F3 for ; Fri, 8 Oct 2004 06:00:36 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id DD374220007; Fri, 8 Oct 2004 14:09:01 +0300 (EEST) Received: from [127.0.0.1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 9599E8; Fri, 8 Oct 2004 14:09:02 +0300 (EEST) In-Reply-To: <200410071033.29140.julien.laganier@sun.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> <200410071033.29140.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B085D15-191A-11D9-BF2A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) To: Julien Laganier , Yogesh Prem Swami X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Oct 2004 14:09:10 +0300 Date: Fri, 8 Oct 2004 14:09:10 +0300 Content-Transfer-Encoding: 7bit Just one aspect now, I'll try to return to the rest later. Sorry for not having had time to take this up earlier. Supporting multiple parallel SAs between any pair of HIs has been a non-goal for HIP from the beginning. The mobility and multi-homing extension adds such a feature, but _only_ for dealing with replay window problems. If this non-goal is not clear from the base spec / arch spec, we need to add explicit text. And I guess the case is so, since we've faced this same issue before. Anyone willing to draft text to be included in both/either of the drafts, noting that _architecturally_ HIP only considers host-to-host granularity, and any finer granularity is FFS? If someone wants to add policy control to HIP so that you could have multiple parallel SAs for policy purposes, that requires an extension and DOES NOT belong to the base specification. From that point of view, I don't see any need for having nonces. There may be other reasons; I haven't had flow time to contemplate that. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 07:14:59 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14838 for ; Fri, 8 Oct 2004 07:14:59 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5A47D7316; Fri, 8 Oct 2004 06:06:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id E574272F3 for ; Fri, 8 Oct 2004 06:05:34 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 812DA212CA3; Fri, 8 Oct 2004 14:14:00 +0300 (EEST) Message-ID: <4166764D.1060401@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Julien Laganier , "Henderson, Thomas R" , Erik Nordmark , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Recovery from state loss References: <200407151325.14103.julien.laganier@sun.com> <200410072323.32301.julien.laganier@sun.com> <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> In-Reply-To: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 08 Oct 2004 14:13:17 +0300 Date: Fri, 08 Oct 2004 14:13:17 +0300 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > > Looks good, thanks! > > Maybe it would be better to have different messages for these > purposes? That is, in the UNASSOCIATED state, if you receive > a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable > error code. In that way the CLOSE_ACK message would be only > used for acknowledging CLOSE. > > A related issue is whether we should allow/require a "CLOSED" > state. A host sending a CLOSE_ACK would enter a "CLOSED" > state for a certain period (2 * timeout?), and during that > time it would be able to send further CLOSE_ACK messages in the > case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) > It would then automatically move to UNASSOCIATED if it receives > no CLOSE messages within that period. > > I don't think the CLOSED state is necessarily needed, or should > be mandated, but it sounds to be as a nice engineering optimisation > that some implementations might want to do. > Thanks Julien for the text! I modified a bit Julien's proposal according to Pekka's comments. My notes are included in the text. Outgoing/incoming data traffic text needs still something For example when the association is not dropped in the CLOSED state and there is some data that would belong to this association. /petri 5.4.2 HIP State Processes <**PJ**> In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOSE, not written down here <**PJ**> +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED Receive ESP for unknown SA, optionally send ICMP as defined in Section 6.3 and stay at UNASSOCIATED Receive CLOSE for unknown association, stay at UNASSOCIATED Receive ANYOTHER, drop and stay at UNASSOCIATED <**PJ**> ESTABLISHED: Go to CLOSED instead of UNASSOCIATED <**PJ**> +------------+ |ESTABLISHED | HIP SA established +------------+ Receive I1, send R1 and stay at ESTABLISHED Receive I2, process with cookie and possible Opaque data verification if successful, send R2, drop old SAs, establish new SA, go to R2-SENT if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPDATE, process if successful, send UPDATE in reply and go to REKEYING if failed, stay at ESTABLISHED Need rekey, send UPDATE and go to REKEYING No packet sent/received during UAL minutes, send CLOSE and go to CLOSING. Receive CLOSE, process if successful, send CLOSE_ACK and go to CLOSED if failed, stay at ESTABLISHED <**PJ**> Closing: Move to CLOSED after sending CLOSE_ACK instead of UNASSOCIATED <**PJ**> +---------+ | CLOSING | HIP association has not been used for UAL (Unused +---------+ Association Lifetime) minutes. Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, discard state and go to CLOSED if failed, stay at CLOSING Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive ANYOTHER, drop and stay at CLOSING Timeout, increment timeout sum, reset timer if timeout sum is less than UAL+MSL minutes, retransmit CLOSE and stay at CLOSING if timeout sum is greater than UAL+MSL minutes, go to UNASSOCIATED <**PJ**> CLOSED is a new state. Timeout sum should be 2*MSL or something else?? <**PJ**> +--------+ | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary +--------+ Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, stay at CLOSED if failed, stay at CLOSED Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSED Receive ANYOTHER, drop and stay at CLOSED Timeout, increment timeout sum, reset timer if timeout counter > 2 * MSL, discard state and go to UNASSOCIATED else stay at CLOSED 5.4.3 Simplified HIP State Diagram +-+ | | CLOSE received, send NOTIFY V ^ +------------+ |UNASSOCIATED|<----------------------+ +------------+ | ^ | Timeout, move to | CLOSE_ACK received, or | UNASSOCIATED | timeout sum > UAL+MSL | | +--------+ ^ rec CLOSE, +--->| CLOSED |----+ +---------+ send CLOSE_ACK | +--------+ | CLOSE received, | CLOSING |----------------+ | ^ | send CLOSE_ACK | |-----+ | | | +---------+ | timeout sum | +-----+ ^ ^ | < UAL+MSL, | | +------+ retransmit CLOSE | | | | No packet sent/received | | for UAL min, send CLOSE | ^ | CLOSE received, +------------+ | send CLOSE_ACK |ESTABLISHED |>----------------------+ +------------+ ----------------------------------------------------------------- <**PJ**> Removed optional things, NOTIFY is sent in UNASSOCIATED state <**PJ**> 7.11 CLOSE_ACK - the HIP closing acknowledgment packet The HIP header values for the CLOSE_ACK packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) Valid control bits: none The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope). The receiver peer MUST validate both the HMAC and the signature. ----------------------------------------------------------------- <**PJ**> We don't discard the state before we move to UNASSOCIATED. - If we want to send data? We cannot use the old association any longer, we need to start a new negotiation. That part of the text needs maybe some clarification. <**PJ**> 8.16 Processing CLOSE packets When the host receives a CLOSE message it responds with a CLOSE_ACK message and moves to CLOSED state. (The authenticity of the CLOSE message is verified using both HMAC and SIGNATURE). This processing applies whether or not the HIP association state is CLOSING in order to handle CLOSE messages from both ends crossing in flight. The HIP association is not discarded before the host moves from the UNASSOCIATED state. Once the closing process has started, any need to send data packets will trigger creating and establishing of a new HIP association, starting with sending an I1. A CLOSE message which is received when there is no HIP association state can not be verified but will result in a NOTIFY response. ----------------------------------------------------------------- <**PJ**> Optional things removed. ACK also accepted in CLOSED state if we have earlier sent CLOSE related to the same association: ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, send CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent CLOSE ->... <**PJ**> 8.17 Processing CLOSE_ACK packets When a host receives a CLOSE_ACK message it verifies that it is in CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSE (using the included ECHO_REPLY in response to the sent ECHO_REQUEST). The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is discarded when the state changes to UNASSOCIATED and, after that, NOTIFY is sent as a response to a CLOSE message. ----------------------------------------------------------------- <**PJ**> New NOTIFY <**PJ**> 6.2.19 NOTIFY UNKNOWN ASSOCIATION 44 The received CLOSE message referred to an association that does not exist. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 07:27:01 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15497 for ; Fri, 8 Oct 2004 07:27:01 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id F1BD97316; Fri, 8 Oct 2004 06:18:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 51CB172F3 for ; Fri, 8 Oct 2004 06:17:15 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1CFssD-0006q8-00; Fri, 08 Oct 2004 07:25:21 -0400 From: Tim Shepard To: Pekka Nikander Cc: Julien Laganier , Yogesh Prem Swami , hipsec@honor.trusecure.com Subject: Re: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-reply-to: Your message of Fri, 08 Oct 2004 14:09:10 +0300. <7B085D15-191A-11D9-BF2A-000D9331AFB0@nomadiclab.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 08 Oct 2004 07:25:21 -0400 Date: Fri, 08 Oct 2004 07:25:21 -0400 > Supporting multiple parallel SAs between any pair of HIs > has been a non-goal for HIP from the beginning. Yes. And our thinking on this was that HIs can be easily created, as many as you like, and only one of two hosts would have to use a different HI in order to have parallel HIP sessions going simultaneously between two hosts. We were thinking that typical HIP associations would be using an ephemeral HI on at least one end (probably the initiator) so if for some reason you need to open a parallel SA, you just create another ephemeral HI. Even if there's a situation where you need non-ephemeral HIs at both ends, then if you need parallel SAs, you can probably manage to have a different HI at least at one end. At least that is what we were thinking, and at this particular moment I am not convinced that this thinking was in error. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 08:21:03 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18941 for ; Fri, 8 Oct 2004 08:21:02 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 270067316; Fri, 8 Oct 2004 07:12:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 379E572F3 for ; Fri, 8 Oct 2004 07:11:49 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 84DAD220003; Fri, 8 Oct 2004 15:20:16 +0300 (EEST) Received: from [127.0.0.1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2E2118; Fri, 8 Oct 2004 15:20:17 +0300 (EEST) In-Reply-To: <414DF55F.7020802@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward To: Yogesh Prem Swami X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Oct 2004 15:20:23 +0300 Date: Fri, 8 Oct 2004 15:20:23 +0300 Content-Transfer-Encoding: 7bit Yogesh, Trying to finally cover this message, sorry for the delay. Anyway, thanks a lot of taking this up and writing this. > Okay, the minimal changes required in the present HIP key exchange is > to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in > the HMAC of message 4 (shown in the message exchange below). Note > that the present protocol in the draft looks fairly secure, but as > SIGMA > paper points out encryption is not the right method to prove possession > of session key (but the attack that the paper describes in the presence > of stream cipher doesn't apply here). So while the encrypted token > { PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token > guarantees that identity mis-binding attack cannot be carried out, > it's still better to use HMAC, IMO. (Besides we have a proof that > HMAC based scheme is secure.) Sounds good. > I have also added nonce-I and nonce-R in all these message. This is > important to allow parallel SA creation, and allow cases where both > initiator and responder choose pre computed g^i and g^r (this can > happen, unless the draft explicitly prevents it). The nonce should > be used in deriving the session keys. As was discussed in other messages, parallel SAs between any given pair of HITs is a non-goal. I'd like to understand better your reference to pre-computed D-H keys by both parties. Would you care to explain? > 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > > 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > SIG( HIT-R, g^r, PUBLIC_KEY-R) > > > 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > SIG( HIT-I, HIT-R, SPI, g^i, > { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > > 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > has changed */ If I understand correctly, and leaving aside the issue of nonces, the only differences are the addition of HMAC to I2 and the change of the HMAC contents in R2. They seem OK to me. > o In the draft it's important to say that the responder should keep > the random value r for at least 2*MSL (and possibly longer) from > the > last time it sent message 2. In case Message 3 arrives after 2*MSL, > and no random number r can be found, it should be dropped and an > ICMP > message should be sent. If the Initiator receives an ICMP after > sending message-3, it should not assume that the responder sent > the message, and should not close that session. An Initiator > MAY however start with a new parallel I1 with a new nonce value. Sounds OK to me. I guess most of this is already implied by the draft, but it would be much better to be explicit. Petri your Yogesh, could you provide us with some concrete proposal? > Couple of observations about this key exchange: > > A) The identity of Responder cannot be concealed even against the > passive attack. The HOST_ID in message-2 is required so that the > Initiator can get the public-key to verify the SIGNATURE from > responder. Yes. One way to address this has been discussed in the BLIND paper by Jukka Ylitalo and me, in this year's Cambridge Security Protocols Workshop. See Jukka's or my publications web pages. > B) The identity of Initiator cannot be concealed against an active > attacker unless g^r is covered in SIGNATURE calculation in > message-2. (So keep section-7 description and change section-4 text) Sounds OK to me. > (A) and (B) together means that if we want to get responders ID > protection then we need to severely reorganize the messages. Yes. We are aware of that. See the above mentioned paper. > One simple thing one can do is to only send the public-key and > in message-2 (and leave Domain-ID-R field completely out). That doesn't help much, since in HIP the public key IS the real identifier. The hostname/NAI is only considered as auxliary information. You may learn the association between the public key and the hostname/NAI also from the DNS or some other databse. > Later, > Responder can put Domain-ID as encrypted in message-4 and let Initiator > verify it against the MAC received in message-2. The advantage is that > we can now protect the identity of Initiator against passive attacker > and the Identity of responder against Active attackers. The > disadvantage > is that the Initiator's ID cannot be protected against active > attackers. It was a deliberate choice to err on protecting the initiator's privacy more than the responder's. > Note that protecting the Public-Key alone without Domain-ID is not > that useful. The worst thing that an attacker can do by stealing the > public key is to register it under her own name (i.e., Eve takes > Alice's public key and puts it in DNSsec under Eve's name, assuming > DNSsec doesn't do proof of possession checks). Binding of public keys and external identifiers, such as hostnames or NAIs, is currently outside the scope of the WG charter. The architectural stance is that the public key is the primary identifier, and getting the public key from a human understandable name is a separate problem. > But the HMAC binding to > name in SIGMA prevents from attacks that can result from this kind of > behavior, so it's not that useful to protect the public-key. Note > that this is the reason I have added HOST_ID in message-4. HMACing > only HITs will get us in trouble. I don't see any adverse effects of adding the HOST_ID to the HMACs, even though I doubt its value. The kind of identity stealing attack that you describe belongs, from an architectural point of view, beyond the HIP base spec. On the other hand, if we can this easily provide some extra security, then why not. In summary: I am in favour of making these two changes: - adding a HMAC to I2 - changeing the R2 HMAC contents I still haven't been convinced about the nonces. The multiple-SA argument doesn't hold as it is a non-goal. I haven't seen explicit argumentation about using nonces for keymat generation. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 09:43:05 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23626 for ; Fri, 8 Oct 2004 09:43:03 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8A078731B; Fri, 8 Oct 2004 08:34:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 675997316 for ; Fri, 8 Oct 2004 08:33:53 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i98DgLNH016765 for ; Fri, 8 Oct 2004 07:42:21 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5900649Q2KEY@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 08 Oct 2004 07:42:21 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5900KANQ2I3K@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 08 Oct 2004 07:42:21 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Agenda requests In-reply-to: <4164E796.6030603@ericsson.com> To: hipsec@honor.trusecure.com Cc: Gonzalo Camarillo , David Ward , Pekka Nikander , Thomas Henderson Message-id: <200410081543.39186.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <4164E796.6030603@ericsson.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 08 Oct 2004 15:43:38 +0200 Date: Fri, 08 Oct 2004 15:43:38 +0200 Content-Transfer-Encoding: 7BIT On Thursday 07 October 2004 08:52, Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for the HIP WG > meeting in Washington. You should send your agenda request to the > chairs indicating what you want to present, any related documents, > and how long you want your agenda-slot to be. Hi Gonzalo, I'd like to request to short (10 minutes) slots to present draft-ietf-hip-dns-00.txt and draft-ietf-hip-rvs-00.txt in the next HIP WG session. Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 8 17:09:09 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16658 for ; Fri, 8 Oct 2004 17:09:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1B8E37311; Fri, 8 Oct 2004 16:00:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id AD9BD72F3 for ; Fri, 8 Oct 2004 15:59:41 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA07662; Fri, 8 Oct 2004 14:07:55 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i98L7ts08034; Fri, 8 Oct 2004 14:07:55 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 14:07:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Thread-Topic: review of comments on draft-ietf-hip-mm-00 preview Thread-Index: AcSqqtsNj3T5xIQZT3Crrj3efenEGgCyO6MA From: "Henderson, Thomas R" To: "Miika Komu" Cc: X-OriginalArrivalTime: 08 Oct 2004 21:07:53.0605 (UTC) FILETIME=[E06CAB50:01C4AD7A] Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 8 Oct 2004 14:07:53 -0700 Date: Fri, 8 Oct 2004 14:07:53 -0700 Content-Transfer-Encoding: quoted-printable Responding below to a number of (mostly Miika's) comments: (thanks for donating Security Considerations text! unless there is objection, I will include the version that Pekka edited) >=20 > > 9. If HIP negotiates base exchange using link locals, and one > > host moves, it will not be able to find its peer > > > > Suggested resolution: State that a host SHOULD provide its > > peer with a globally reachable IP address instead of relying > > exclusively on link-local addresses. >=20 > (the same goes for site-local addresses) site-locals are deprecated, but I think we can address this generally by saying "locally scoped" or "non-global" address. >=20 > > 10. Should REA be included in R2 or R1 (R1 is presently > > specified in text)? > > > > Note that there is some conflict in saying that, when REA > > is included in R1 and it includes a new preferred address, > > that the puzzle solution MUST be valid for both responder > > addresses. The conflict is in using Appendix D (base spec) > > mapping functions. > > > > Suggested resolution: Open, but leaning towards recommending > > inclusion in R2 instead of R1, unless the reason for putting > > it in R1 is (re)discovered. > > > > Also, issue should be opened in issue tracker. >=20 > I'd vote for the inclusion in the R2. This way, the R1s don't=20 > have to be > prebuilt every time the responder moves. >=20 It seems that most people (including myself) prefer the R2-- any objection if we make that change now? > One possible Denial of Service attack occurred in my mind: >=20 > A host could fake a creation of a new SA causing resource=20 > consumption at=20 > the peer host. This covered by Miika's proposed security section. > -> 4. (Roundup issue tracker #4): Use of multiple SAs > ->=20 > -> Suggested resolution: Close this issue (resolved). >=20 > How was this resolved (I forgot..) ? The issue tracker shows only one=20 > posting about this issue. Here was the start of the thread that caused that issue: http://honor.trusecure.com/pipermail/hipsec/2004-April/000667.html My understanding of the consensus (or the way that the thread eventually tailed off) was that a mechanism to have multiple SAs to handle the case where RTTs are very different was needed, but maybe in some cases it could be avoided (depending on how well the anti-replay was tuned). > -> Suggested resolution: Add a note to the text that, in the > -> case of multihoming with multiple SAs, it is RECOMMENDED to > -> associate SAs in pairs, and that when a NES is received for > -> a particular SA, the peer should rekey the paired SA. > -> Also, state that using asymmetrically set up SAs is experimental,=20 > -> and may fail to interoperate. > -> >=20 > I would like to see what is the definition for a "paired SA".=20 > How it is=20 > related to the peer's SAs and how it is associated when a new SA is=20 > created. >=20 Here is proposed text for a replacement of the third paragraph in=20 Section 5.2: "IPsec SAs are unidirectional, and the protocol may support = configurations in which an asymmetric number of inbound and outbound SAs exist on a = given host with respect to another host. However, for the purpose of handling multihoming more cleanly, it is RECOMMENDED that inbound and outbound = SAs=20 be created and maintained in a pairwise fashion between hosts, and that when rekeying occurs on one SA, it is also triggered on the paired SA. = For example, the HIP base exchange results in two SAs-- one inbound and one outbound on each host. If one of the two hosts wants to advertise = another interface to its peer, it should add a new inbound SA and send a REA = (and NES) to the peer. The peer should also create a new inbound SA. These two new SAs are also paired. Subsequently, when a rekey occurs on one = SA, a corresponding rekey is performed on the paired SA, with no ambiguity. = Implementations that fail to follow the above guidelines may fail to=20 interoperate cleanly." > -> 11. Use of SPI parameter when REA is present-- is it necessary? >=20 > I have no experience yet. >=20 > -> Suggested resolution: Open until middlebox implications are > -> better understood. > ->=20 > -> Also, issue should be opened in issue tracker. >=20 > Then we would have SPIs in three places in the same packet. REA, > NES, and SPI. Messy ? REA and NES both need SPI, since REA may occur without NES. SPI would seem to be redundant, unless a middlebox always wants SPI to be there, for its convenience. Suggest to leave it open for now. >=20 > Also the SPI selection algorithm for the parameter would be nice. Suggest statement that "SPI selection is performed in the same manner as in the base exchange." >=20 > Looks like there is a lot of text which assume the situation=20 > as if there=20 > is always only one address listed in the REA. That causes=20 > misinterpretation (for me at least) in sentences such as: >=20 >=20 > -Section 4.2 Address verification, "A simple technique to=20 > verify addresses=20 > is to send an UPDATE to the host at the new address." and "If=20 > the peer=20 > host is rekeying by sending an UPDATE with NES to the new=20 > address, the=20 > arrival of data on the new SPI can also be used to verify the=20 > address."=20 >=20 > Does this verify the reachability of all addresses listed in=20 > the REA ? No. >=20 > Shouldn't this be "For each of the listed addresses in the REA, .." ?=20 > Something like in draft mm-00 section 4.3 Address verification: "To=20 > acknowledge that it has received the REA, and to initiate an address=20 > check, the HIP host receiving a REA immediately sends an AC to all=20 > addresses mentioned in the REA." Yes, should state "for each" > -Section 5.1 Mobility with single SA pair, "Upon obtaining a new IP=20 > address, the mobile host sends a REA parameter to the peer host in an=20 > UPDATE message. The REA indicates the following: the new IP=20 > address, the=20 > SPI associated with the new IP address, the address lifetime,=20 > and whether=20 > the new address is a preferred address. .. The UPDATE=20 > messages sent from=20 > the peer back to the mobile are sent to the newly advertised address." >=20 > And the "newly advertised address" is defined here as .. ? Preferred=20 > address in the REA, if there is any (and what if not) ? All of the=20 > addresses ? >=20 > Hmm..but wait..ahh..the reader must notice the word "messages", so by=20 > deduction this section should also say "for all of the addresses a=20 > separate UPDATE is sent by the peer..", right ? Yes, this should be clarified as you point out. =20 > In section 5.1 Mobility with single SA pair, "Readdress=20 > without rekeying,=20 > but with address check": >=20 > When a mobile hosts sends UPDATE(REA, SEQ) (Figure 3), must it be=20 > processed in any state (established or rekeying) ? How it should be=20 > processed upon receive ? Can we skip some tests mentioned in the base=20 > draft's section 8.11 Processing UPDATE packets ? Yes, I will refer to 8.11 and remove the redundant text. > A conflict in 5th paragraph of section 7.1 Sending REAs: "All=20 > addresses=20 > corresponding to the SPI have the same lifetime." But the rest of the=20 > discussion on address lifetimes tells that each address have=20 > their own=20 > lifetimes. I think that the quoted sentence should be struck (maybe Pekka has an opinion). The address lifetimes correspond to the IPv6 stateless autoconfiguration lifetimes-- not necessarily the same for all addresses. > 5.7 Initiating the protocol in R1 or I2: >=20 > Should there be some explicit notes about the KEYMAT index to=20 > be used when=20 > retrieving keying materials for the SA(s) if the R1 or I2 contains=20 > (multiple) REA(s) ? Or do we just assume that the=20 > implementors know what=20 > they are doing without telling them. That is, they use the=20 > current KEYMAT=20 > index right after when the HIP keys were drawn. I do not see any harm in adding a sentence for clarity. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Oct 9 02:25:11 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18344 for ; Sat, 9 Oct 2004 02:25:11 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DF43172F3; Sat, 9 Oct 2004 01:16:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 4DDC272EA for ; Sat, 9 Oct 2004 01:15:24 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 911E489877; Sat, 9 Oct 2004 09:23:56 +0300 (EEST) Message-ID: <416783AC.3050408@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: Miika Komu , hipsec@honor.trusecure.com Subject: Re: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 09 Oct 2004 09:22:36 +0300 Date: Sat, 09 Oct 2004 09:22:36 +0300 Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >>>9. If HIP negotiates base exchange using link locals, and one >>>host moves, it will not be able to find its peer >>> >>>Suggested resolution: State that a host SHOULD provide its >>>peer with a globally reachable IP address instead of relying >>>exclusively on link-local addresses. >> >>(the same goes for site-local addresses) > > > site-locals are deprecated, but I think we can address this > generally by saying "locally scoped" or "non-global" address. Statistically unique site-local addresses would probably be OK too, for usage within a site. The problem with the link-local and old site local addresses was not just the connectivity but also potential collisions; you could attempt talking to a node which had nothing to do with the previous node you talked with. The connectivity part is, however, not a major problem as far as I can see. Even global addresses might have connectivity problems in some cases, and we provide multihoming primarily to combat this problem. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Oct 10 22:37:22 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05264 for ; Sun, 10 Oct 2004 22:37:22 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 3846872E8; Sun, 10 Oct 2004 21:28:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by honor.icsalabs.com (Postfix) with ESMTP id 0FBE972E2 for ; Sun, 10 Oct 2004 21:27:53 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B2aVh29093; Mon, 11 Oct 2004 05:36:32 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 05:35:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9B2Z0P0022781; Mon, 11 Oct 2004 05:35:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00j97JyN; Mon, 11 Oct 2004 05:34:59 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B2Ywa06707; Mon, 11 Oct 2004 05:34:58 +0300 (EET DST) Received: from [10.241.50.253] ([10.241.50.253]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 05:34:56 +0300 Message-ID: <4169F148.8010502@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Tim Shepard Cc: Pekka Nikander , Julien Laganier , hipsec@honor.trusecure.com Subject: Re: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig90A14E5CE55C2CD19A479754" X-OriginalArrivalTime: 11 Oct 2004 02:34:56.0547 (UTC) FILETIME=[E56F7F30:01C4AF3A] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 10 Oct 2004 21:34:48 -0500 Date: Sun, 10 Oct 2004 21:34:48 -0500 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig90A14E5CE55C2CD19A479754 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit catching up... ext Tim Shepard wrote: >>Supporting multiple parallel SAs between any pair of HIs >>has been a non-goal for HIP from the beginning. > > > Yes. > > And our thinking on this was that HIs can be easily created, as many > as you like, and only one of two hosts would have to use a different > HI in order to have parallel HIP sessions going simultaneously between > two hosts. We were thinking that typical HIP associations would be > using an ephemeral HI on at least one end (probably the initiator) so > if for some reason you need to open a parallel SA, you just create > another ephemeral HI. Even if there's a situation where you need > non-ephemeral HIs at both ends, then if you need parallel SAs, you can > probably manage to have a different HI at least at one end. > > At least that is what we were thinking, and at this particular moment > I am not convinced that this thinking was in error. > I wasn't expecting so much discussion on this issue. One can of course use new HIs for every simultaneous SA creation, but a) this will make the possibility of HIT collision much higher, b) the user will have to wait for minutes if HIs are to be generated on the fly (may be one can cache all the previously generated HIs, still...) and c) If you want MITM prevention through DNSsec, the DNS database size will explode. Compared to all this, a nonce is somewhat more efficient. If I understand right, I guess the traffic selector is the main objection that people have for not using nonce. But as Julien pointed out, one can use "populate from packets" (PFP) to setup the filters. Also, I am not sure how multiple HIs help. If you have a BITW implementation of IPsec, you still need some mechanism to tell the IPsec filter to select packets based on IP address/port-numbers (the HITs are not present in the packets). So we end with the same problem, don't we? What am I missing here? Yogesh --------------enig90A14E5CE55C2CD19A479754 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWnxTHkjMhOId4nzAQKZoQgApNSCCGDbACL20hG88Yg8hJkb1zu/+P08 7zPiwZH8wYXpKOGF535vLkU77j7IkHHocax9vvGJlywLF9oi4gX/jHa9cf9Vh4Dj 0a6Oob0dEVYYrqvE9Y9X5j2R8AaPlZwNbd+ZLf4zF3quBDDXrco422+r9z2FS46N pelz6zqb9WLkAqZCRLSl5lNt5lRq0n257PRt5EwA0qH1n8Nmeu5N+IFmjjR3R18w bzx630/UzmeYdJoPupW3FfkyHuBAxMvgetgMNF6UuqC5Hv8TgEHgipukEd2aksxD HF/cNn+k1qPmITzW3STXyxLxfvzQV1yklIGyQh/YvvVFzw7uq1r2zQ== =OZjQ -----END PGP SIGNATURE----- --------------enig90A14E5CE55C2CD19A479754-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Oct 10 22:43:17 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05830 for ; Sun, 10 Oct 2004 22:43:16 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 40D4A72F3; Sun, 10 Oct 2004 21:34:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by honor.icsalabs.com (Postfix) with ESMTP id 0B8BE72E2 for ; Sun, 10 Oct 2004 21:33:06 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B2fph07348; Mon, 11 Oct 2004 05:41:51 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 05:40:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9B2eRoJ002920; Mon, 11 Oct 2004 05:40:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vxoaKD; Mon, 11 Oct 2004 05:40:26 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B2eJa10257; Mon, 11 Oct 2004 05:40:19 +0300 (EET DST) Received: from [10.241.50.253] ([10.241.50.253]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 05:40:04 +0300 Message-ID: <4169F281.8000703@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> In-Reply-To: <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD9BE0ED44EAF8E977C004A9B" X-OriginalArrivalTime: 11 Oct 2004 02:40:04.0728 (UTC) FILETIME=[9D202F80:01C4AF3B] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sun, 10 Oct 2004 21:40:01 -0500 Date: Sun, 10 Oct 2004 21:40:01 -0500 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9BE0ED44EAF8E977C004A9B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pekka, Please see in line: ext Pekka Nikander wrote: > Yogesh, > > >> I have also added nonce-I and nonce-R in all these message. This is >> important to allow parallel SA creation, and allow cases where both >> initiator and responder choose pre computed g^i and g^r (this can >> happen, unless the draft explicitly prevents it). The nonce should >> be used in deriving the session keys. > > > As was discussed in other messages, parallel SAs between any > given pair of HITs is a non-goal. I'd like to understand better > your reference to pre-computed D-H keys by both parties. Would > you care to explain? > Let's say, both the sides, Alice and Bob, use precomputed values of g^x and g^y. Let's also say that both Alice and Bob update their g^x and g^y only once every hour. That means, during that one hour period, no matter how many HIP exchange Alice and Bob do, they will end up with the same Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which will be the same). This can have quite a few security implications. For example, replay protection will become weak, because an attacker can now inject packets from previous sessions and simple sequence numbers and HMAC based authentication will not be able to detect it (Assuming the session was not using any form of Initialization Vectors). >> 1. I->R: NCN-I, 0, HIT-I, [HIT-R] >> >> 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R >> SIG( HIT-R, g^r, PUBLIC_KEY-R) >> >> >> 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, >> { PUBLIC_KEY-I, Domain-ID-I }_g^ri, >> SIG( HIT-I, HIT-R, SPI, g^i, >> { PUBLIC_KEY-R, Domain-ID }_g^ri, ) >> *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* >> >> 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), >> HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content >> has changed */ > > > If I understand correctly, and leaving aside the issue of nonces, > the only differences are the addition of HMAC to I2 and the > change of the HMAC contents in R2. They seem OK to me. > >> o In the draft it's important to say that the responder should keep >> the random value r for at least 2*MSL (and possibly longer) from the >> last time it sent message 2. In case Message 3 arrives after 2*MSL, >> and no random number r can be found, it should be dropped and an ICMP >> message should be sent. If the Initiator receives an ICMP after >> sending message-3, it should not assume that the responder sent >> the message, and should not close that session. An Initiator >> MAY however start with a new parallel I1 with a new nonce value. > > > Sounds OK to me. I guess most of this is already implied by the > draft, but it would be much better to be explicit. Petri your Yogesh, > could you provide us with some concrete proposal? > >> Couple of observations about this key exchange: >> >> A) The identity of Responder cannot be concealed even against the >> passive attack. The HOST_ID in message-2 is required so that the >> Initiator can get the public-key to verify the SIGNATURE from >> responder. > > > Yes. One way to address this has been discussed in the BLIND > paper by Jukka Ylitalo and me, in this year's Cambridge Security > Protocols Workshop. See Jukka's or my publications web pages. > >> B) The identity of Initiator cannot be concealed against an active >> attacker unless g^r is covered in SIGNATURE calculation in >> message-2. (So keep section-7 description and change section-4 text) > > > Sounds OK to me. > >> (A) and (B) together means that if we want to get responders ID >> protection then we need to severely reorganize the messages. > > > Yes. We are aware of that. See the above mentioned paper. > >> One simple thing one can do is to only send the public-key and >> in message-2 (and leave Domain-ID-R field completely out). > > > That doesn't help much, since in HIP the public key IS the real > identifier. The hostname/NAI is only considered as auxliary > information. You may learn the association between the public > key and the hostname/NAI also from the DNS or some other databse. > I agree. But the HIs alone are somewhat hard to work with. When a hosts grants access to resources, it needs to know who the person on the other side is, and that's why I consider names bound to HIs to be a fundamental component to identity. This can also have scalability issues (for example, with e-mail addresses you can grant access to every one with address for example as *.acm.org. With HIs one will have to list all the HIs, which is error prone and takes a lot more space). >> Later, >> Responder can put Domain-ID as encrypted in message-4 and let Initiator >> verify it against the MAC received in message-2. The advantage is that >> we can now protect the identity of Initiator against passive attacker >> and the Identity of responder against Active attackers. The disadvantage >> is that the Initiator's ID cannot be protected against active attackers. > > > It was a deliberate choice to err on protecting the initiator's > privacy more than the responder's. > But now, if an attacker, Eve, wants to get the Identity of the Initiator, Alice, all Eve has to do is to just take Alice's HIT (from an exchange that she started) and send an I1 to Alice. Alice, on seeing I1 will herself give her identity out in R1. >> Note that protecting the Public-Key alone without Domain-ID is not >> that useful. The worst thing that an attacker can do by stealing the >> public key is to register it under her own name (i.e., Eve takes >> Alice's public key and puts it in DNSsec under Eve's name, assuming >> DNSsec doesn't do proof of possession checks). > > > Binding of public keys and external identifiers, such as hostnames > or NAIs, is currently outside the scope of the WG charter. The > architectural stance is that the public key is the primary identifier, > and getting the public key from a human understandable name is a > separate problem. see above. > >> But the HMAC binding to >> name in SIGMA prevents from attacks that can result from this kind of >> behavior, so it's not that useful to protect the public-key. Note >> that this is the reason I have added HOST_ID in message-4. HMACing >> only HITs will get us in trouble. > > > I don't see any adverse effects of adding the HOST_ID to the > HMACs, even though I doubt its value. The kind of identity > stealing attack that you describe belongs, from an architectural > point of view, beyond the HIP base spec. On the other hand, > if we can this easily provide some extra security, then why not. > > In summary: I am in favour of making these two changes: > - adding a HMAC to I2 > - changeing the R2 HMAC contents > > I still haven't been convinced about the nonces. The multiple-SA > argument doesn't hold as it is a non-goal. I haven't seen > explicit argumentation about using nonces for keymat generation. > Okay, the theory for using nonce (or any random data) in keymat goes as follows (my apologizes, if I am repeating well known stuff): The fact that an attacker cannot generate g^xy from g^x and g^y in itself is not sufficient to guarantee that the scheme is secure. Even though an attacker cannot exactly compute g^xy from g^x and g^y, she can still guess 60%-80% of bits of g^xy with a high (~ 0.95) probability. (For example, some people believe that the generator 2 leaks information about x in 2^x (mod p) because 2^x = (1+1)^x = 1 + x + x(x-1)/2 + .... by binomial expansion -- an expression with only x on right hand side. Of course no one has shown, to the best of my knowledge, how to predict the bits of g^xy (mod p) based on this or any similar information.) So to make the scheme more secure, what one needs is that given (g^x, g^y, and g^xy) an attacker should not be able to distinguish it from the distribution of (g^x, g^y, and g^Random_number). There are lots of papers on this problem (called the Decision Diffie-Hellman (DDH) problem). To achieve this, g^xy is MACed to get rid of the non-uniform distribution of bits of g^xy and make it look more like g^random_number (actually if there is a better Pseudo Random Number Generator (PRG) than MACs, then that PRG should be used instead). For a MAC to generate a uniform distribution it should have enough entropy in the input stream. Adding a nonce (or any random data) helps in that sense. Note that the present KEYMAT also MACs the HITs, but the amount of entropy of HITs combined (=127*2) is much less that the size of g^xy (=1024 bits). So how much MAC will be able to get rid of predictability of g^xy is not clear (it might be sufficient; I haven't been closely following crypto stuff after 2001, so I don't know what new developments have taken place). Adding the nonce in key generation might help from that POV. If you don't want to add a nonce, then just adding some random data will also help (e.g., using the entire R1 and I2 packets in KEYMAT generation). Yogesh --------------enigD9BE0ED44EAF8E977C004A9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWnygXkjMhOId4nzAQLbVwgAj7YES64v6htAAtG9iOfXRdEY135FixNG K10uIVrVt65Arzn4xjfTDQcqALdNzjEWU8rihVIrJn+TPullGrjF2TGVTjDy/+n9 M2oLoJabyGx01XQzYIn2rcoRnvAQtjwPiQZ4qs3olXCWrO6OKsvgHT/sQ/IRWQOg qJ+qSnLOlN54KuwoEgbaJm27dF+B7UhdhP0Q060u5LAUSrF1/Wbahpyrq1BKC++c rO3q9rc8dqt/zh4OjTq29NRKQQuLABGFGsmids/t90tpG88dc4vs7trB0WslnOr1 mQ8Xv079EjB6lJ7BZsLkhUoMbdGG508+OktveXZenZZ+0F7w0sOA2Q== =LeaH -----END PGP SIGNATURE----- --------------enigD9BE0ED44EAF8E977C004A9B-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 02:05:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24306 for ; Mon, 11 Oct 2004 02:05:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DBF2872E8; Mon, 11 Oct 2004 00:56:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id DBC8672E2 for ; Mon, 11 Oct 2004 00:55:05 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 743DB220004; Mon, 11 Oct 2004 09:03:42 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id E77B88; Mon, 11 Oct 2004 09:03:42 +0300 (EEST) In-Reply-To: <4169F148.8010502@acm.org> References: <4169F148.8010502@acm.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Julien Laganier , ext Tim Shepard , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) To: Yogesh Prem Swami X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 09:03:51 +0300 Date: Mon, 11 Oct 2004 09:03:51 +0300 Content-Transfer-Encoding: 7bit > If I understand right, I guess the traffic selector is the main > objection that people have for not using nonce. But as Julien > pointed out, one can use "populate from packets" (PFP) to setup > the filters. As far as I have understood the thinking of the community (the chairs may correct), the current belief is that if someone wants to have traffic selectors and multiple parallel SAs for policy reason, the right thing to do is to write an extension, present it at the RG side, and sense the feeling of the community at the re-chartering time. Hence, IMHO, that discussion should be moved to the RG mailing list. > Also, I am not sure how multiple HIs help. If you have a BITW > implementation of IPsec, you still need some mechanism to tell > the IPsec filter to select packets based on IP address/port-numbers > (the HITs are not present in the packets) At least my understanding has been that iff you are dealing with legacy hosts and therefore BITW IPsec, you just configure your host to use either LSIs (1.0.0.0/8) or HITs (4000::0/2) on the local link. Contrary what the docs says, in that special case you do have LSIs or HITs in IP headers on the wire. Hence, you will have HITs (or at least LSIs) even in a BITW implementation. Other than that, properply implementing HIP support on a BITW box is pretty impossible. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 02:10:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29173 for ; Mon, 11 Oct 2004 02:10:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id F10A372E8; Mon, 11 Oct 2004 01:01:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 50D7472E2 for ; Mon, 11 Oct 2004 01:00:21 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 0CD9A220004; Mon, 11 Oct 2004 09:09:07 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 408638; Mon, 11 Oct 2004 09:09:07 +0300 (EEST) In-Reply-To: <4169F281.8000703@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <143BE305-1B4C-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Jukka Ylitalo , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward To: Yogesh Prem Swami X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 09:09:15 +0300 Date: Mon, 11 Oct 2004 09:09:15 +0300 Content-Transfer-Encoding: 7bit Yogesh, This is very good and educating discussion, at least to me. Thanks again for bringing this up, even if I seem to oppose quite a lot of what you say :-) >> I'd like to understand better >> your reference to pre-computed D-H keys by both parties. Would >> you care to explain? > > Let's say, both the sides, Alice and Bob, use precomputed values of g^x > and g^y. Let's also say that both Alice and Bob update their g^x and > g^y > only once every hour. That means, during that one hour period, no > matter > how many HIP exchange Alice and Bob do, they will end up with the same > Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which > will be the same). Well, my understanding has been that you shouldn't reuse your DH-key, ever. (Maybe the docs don't say that.) That is, you should have a pool of precomputed R1s, use that pool pretty uniformingly while they are valid, and once you get an I2 for a given R1, cease transmitting it. When some R1s expire, you can reuse the DH keys in them after a while, i.e., when it looks like that you won't get any I2 on them. Since all this is supposed to be (mostly) stateless, implementing this in practise is pretty hard, though. Hence, while I don't buy your argument above, there still seems to be of some value. >> ... in HIP the public key IS the real >> identifier. The hostname/NAI is only considered as auxliary >> information. You may learn the association between the public >> key and the hostname/NAI also from the DNS or some other databse. > > I agree. But the HIs alone are somewhat hard to work with. When a hosts > grants access to resources, it needs to know who the person on the > other > side is, and that's why I consider names bound to HIs to be a > fundamental component to identity. From a practical point of view, I can't help but agree. However, from an architectural purity point of view, I bitterly disagree. :-) > This can also have scalability issues > (for example, with e-mail addresses you can grant access to every one > with address for example as *.acm.org. With HIs one will have to list > all the HIs, which is error prone and takes a lot more space). Right. That's why the HAA HITs were introduced. The recent development has pretty much ignored them, but I expect them to pop up later. OTOH, you have to remember that you have to store either the HITs or the HIs somewhere, in order to be (reasonably) secure. It may be enough to store a wild card name locally, but then you still need to have access to a trusted binding between the names and HIs. I'd most probably attempt to solve this problem with SDSI/SPKI name certificates, without storing anything locally, if space is of concern. Hence, the name transferred as a part of the HIP base exchange really is just auxliary information. You can't trust it, in no way, as you can't trust your peer. In fact, if the proposed DHT infra was there in place, we most probably wouldn't need the HOST_ID payload at all. >> It was a deliberate choice to err on protecting the initiator's >> privacy more than the responder's. > > But now, if an attacker, Eve, wants to get the Identity of the > Initiator, Alice, all Eve has to do is to just take Alice's HIT (from > an > exchange that she started) and send an I1 to Alice. Alice, on seeing I1 > will herself give her identity out in R1. That depends on the policy Alice has. If the associated HI is non-public, the case may be that Alice doesn't reply to any I1s asking to connect to it. Again, if you want to have full privacy with HIP, you most probably need to go to something like BLIND. (And there you have the nonces, too :-). Hence, I don't see much value in changing the base spec at this point of time. But, as I wrote above, this discussion is very useful and preferably should be preserved in some form. I think we should either write another draft, or add an informational appendix on the base spec. >> I still haven't been convinced about the nonces. The multiple-SA >> argument doesn't hold as it is a non-goal. I haven't seen >> explicit argumentation about using nonces for keymat generation. > > Okay, the theory for using nonce (or any random data) in keymat goes as > follows (my apologizes, if I am repeating well known stuff): The fact > that an attacker cannot generate g^xy from g^x and g^y in itself is not > sufficient to guarantee that the scheme is secure. Even though an > attacker cannot exactly compute g^xy from g^x and g^y, she can still > guess 60%-80% of bits of g^xy with a high (~ 0.95) probability. (For > example, some people believe that the generator 2 leaks information > about x in 2^x (mod p) because 2^x = (1+1)^x = 1 + x + x(x-1)/2 + .... > by binomial expansion -- an expression with only x on right hand side. > Of course no one has shown, to the best of my knowledge, how to predict > the bits of g^xy (mod p) based on this or any similar information.) Ok. This was new to me. (I haven't been really following crypto since 1999.) > So to make the scheme more secure, what one needs is that given (g^x, > g^y, and g^xy) an attacker should not be able to distinguish it from > the > distribution of (g^x, g^y, and g^Random_number). There are lots of > papers on this problem (called the Decision Diffie-Hellman (DDH) > problem). I see. The first time I hear about this. Mea culpa. > To achieve this, g^xy is MACed to get rid of the non-uniform > distribution of bits of g^xy and make it look more like g^random_number > (actually if there is a better Pseudo Random Number Generator (PRG) > than > MACs, then that PRG should be used instead). > > For a MAC to generate a uniform distribution it should have enough > entropy in the input stream. Adding a nonce (or any random data) helps > in that sense. Note that the present KEYMAT also MACs the HITs, but > the amount of entropy of HITs combined (=127*2) is much less that the > size of g^xy (=1024 bits). So how much MAC will be able to get rid of > predictability of g^xy is not clear (it might be sufficient; I haven't > been closely following crypto stuff after 2001, so I don't know what > new developments have taken place). > > Adding the nonce in key generation might help from that POV. If you > don't want to add a nonce, then just adding some random data will also > help (e.g., using the entire R1 and I2 packets in KEYMAT generation). Good goal. However, my current suggestion would be not to add nonces to the base spec. Adding HMAC to I2 and revising the R2 HMAC looks small enough that we can do that easily and safely enough. But adding nonces seems to have architectural implications that I don't quite understand. Hence, I would leave that for later. What do others think? However, I would encourage you to work towards a revision of BLIND, perhaps together with Jukka. (I am currently too busy to write papers.) As the key generation in BLIND is, by necessity, different from base HIP, including the nonces into key generation seems like a natural thing. My personal guess is that we most probably want to adopt some aspects of BLIND for the next revision of HIP, but given the pressures to get a stable specification out for experimentation, I would leave all this nonce stuff for future, and not change the current spec in that respect. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 03:20:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08583 for ; Mon, 11 Oct 2004 03:20:19 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AA3E472E8; Mon, 11 Oct 2004 02:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 903EB72E2 for ; Mon, 11 Oct 2004 02:10:05 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id F1D4832D4; Mon, 11 Oct 2004 10:18:51 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9B7IpP07575; Mon, 11 Oct 2004 10:18:51 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Yogesh Prem Swami Cc: ext Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4169F281.8000703@acm.org> Message-ID: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 10:18:51 +0300 (EEST) Date: Mon, 11 Oct 2004 10:18:51 +0300 (EEST) On Sun, 10 Oct 2004, Yogesh Prem Swami wrote: > > As was discussed in other messages, parallel SAs between any > > given pair of HITs is a non-goal. I'd like to understand better > > your reference to pre-computed D-H keys by both parties. Would > > you care to explain? > > > > Let's say, both the sides, Alice and Bob, use precomputed values of g^x > and g^y. Let's also say that both Alice and Bob update their g^x and g^y > only once every hour. That means, during that one hour period, no matter > how many HIP exchange Alice and Bob do, they will end up with the same > Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which > will be the same). > > This can have quite a few security implications. For example, replay > protection will become weak, because an attacker can now inject packets > from previous sessions and simple sequence numbers and HMAC based > authentication will not be able to detect it (Assuming the session was > not using any form of Initialization Vectors). The base spec says: "The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes." The case for long period of DH regeneration may be valid for devices with limited CPU resources (e.g. PDAs or overloaded servers). At the moment, I cannot remember how much CPU resources DH generation eats up in practice. If we decide to tangle the nonce into the KEYMAT derivation, we can still use the current scheme, i.e., grab the nonce from the echo request/reply messages. The nonce propably needs to be sufficiently large so that it really enhances the security. For practical reasons, is may be better that the length of the nonce is constant. We should also note that we probably want the nonce to be covered by the signature because otherwise the nonce can be tampered by an passive attacker (i.e. rogue host in the path of the message). This is problematic from the view point of precreated R1s because changing the nonce requires changing the precreated R1s (or a yet another index, based on nonce, to the table of R1s). > >> 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > >> > >> 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > >> SIG( HIT-R, g^r, PUBLIC_KEY-R) > >> > >> > >> 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > >> { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > >> SIG( HIT-I, HIT-R, SPI, g^i, > >> { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > >> *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > >> > >> 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > >> HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > >> has changed */ > > > > > > If I understand correctly, and leaving aside the issue of nonces, > > the only differences are the addition of HMAC to I2 and the > > change of the HMAC contents in R2. They seem OK to me. For practical reasons, maybe the HMAC should cover the whole packet, not just few fields. The overhead should not be too significant, and it should be easier to implement. In addition, I find the "pseudo-HMAC" scheme above a bit difficult to implement; in the third and fourth packets, the HMAC covers parameters that are not present in the packet (3. packet g^r, 4. packet g^ir). Alternatively, we could have: I2: IP ( HIP ( SPI, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, /* g^i */ DIFFIE_HELLMAN, /* g^r (is this really needed?) */ HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, [ ECHO_RESPONSE ], HMAC, HIP_SIGNATURE, [ECHO_RESPONSE] ) ) R2: IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) In this version, the HMAC covers the whole I2. There is no pseudo-HMAC; the initiator has to include both of the DH parameters to the responder. I am not completely sure if both of DH parameters need to be sent in I2 (Yogesh, opinion?) but it seems to be so in the SIGMA. Maybe the pseudo-HMAC scheme is better from the viewpoint of security as you don't echo the g^ir again on the wire. Anyway, the g^ir has been exposed already. The R2 remains the same as in the current draft because I coupled HIP with SIGMA-I. I interpreted the R2 as an "SIGMA ACK" that guarantees the peer awareness property. In a more strict sense, the R2 is not just a plain ack because it includes the SPI. I don't see this as a problem because the HMAC already protects against R2 replication attacks (e.g. man-in-the-middle host tries to record R2s, and tries to DoS the initiator with incorrect SPIs). > > That doesn't help much, since in HIP the public key IS the real > > identifier. The hostname/NAI is only considered as auxliary > > information. You may learn the association between the public > > key and the hostname/NAI also from the DNS or some other databse. > > > > I agree. But the HIs alone are somewhat hard to work with. When a hosts > grants access to resources, it needs to know who the person on the other > side is, and that's why I consider names bound to HIs to be a > fundamental component to identity. This can also have scalability issues > (for example, with e-mail addresses you can grant access to every one > with address for example as *.acm.org. With HIs one will have to list > all the HIs, which is error prone and takes a lot more space). You need certificates to guarantee that hostname/NAI is not forged. Until then, it can be considered only as informational. > >> Later, > >> Responder can put Domain-ID as encrypted in message-4 and let Initiator > >> verify it against the MAC received in message-2. The advantage is that > >> we can now protect the identity of Initiator against passive attacker > >> and the Identity of responder against Active attackers. The disadvantage > >> is that the Initiator's ID cannot be protected against active attackers. > > > > It was a deliberate choice to err on protecting the initiator's > > privacy more than the responder's. > > But now, if an attacker, Eve, wants to get the Identity of the > Initiator, Alice, all Eve has to do is to just take Alice's HIT (from an > exchange that she started) and send an I1 to Alice. Alice, on seeing I1 > will herself give her identity out in R1. The scenario you described seems to be a valid concern. HIP, as currently specified, does not take as good care as SIGMA-I of the initiator's identity. However, the problem can be alleviated with the policies described by Pekka in the previous email. I don't understand how the encrypted domain-ID does the trick. IMHO, to really solve the case, we need to hide the initiator's HIT in the HIP header. Perhaps we could use blinded HITs in HIPv2 as already suggested in earlier email from Pekka. A null HIT for the initiator has other problems. Btw, I did not see a direct correspondence between SIGMA-I/R and HIP. For example, the responder's identity cannot be encrypted. Also, the first message in SIGMA-I/R contains already the public DH key of the initiator, and we need to move it to the third message in HIP. However, I don't think this was of great importantance in SIGMA. The emphasis was on the following rules-of-thumb that can reused also in HIP (as Yogesh already suggested): * keep the HMAC key different from the other keys derived from KEYMAT (as they are in HIP) * each packet should include either a NONCE or DH * DH is covered by the SIGNATURE * The HOST_ID is covered by the HMAC -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 07:24:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25270 for ; Mon, 11 Oct 2004 07:24:24 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 93C6672E8; Mon, 11 Oct 2004 06:15:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id A69C172E2 for ; Mon, 11 Oct 2004 06:14:53 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 46D80220004; Mon, 11 Oct 2004 14:23:40 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 76C1E8; Mon, 11 Oct 2004 14:23:39 +0300 (EEST) In-Reply-To: <416783AC.3050408@piuha.net> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> <416783AC.3050408@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com, Miika Komu From: Pekka Nikander Subject: Re: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 14:23:31 +0300 Date: Mon, 11 Oct 2004 14:23:31 +0300 Content-Transfer-Encoding: 7bit >>>> 9. If HIP negotiates base exchange using link locals, and one >>>> host moves, it will not be able to find its peer >>>> >>>> Suggested resolution: State that a host SHOULD provide its >>>> peer with a globally reachable IP address instead of relying >>>> exclusively on link-local addresses. >>> >>> (the same goes for site-local addresses) >> site-locals are deprecated, but I think we can address this >> generally by saying "locally scoped" or "non-global" address. > > Statistically unique site-local addresses would probably be OK > too, for usage within a site. The problem with the link-local > and old site local addresses was not just the connectivity > but also potential collisions; you could attempt talking to > a node which had nothing to do with the previous node you > talked with. The connectivity part is, however, not a major > problem as far as I can see. Even global addresses might > have connectivity problems in some cases, and we provide > multihoming primarily to combat this problem. I agree. However, I think a SHOULD for non-global is the right choice now, as we the Hinden-Haberman addresses are not quite RFC yet. If they become an RFC, we can return to this and revise? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 07:31:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25698 for ; Mon, 11 Oct 2004 07:31:21 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AFF9C72F3; Mon, 11 Oct 2004 06:22:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 947E772E8 for ; Mon, 11 Oct 2004 06:21:52 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id C2422220004; Mon, 11 Oct 2004 14:30:39 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2DA188; Mon, 11 Oct 2004 14:30:40 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Miika Komu" , From: Pekka Nikander Subject: Re: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 14:30:37 +0300 Date: Mon, 11 Oct 2004 14:30:37 +0300 Content-Transfer-Encoding: 7bit > Here is proposed text for a replacement of the third paragraph in > Section 5.2: > "IPsec SAs are unidirectional, and the protocol may support > configurations > in which an asymmetric number of inbound and outbound SAs exist on a > given > host with respect to another host. However, for the purpose of > handling > multihoming more cleanly, it is RECOMMENDED that inbound and outbound > SAs > be created and maintained in a pairwise fashion between hosts, and that > when rekeying occurs on one SA, it is also triggered on the paired SA. > For > example, the HIP base exchange results in two SAs-- one inbound and one > outbound on each host. If one of the two hosts wants to advertise > another > interface to its peer, it should add a new inbound SA and send a REA > (and > NES) to the peer. The peer should also create a new inbound SA. These > two new SAs are also paired. Subsequently, when a rekey occurs on one > SA, > a corresponding rekey is performed on the paired SA, with no ambiguity. > Implementations that fail to follow the above guidelines may fail to > interoperate cleanly." Looks good to me other than the last statement, which I would tune down. Maybe: "Note that it is possible that implementations that fail to follow the above guidelines may fail to interoperate with some implementations. However, it is recommended that implementations attempt to support peers that prefer to utilise non-paired SAs." And, maybe add at least the following: "It is expected that this section and behaviour will be modified in some future revision of this protocol, once the issue and its implications are understood better." >> A conflict in 5th paragraph of section 7.1 Sending REAs: "All >> addresses >> corresponding to the SPI have the same lifetime." But the rest of the >> discussion on address lifetimes tells that each address have >> their own >> lifetimes. > > I think that the quoted sentence should be struck (maybe Pekka has > an opinion). The address lifetimes correspond to the IPv6 stateless > autoconfiguration lifetimes-- not necessarily the same for all > addresses. That sentence was an optimisation that allowed only one lifetime to be sent for a group of addresses. I don't remember how the packet format is today; the sentence can be removed if the packet format supports different lifetimes. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 07:41:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26415 for ; Mon, 11 Oct 2004 07:41:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 501FF72F3; Mon, 11 Oct 2004 06:32:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id E0D7F72EA for ; Mon, 11 Oct 2004 06:31:21 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A5EEA89877; Mon, 11 Oct 2004 14:40:06 +0300 (EEST) Message-ID: <416A70C2.5020807@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com, Miika Komu Subject: Re: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> <416783AC.3050408@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 14:38:42 +0300 Date: Mon, 11 Oct 2004 14:38:42 +0300 Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > I agree. > > However, I think a SHOULD for non-global is the right choice now, > as we the Hinden-Haberman addresses are not quite RFC yet. > If they become an RFC, we can return to this and revise? Works for me. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 07:47:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27005 for ; Mon, 11 Oct 2004 07:47:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 00EA372F4; Mon, 11 Oct 2004 06:38:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by honor.icsalabs.com (Postfix) with ESMTP id A540472F3 for ; Mon, 11 Oct 2004 06:37:21 -0400 (EDT) Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i9BBk9UD007578 for ; Mon, 11 Oct 2004 14:46:09 +0300 From: Mika Kousa To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 14:46:09 +0300 (EEST) Date: Mon, 11 Oct 2004 14:46:09 +0300 (EEST) 5.1 Mobility with single SA pair Mobile Host Peer Host UPDATE(REA, SEQ) -----------------------------------> UPDATE(SPI, SEQ, ACK, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> Figure 3: Readdress without rekeying, but with address check Now that we have seen the change needed for address check procedure (ECHO_REQUESTs are sent to each of the addresses listed in the REA, see this same thread), this section needs some editing. Peer Host does not need to send ACK for the REA-UPDATE in every UPDATE it sends related to address check procedure, it could send just ACK-UPDATE and after that the Peer Host sends the ECHO_REQUEST-UPDATEs: For example: Mobile Host Peer Host UPDATE(REA(addr_1,addr_2), SEQ) -----------------------------------> UPDATE(ACK) <----------------------------------- sent to addr_1: UPDATE(SPI, SEQ, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> sent to addr_2: UPDATE(SPI, SEQ, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> ... Maybe the other figures and related texts in section 5 need similar changes when there is a possibility that REA contains many addresses, too. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 08:13:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29611 for ; Mon, 11 Oct 2004 08:13:21 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8CC1772F4; Mon, 11 Oct 2004 07:04:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 4874A72F2 for ; Mon, 11 Oct 2004 07:03:56 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4DAA43312; Mon, 11 Oct 2004 15:12:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9BCChc26458; Mon, 11 Oct 2004 15:12:43 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Miika Komu Cc: Yogesh Prem Swami , ext Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message-ID: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 15:12:43 +0300 (EEST) Date: Mon, 11 Oct 2004 15:12:43 +0300 (EEST) On Mon, 11 Oct 2004, Miika Komu wrote: > We should also note that we probably want the nonce to be covered by the > signature because otherwise the nonce can be tampered by an passive > attacker (i.e. rogue host in the path of the message). This is problematic > from the view point of precreated R1s because changing the nonce requires > changing the precreated R1s (or a yet another index, based on nonce, to > the table of R1s). I'll take this back. The nonce does not have to be covered by the signature because the the purpose of the nonce is not to provide integrity protection. > For practical reasons, maybe the HMAC should cover the whole packet, not > just few fields. The overhead should not be too significant, and it should > be easier to implement. In addition, I find the "pseudo-HMAC" scheme above > a bit difficult to implement; in the third and fourth packets, the HMAC > covers parameters that are not present in the packet (3. packet g^r, 4. > packet g^ir). > > Alternatively, we could have: > > I2: IP ( HIP ( SPI, > [R1_COUNTER,] > SOLUTION, > DIFFIE_HELLMAN, /* g^i */ > DIFFIE_HELLMAN, /* g^r (is this really needed?) */ > HIP_TRANSFORM, > ESP_TRANSFORM, > ENCRYPTED { HOST_ID }, > [ ECHO_RESPONSE ], > HMAC, > HIP_SIGNATURE, > [ECHO_RESPONSE] ) ) > > R2: IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) > > In this version, the HMAC covers the whole I2. There is no pseudo-HMAC; > the initiator has to include both of the DH parameters to the responder. I > am not completely sure if both of DH parameters need to be sent in I2 > (Yogesh, opinion?) but it seems to be so in the SIGMA. Maybe the > pseudo-HMAC scheme is better from the viewpoint of security as you don't > echo the g^ir again on the wire. Anyway, the g^ir has been exposed > already. I think I misunderstood the notation here. g^ir (or g^xy) is the shared Diffie-Hellman secret, not the concatenation of the Diffie-Hellman parameters. Just forget my alternative above =) So, I guess we need to include the shared secret in the calculation of the HMAC in I2 and R2? Still, I am a bit confused why this should be done. Yogesh, would you care to explain this point in more depth? I am not a crypto specialist... -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 08:20:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00356 for ; Mon, 11 Oct 2004 08:20:21 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4D5B572F9; Mon, 11 Oct 2004 07:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 8CCCA72F4 for ; Mon, 11 Oct 2004 07:10:47 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id AC013220004; Mon, 11 Oct 2004 15:19:34 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 325E38; Mon, 11 Oct 2004 15:19:35 +0300 (EEST) In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com, Yogesh Prem Swami From: Pekka Nikander Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward To: Miika Komu X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 15:19:34 +0300 Date: Mon, 11 Oct 2004 15:19:34 +0300 Content-Transfer-Encoding: 7bit >> For practical reasons, maybe the HMAC should cover the whole packet, >> not >> just few fields. The overhead should not be too significant, and it >> should >> be easier to implement. In addition, I find the "pseudo-HMAC" scheme >> above >> a bit difficult to implement; in the third and fourth packets, the >> HMAC >> covers parameters that are not present in the packet (3. packet g^r, >> 4. > > I think I misunderstood the notation here. g^ir (or g^xy) is the shared > Diffie-Hellman secret, not the concatenation of the Diffie-Hellman > parameters. Just forget my alternative above =) > > So, I guess we need to include the shared secret in the calculation of > the > HMAC in I2 and R2? Still, I am a bit confused why this should be done. > Yogesh, would you care to explain this point in more depth? I am not a > crypto specialist... For practical purposes, we apparently need to use a different HMAC parameter type for I2 and R2, as they do not cover the packets but extra-protocol information. But that also makes it easier to either place it under the signature or outside, dependent on which is better. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 08:45:21 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02647 for ; Mon, 11 Oct 2004 08:45:21 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6ACF57302; Mon, 11 Oct 2004 07:36:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 3F9FC72F9 for ; Mon, 11 Oct 2004 07:35:24 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 6FEAD3316; Mon, 11 Oct 2004 15:44:12 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9BCiAp28719; Mon, 11 Oct 2004 15:44:10 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Cc: hipsec@honor.trusecure.com In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hipsec] Re: review of comments on draft-ietf-hip-mm-00 preview Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 15:44:10 +0300 (EEST) Date: Mon, 11 Oct 2004 15:44:10 +0300 (EEST) On Fri, 8 Oct 2004, Henderson, Thomas R wrote: > Responding below to a number of (mostly Miika's) comments: (You are confusing me with Mika. Most of the comments were from Mika. To confuse even more, we also have a "Miikka" at work. Fortunately, for your sake, he is not working on anything related to HIP ;) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 12:59:32 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21866 for ; Mon, 11 Oct 2004 12:59:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B789C72E8; Mon, 11 Oct 2004 11:50:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 543CA72E2 for ; Mon, 11 Oct 2004 11:49:00 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9BGvlNH023773 for ; Mon, 11 Oct 2004 10:57:47 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5F00FO5J44HA@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 11 Oct 2004 10:57:47 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5F00FHDJ3Z46@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 11 Oct 2004 10:57:39 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Recovery from state loss In-reply-to: <4166764D.1060401@nomadiclab.com> To: Petri Jokela , Pekka Nikander , Erik Nordmark , "Henderson, Thomas R" Cc: HIPsec Message-id: <200410111858.59103.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)" User-Agent: KMail/1.7 References: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4166764D.1060401@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 18:58:58 +0200 Date: Mon, 11 Oct 2004 18:58:58 +0200 --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT On Friday 08 October 2004 13:13, Petri Jokela wrote: > Pekka Nikander wrote: > > Looks good, thanks! > > > > Maybe it would be better to have different messages for these > > purposes? That is, in the UNASSOCIATED state, if you receive > > a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable > > error code. In that way the CLOSE_ACK message would be only > > used for acknowledging CLOSE. > > > > A related issue is whether we should allow/require a "CLOSED" > > state. A host sending a CLOSE_ACK would enter a "CLOSED" > > state for a certain period (2 * timeout?), and during that > > time it would be able to send further CLOSE_ACK messages in the > > case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) > > It would then automatically move to UNASSOCIATED if it receives > > no CLOSE messages within that period. > > > > I don't think the CLOSED state is necessarily needed, or should > > be mandated, but it sounds to be as a nice engineering > > optimisation that some implementations might want to do. > > Thanks Julien for the text! > > I modified a bit Julien's proposal according to Pekka's comments. > My notes are included in the text. Outgoing/incoming data traffic > text needs still something For example when the association is not > dropped in the CLOSED state and there is some data that would > belong to this association. Thanks Pekka and Petri, the modified text looks quite good. Attached are some answers/questions, correction to the text and suggested text for Security Considerations. Cheers, --julien --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA) Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK2 Content-disposition: attachment; filename=CLOSEACK2 Content-Transfer-Encoding: quoted-printable 5.4.2 =A0HIP State Processes <**PJ**> =A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOS= E, not =A0 =A0 =A0 =A0 =A0written down here <**PJ**> <**JL**> Why not? <**JL**> =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED| =A0Start state =A0 =A0 +------------+ =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED =A0 =A0 Receive CLOSE for unknown association, optionnaly send NOTIFY as defined in section XXX and stay at UNASSOCIATED =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED <**PJ**> =A0 =A0 =A0 =A0 =A0ESTABLISHED: Go to CLOSED instead of UNASSOCIATED <**PJ**> =A0 =A0 +------------+ =A0 =A0 |ESTABLISHED | HIP SA established =A0 =A0 +------------+ =A0 =A0 Receive I1, send R1 and stay at ESTABLISHED =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 Receive I2, process with cookie and possible Opaque data verificati= on =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2, drop old SAs, establish new= SA, go to =A0=A0=A0=A0=A0=A0=A0=A0R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at ESTABLISHED =A0 =A0 Receive R1, drop and stay at ESTABLISHED =A0 =A0 Receive R2, drop and stay at ESTABLISHED =A0 =A0 Receive ESP for SA, process and stay at ESTABLISHED =A0 =A0 Receive UPDATE, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send UPDATE in reply and go to REKEY= ING =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 Need rekey, send UPDATE and go to REKEYING =A0 =A0 No packet sent/received during UAL minutes, send CLOSE and =A0 =A0 =A0=A0=A0=A0go to CLOSING. =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK and go to CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED <**PJ**> =A0 =A0 =A0 =A0 =A0Closing: Move to CLOSED after sending CLOSE_ACK instead = of =A0 =A0 =A0 =A0 =A0UNASSOCIATED <**PJ**> =A0 =A0 +---------+ =A0 =A0 | CLOSING | HIP association has not been used for UAL (Unused =A0 =A0 +---------+ Association Lifetime) minutes. =A0 =A0 Datagram to send, requires creation of another HIP association =A0=A0=A0=A0=A0=A0=A0=A0in UNASSOCIATED state (which will send I1 and go to= I1-SENT) =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, discard state and go to = CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive ANYOTHER, drop and stay at CLOSING =A0 =A0 Timeout, increment timeout sum, reset timer =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is less than UAL+MSL minutes, retran= smit CLOSE =A0=A0=A0=A0=A0=A0=A0=A0 =A0and stay at CLOSING =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is greater than UAL+MSL minutes, go = to =A0 =A0 =A0 =A0 =A0 =A0UNASSOCIATED <**PJ**> =A0 =A0 =A0 =A0 =A0CLOSED is a new state. Timeout sum should be 2*MSL or so= mething =A0 =A0 =A0 =A0 =A0else?? <**PJ**> <**JL**> The 'active closer' might retransmit a CLOSE during UAL + MSL, so I think a host entering CLOSED should wait for UAL + 2MSL before going to=20 UNASSOCIATED. Also, there's no need for 'timeout sun' or 'counter', nor to reset timer here. =A0 =A0 +--------+ =A0 =A0 | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary =A0 =A0 +--------+ =A0 =A0 Datagram to send, requires creation of another HIP association =A0=A0=A0=A0=A0=A0=A0=A0in UNASSOCIATED state (which will send I1 and go to= I1-SENT) =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, stay at CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive ANYOTHER, drop and stay at CLOSED Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED 5.4.3 =A0Simplified HIP State Diagram =A0 =A0 =A0 =A0 +-+ =A0 =A0 =A0 =A0 | | CLOSE received, send NOTIFY =A0 =A0 =A0 =A0 V ^ =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED|<----------------------+ =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| Timeout, move to =A0 =A0 =A0 =A0 =A0 | CLOSE_ACK received, or =A0 =A0 =A0 | UNASSOCIATED =A0 =A0 =A0 =A0 =A0 | timeout sum > UAL+MSL =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-= =2D------+ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0rec CLOSE, =A0 =A0 +--->| CLOSED |----+ =A0 =A0 =A0+---------+ send CLOSE_ACK | =A0 =A0+--------+ =A0 =A0| CLOSE re= ceived, =A0 =A0 =A0| CLOSING |----------------+ =A0 =A0 =A0 =A0| =A0 ^ =A0 =A0 | se= nd CLOSE_ACK =A0 =A0 =A0| =A0 =A0 =A0 =A0 |-----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 | =A0 =A0 | =A0 =A0 =A0+---------+ =A0 =A0 | timeout sum =A0 =A0 =A0 | =A0 +-----+ =A0 =A0 =A0 =A0 =A0 ^ =A0 ^ =A0 =A0 =A0| < UAL+MSL, =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 +------+ retransmit CLOSE =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 | No packet sent/received =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | for UAL min, send CLOSE =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| CLOSE received, =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | send C= LOSE_ACK =A0 =A0 |ESTABLISHED |>----------------------+ =A0 =A0 +------------+ =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0Removed optional things, NOTIFY is sent in UNASSOCIATED = state <**PJ**> 7.11 =A0CLOSE_ACK - the HIP closing acknowledgment packet =A0 =A0 The HIP header values for the CLOSE_ACK packet: =A0 =A0 Header: =A0=A0=A0=A0=A0=A0=A0=A0Packet Type =3D XXX Tbd. =A0=A0=A0=A0=A0=A0=A0=A0SRC HIT =3D Sender's HIT =A0=A0=A0=A0=A0=A0=A0=A0DST HIT =3D Recipient's HIT =A0 =A0 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) =A0 =A0 Valid control bits: none =A0 =A0 The sender MUST include both an HMAC and signature (calculated over =A0 =A0 the whole HIP envelope). =A0 =A0 The receiver peer MUST validate both the HMAC and the signature. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0We don't discard the state before we move to UNASSOCIATE= D. =A0 =A0 =A0 =A0 =A0- If we want to send data? We cannot use the old associa= tion =A0 =A0 =A0 =A0 =A0any longer, we need to start a new negotiation. That par= t of =A0 =A0 =A0 =A0 =A0the text needs maybe some clarification. <**PJ**> <**JL**> If a node needs to send data while in CLOSING or CLOSED state, a new exchange must be initiated by sending an I1. The problem is that both=20 nodes needs a means to distinguish packets from two incarnations of a same HIP association between two HIs. If a node receives an I1 while in CLOSING or CLOSED, or even if ESTABLISHED (if a CLOSE was lost), it would=20 create another HIP state and handle all inbound packets but CLOSE and=20 CLOSE_ACK with this new state. I found this approach ambiguous and a=20 bit naive (what happens if the new association is then closed ??).=20 That's one of the reason I've been advocating in the past for having either NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another possibility=20 might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and CLOSE_ACK=20 and use it to demultiplex the packets to the correct state. What does other people think? <**JL**> 8.16 Processing CLOSE packets =A0 =A0 When the host receives a CLOSE message it responds with a CLOSE_ACK =A0 =A0 message and moves to CLOSED state. =A0(The authenticity of the CLOSE =A0 =A0 message is verified using both HMAC and SIGNATURE). This processing =A0 =A0 applies whether or not the HIP association state is CLOSING in order =A0 =A0 to handle CLOSE messages from both ends crossing in flight. =A0 =A0 The HIP association is not discarded before the host moves from the =A0 =A0 UNASSOCIATED state. =A0 =A0 Once the closing process has started, any need to send data packets =A0 =A0 will trigger creating and establishing of a new HIP association, =A0 =A0 starting with sending an I1. =A0 =A0 A CLOSE message which is received when there is no HIP association =A0 =A0 state can not be verified but will result in a NOTIFY response. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0Optional things removed. ACK also accepted in CLOSED sta= te if we =A0 =A0 =A0 =A0 =A0have earlier sent CLOSE related to the same association: =A0 =A0 =A0 =A0 =A0ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, se= nd =A0 =A0 =A0 =A0 =A0CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent= CLOSE =A0 =A0 =A0 =A0 =A0->... <**PJ**> 8.17 Processing CLOSE_ACK packets =A0 =A0 When a host receives a CLOSE_ACK message it verifies that it is in =A0 =A0 CLOSING or CLOSED state and that the CLOSE_ACK was in response to t= he =A0 =A0 CLOSE (using the included ECHO_REPLY in response to the sent =A0 =A0 ECHO_REQUEST). =A0 =A0 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state =A0 =A0 is discarded when the state changes to UNASSOCIATED and, after that, =A0 =A0 NOTIFY is sent as a response to a CLOSE message. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0New NOTIFY <**PJ**> 6.2.19 NOTIFY =A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A044 =A0 =A0 =A0 =A0 =A0 The received CLOSE message referred to an =A0 =A0 =A0 =A0 =A0 association that does not exist. =2D------------------------------------------------------------------ <**JL**> Below is suggested text to replace this paragraph of the Security Considera= tions: A fourth form of DoS attack is emulating the end of state. HIP has no end of state packet. It relies on a local policy timer to end state. A fourth form of DoS attack is emulating the end of state. HIP relies on= timers plus a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be= cause both CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a= connection. The presence of an additional SIGNATURE allows middle-boxes to inspect t= hese messages and discard the associated state (for e.g., firewalling, SPI-based NATin= g, etc.). However, the optionnal behavior of replying to CLOSE with a NOTIFY while= in UNASSOCIATED state might allow a spoofer sending CLOSE messages to launch reflexion attacks= =2E=20 =2D------------------------------------------------------------------------= =2D---= --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 13:54:23 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27417 for ; Mon, 11 Oct 2004 13:54:23 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 690AD72E8; Mon, 11 Oct 2004 12:45:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by honor.icsalabs.com (Postfix) with ESMTP id 54FE472E2 for ; Mon, 11 Oct 2004 12:44:32 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BHrAh28284; Mon, 11 Oct 2004 20:53:10 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 20:52:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9BHq0T4010279; Mon, 11 Oct 2004 20:52:00 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00ZGWrul; Mon, 11 Oct 2004 20:51:59 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BHpwa06269; Mon, 11 Oct 2004 20:51:58 +0300 (EET DST) Received: from [172.19.11.235] ([172.19.11.235]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 20:51:57 +0300 Message-ID: <416AC836.8010802@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Pekka Nikander Cc: Julien Laganier , ext Tim Shepard , hipsec@honor.trusecure.com Subject: Re: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) References: <4169F148.8010502@acm.org> <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> In-Reply-To: <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFBA5A59C0068240556F1285D" X-OriginalArrivalTime: 11 Oct 2004 17:51:58.0055 (UTC) FILETIME=[00CF5770:01C4AFBB] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 12:51:50 -0500 Date: Mon, 11 Oct 2004 12:51:50 -0500 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFBA5A59C0068240556F1285D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pekka, I am okay with not using NONCE. Also, as I have said before, it's important to get some implementation experience with the present draft. I'll get to other e-mails later on (in a couple of days). Yogesh ext Pekka Nikander wrote: >> If I understand right, I guess the traffic selector is the main >> objection that people have for not using nonce. But as Julien >> pointed out, one can use "populate from packets" (PFP) to setup >> the filters. > > > As far as I have understood the thinking of the community (the > chairs may correct), the current belief is that if someone wants > to have traffic selectors and multiple parallel SAs for policy > reason, the right thing to do is to write an extension, present > it at the RG side, and sense the feeling of the community at the > re-chartering time. Hence, IMHO, that discussion should be moved > to the RG mailing list. > >> Also, I am not sure how multiple HIs help. If you have a BITW >> implementation of IPsec, you still need some mechanism to tell >> the IPsec filter to select packets based on IP address/port-numbers >> (the HITs are not present in the packets) > > > At least my understanding has been that iff you are dealing > with legacy hosts and therefore BITW IPsec, you just configure > your host to use either LSIs (1.0.0.0/8) or HITs (4000::0/2) > on the local link. Contrary what the docs says, in that special > case you do have LSIs or HITs in IP headers on the wire. > Hence, you will have HITs (or at least LSIs) even in a BITW > implementation. Other than that, properply implementing HIP > support on a BITW box is pretty impossible. > > --Pekka > > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec --------------enigFBA5A59C0068240556F1285D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWrIOXkjMhOId4nzAQLf1Qf/WhpNFLb0ZX64yPRGWi8UFQta12J263jV XTF+ms9J+orqpiLQiNHr8ctBM4w1RjE1BcetWqvPrYggcAo53pEP74OszM9Kes6N VozcT5b2IvFbruZ1goB+D8TagNxMHIr+T3XDfL6Z6G6ANmv+KzQGChTPdXDRsFw+ 4X6QWxEXPsBxcfMidrM9rAb8smfiCZ8wuXF40PTQDJ9OuEBPFAKWIqs0uZfi8pDl nDfoMA6XmncOjPm0yhDgIZDxK+yedzuGktcJbvF/VOv7LqhxWjh68huUcsZ5bBAt O7FsnKrtKGgbaU9CVDUuU+65D4cWitUIxLFn0GMwFiagdBDn7bErcA== =dkiL -----END PGP SIGNATURE----- --------------enigFBA5A59C0068240556F1285D-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 11 14:28:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00633 for ; Mon, 11 Oct 2004 14:28:24 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1C52372E8; Mon, 11 Oct 2004 13:19:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 69C9B72E2 for ; Mon, 11 Oct 2004 13:18:17 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 0132F220006; Mon, 11 Oct 2004 21:27:06 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 75E428; Mon, 11 Oct 2004 21:27:06 +0300 (EEST) In-Reply-To: <200410111858.59103.julien.laganier@sun.com> References: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4166764D.1060401@nomadiclab.com> <200410111858.59103.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Thomas R Henderson , HIPsec From: Pekka Nikander Subject: Re: [Hipsec] Recovery from state loss To: Petri Jokela , Julien Laganier X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 11 Oct 2004 21:27:03 +0300 Date: Mon, 11 Oct 2004 21:27:03 +0300 Content-Transfer-Encoding: quoted-printable Some details: > 5.4.2 =A0HIP State Processes > > <**PJ**> > =A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming = CLOSE, not > =A0 =A0 =A0 =A0 =A0written down here > <**PJ**> > > <**JL**> > Why not? > <**JL**> Actually, it should be ICMP parameter problem with pointer pointing to something useful, e.g., sender's HIT. That would be an indication that such an association does not exist. The same could be used also for received UPDATE, R2, and perhaps PAYLOAD, when the HIP association has been dropped. I would suggest a new section 6.3.5. 6.3.5. Non-existing HIP association If a HIP implementation receives a CLOSE, UPDATE, or PAYLOAD packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate limited, with an ICMP packet with the type Parameter Problem, the Pointer pointing to the the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, BOS, CER, and NOTIFY. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP replies. 8.11. 0. If there is no corresponding HIP association, the implementation MAY reply with an ICMP Parameter Problem, as specified in 6.3.5. > =A0 =A0 +------------+ > =A0 =A0 |UNASSOCIATED| =A0Start state > =A0 =A0 +------------+ > > =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT > =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED > =A0 =A0 Receive I2, process > =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT > =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED > > =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined > =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED > =A0 =A0 Receive CLOSE for unknown association, optionnaly send NOTIFY > as defined in section XXX and stay at UNASSOCIATED > =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED Before "receive anyother": Receive CLOSE, UPDATE, or PAYLOAD, optionally send ICMP Parameter Problem and stay in UNASSOCIATED. In CLOSING and CLOSED, if you receive I1 or I2, you should handle them=20= just as if you were in UNASSOCIATED. In I1 case, stay in the state where you are but reply with an R1. In I2 case, try to process, and if=20 successful, move to R2-SENT, otherwise stay where where you are. Some more text in Sec 8 probably needs to be revised. Please check. > <**JL**> > If a node needs to send data while in CLOSING or CLOSED state, a new > exchange must be initiated by sending an I1. The problem is that both > nodes needs a means to distinguish packets from two incarnations of a > same HIP association between two HIs. If a node receives an I1 while = in > CLOSING or CLOSED, or even if ESTABLISHED (if a CLOSE was lost), it=20 > would > create another HIP state and handle all inbound packets but CLOSE and > CLOSE_ACK with this new state. I found this approach ambiguous and a > bit naive (what happens if the new association is then closed ??). > That's one of the reason I've been advocating in the past for having=20= > either > NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another=20 > possibility > might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and=20 > CLOSE_ACK > and use it to demultiplex the packets to the correct state. > > What does other people think? > <**JL**> Reuse SEQ from UPDATE for CLOSE? > <**PJ**> > =A0 =A0 =A0 =A0 =A0New NOTIFY > <**PJ**> > > 6.2.19 NOTIFY > > > =A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A044 > > =A0 =A0 =A0 =A0 =A0 The received CLOSE message referred to an > =A0 =A0 =A0 =A0 =A0 association that does not exist. Not needed as we should use ICMP. Sorry for forgetting about my own guidelines. The last line of the suggested Sec Cons text must refer to ICMP, not NOTIFY. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 03:51:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25712 for ; Tue, 12 Oct 2004 03:51:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6169D72E2; Tue, 12 Oct 2004 02:42:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id D0C0472E0 for ; Tue, 12 Oct 2004 02:41:57 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 9C8B0220004; Tue, 12 Oct 2004 10:50:41 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6C2BA8; Tue, 12 Oct 2004 10:50:42 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Robert Moskowitz From: Pekka Nikander To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619) Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 10:50:40 +0300 Date: Tue, 12 Oct 2004 10:50:40 +0300 Content-Transfer-Encoding: 7bit Here is my attempt for some new text to the arch draft: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2, together with Host Identifiers to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, the authors feel that the way IKE used UDP is architecturally wrong. A protocol controlling another protocol (like ICMP controlling IP) should be located either at the same layer with or the layer immediately above the controlled protocol, unless there are important reasons for doing otherwise. For example, in the case of IKE, the current design requires that certain UDP ports are excepted from the normal policy processing. Second, IKE and IKEv2 are, by design, very secure protocols. As an unfortunate side effect, that makes them unfriendly towards middle boxes. As adding a new naming layer allows one to potentially add a new forwarding layer, it is very important that the HIP protocols are friendly towards any middle boxes. Third, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. Future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. Comments? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 04:00:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26172 for ; Tue, 12 Oct 2004 04:00:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 68B5D72E2; Tue, 12 Oct 2004 02:51:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 8DA6072E0 for ; Tue, 12 Oct 2004 02:50:43 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 51626220004 for ; Tue, 12 Oct 2004 10:59:36 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 252FC8 for ; Tue, 12 Oct 2004 10:59:37 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@honor.trusecure.com From: Pekka Nikander X-Mailer: Apple Mail (2.619) Subject: [Hipsec] SA granularity Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 10:59:34 +0300 Date: Tue, 12 Oct 2004 10:59:34 +0300 Content-Transfer-Encoding: 7bit I wrote: > Supporting multiple parallel SAs between any pair of HIs > has been a non-goal for HIP from the beginning. The mobility > and multi-homing extension adds such a feature, but _only_ > for dealing with replay window problems. > > If this non-goal is not clear from the base spec / arch spec, > we need to add explicit text. And I guess the case is so, > since we've faced this same issue before. > > Anyone willing to draft text to be included in both/either of > the drafts, noting that _architecturally_ HIP only considers > host-to-host granularity, and any finer granularity is FFS? Here is the proposed text to clarify this issue: ... In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. Comments? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 05:23:27 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02611 for ; Tue, 12 Oct 2004 05:23:27 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 308D272E2; Tue, 12 Oct 2004 04:14:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 0755972E0 for ; Tue, 12 Oct 2004 04:13:27 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A612489877; Tue, 12 Oct 2004 12:22:20 +0300 (EEST) Message-ID: <416BA1F7.50608@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: hipsec@honor.trusecure.com, Robert Moskowitz Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> In-Reply-To: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 12:20:55 +0300 Date: Tue, 12 Oct 2004 12:20:55 +0300 Content-Transfer-Encoding: 7bit Hi Pekka, and thanks for your text. It looks good. A couple of nits and comments below, however: > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for > this, and there are also a few architectural reasons. First, the > authors feel that the way IKE used UDP is architecturally wrong. > A protocol controlling another protocol (like ICMP controlling > IP) should be located either at the same layer with or the layer > immediately above the controlled protocol, unless there are > important reasons for doing otherwise. For example, in the case > of IKE, the current design requires that certain UDP ports are > excepted from the normal policy processing. Well, presumably the HIP protocol number would also be excepted? Suggestion: delete the example. > Second, IKE and IKEv2 are, by design, very secure protocols. I have a feeling that the parts of the design that affect middle boxes are more of an accident that design on purpose. I wasn't present when the protocols were being designed, but look at IPsec NAT traversal, for instance. Due to the placement of the SPIs deep inside the packet in an encrypted part and unidirectional SAs, NAT passage was not possible. In latest standards this has been fixed by UDP tunneling which on the other hand is quite open to modifications by middle boxes or even other parties. Suggestion: just say that the IKE-IPsec protocol set has not been designed with middle boxes in mind. > As an unfortunate side effect, that makes them unfriendly > towards middle boxes. As adding a new naming layer allows one > to potentially add a new forwarding layer, it is very important > that the HIP protocols are friendly towards any middle boxes. > > Third, from a conceptual point of view, the IPsec Security > Parameter Index (SPI) in ESP provides a simple compression of > the HITs. This does require per-HIT-pair SAs (and SPIs), and a > decrease of policy granularity over other Key Management > Protocols, such as IKE and IKEv2. Future HIP extensions may > provide for more granularity and creation of several ESP SAs > between a pair of HITs. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 05:32:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03136 for ; Tue, 12 Oct 2004 05:32:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7048972E2; Tue, 12 Oct 2004 04:23:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id B0F2672E0 for ; Tue, 12 Oct 2004 04:22:04 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 97CBA220004; Tue, 12 Oct 2004 12:30:57 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 6128C8; Tue, 12 Oct 2004 12:30:58 +0300 (EEST) In-Reply-To: <416BA1F7.50608@piuha.net> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Robert Moskowitz , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 12:30:56 +0300 Date: Tue, 12 Oct 2004 12:30:56 +0300 Content-Transfer-Encoding: 7bit Tnx, Jari. Here is the revised text: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2, together with Host Identifiers to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, the authors feel that the way IKE uses UDP is architecturally wrong. A protocol controlling another protocol (like ICMP controlling IP) should be located either at the same layer with or the layer immediately above the controlled protocol, unless there are important reasons for doing otherwise. Second, IKE and IKEv2 were not design with middle boxes in mind. As adding a new naming layer allows one to potentially add a new forwarding layer (see Section , below), it is very important that the HIP protocols are friendly towards any middle boxes. Third, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 07:20:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09089 for ; Tue, 12 Oct 2004 07:20:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D5A7972E2; Tue, 12 Oct 2004 06:11:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id D964372E0 for ; Tue, 12 Oct 2004 06:10:24 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9CBJJui026972 for ; Tue, 12 Oct 2004 05:19:19 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5G00JWCY47WW@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:19:19 -0600 (MDT) Received: from [140.77.26.100] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5G003JRY3OQG@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:19:05 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Recovery from state loss In-reply-to: <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> To: hipsec@honor.trusecure.com Cc: Pekka Nikander , Petri Jokela , Erik Nordmark , Thomas R Henderson Message-id: <200410121320.35384.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)" User-Agent: KMail/1.7 References: <200410111858.59103.julien.laganier@sun.com> <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 13:20:35 +0200 Date: Tue, 12 Oct 2004 13:20:35 +0200 --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw) Content-type: text/plain; charset=iso-8859-1 Content-disposition: inline Content-Transfer-Encoding: 7BIT On Monday 11 October 2004 20:27, Pekka Nikander wrote: > Some details Taking Pekka's comments in account, and adding a rule for transition to I2_SENT while receiving R1 in CLOSING or CLOSED, the new modified text should include what follows (I didn't modified the state diagram to reflect transition to I2-SENT and R2-SENT from CLOSING/CLOSED). Thanks, --julien ----------------------------------------------------------------------- --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw) Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK3 Content-disposition: attachment; filename=CLOSEACK3 Content-Transfer-Encoding: quoted-printable Taking Pekka's comments in account, and adding a rule for transition=20 to I2_SENT while receiving R1 in CLOSING or CLOSED, the new modified text should include the following (I didn't modified the state diagram to reflect transition to I2-SENT and R2-SENT from CLOSING/CLOSED) : =2D---------------------------------------------------------------- 5.4.2 =A0HIP State Processes =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED| =A0Start state =A0 =A0 +------------+ =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED Receive CLOSE, UPDATE, or PAYLOAD, optionally send ICMP Parameter Problem and stay in UNASSOCIATED. =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED =A0 =A0 +------------+ =A0 =A0 |ESTABLISHED | HIP SA established =A0 =A0 +------------+ =A0 =A0 Receive I1, send R1 and stay at ESTABLISHED =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 Receive I2, process with cookie and possible Opaque data verificati= on =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2, drop old SAs, establish new= SA, go to =A0=A0=A0=A0=A0=A0=A0=A0R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at ESTABLISHED =A0 =A0 Receive R1, drop and stay at ESTABLISHED =A0 =A0 Receive R2, drop and stay at ESTABLISHED =A0 =A0 Receive ESP for SA, process and stay at ESTABLISHED =A0 =A0 Receive UPDATE, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send UPDATE in reply and go to REKEY= ING =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 Need rekey, send UPDATE and go to REKEYING =A0 =A0 No packet sent/received during UAL minutes, send CLOSE and =A0 =A0 =A0=A0=A0=A0go to CLOSING. =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK and go to CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 +---------+ =A0 =A0 | CLOSING | HIP association has not been used for UAL (Unused =A0 =A0 +---------+ Association Lifetime) minutes. =A0 =A0 Datagram to send, requires the creation of another incarnation of the HIP association, started by sending an I1, and stay at CLOSING =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSING Receive R1, process if successful, send I2 and go to I2-SENT if fail, stay at CLOSING =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, discard state and go to = CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive ANYOTHER, drop and stay at CLOSING =A0 =A0 Timeout, increment timeout sum, reset timer =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is less than UAL+MSL minutes, retran= smit CLOSE =A0=A0=A0=A0=A0=A0=A0=A0 =A0and stay at CLOSING =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is greater than UAL+MSL minutes, go = to =A0 =A0 =A0 =A0 =A0 =A0UNASSOCIATED =A0 =A0 +--------+ =A0 =A0 | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary =A0 =A0 +--------+ =A0 =A0 Datagram to send, requires the creation of another incarnation of the HIP association, started by sending an I1, and stay at CLOSED =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSED Receive R1, process if successful, send I2 and go to I2-SENT if fail, stay at CLOSED =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, stay at CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive ANYOTHER, drop and stay at CLOSED Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED =2D---------------------------------------------------------------- 5.4.3 =A0Simplified HIP State Diagram =A0 =A0 =A0 =A0 +-+ =A0 =A0 =A0 =A0 | | CLOSE received, send NOTIFY =A0 =A0 =A0 =A0 V ^ =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED|<----------------------+ =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| Timeout, move to =A0 =A0 =A0 =A0 =A0 | CLOSE_ACK received, or =A0 =A0 =A0 | UNASSOCIATED =A0 =A0 =A0 =A0 =A0 | timeout sum > UAL+MSL =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-= =2D------+ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0rec CLOSE, =A0 =A0 +--->| CLOSED |----+ =A0 =A0 =A0+---------+ send CLOSE_ACK | =A0 =A0+--------+ =A0 =A0| CLOSE re= ceived, =A0 =A0 =A0| CLOSING |----------------+ =A0 =A0 =A0 =A0| =A0 ^ =A0 =A0 | se= nd CLOSE_ACK =A0 =A0 =A0| =A0 =A0 =A0 =A0 |-----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 | =A0 =A0 | =A0 =A0 =A0+---------+ =A0 =A0 | timeout sum =A0 =A0 =A0 | =A0 +-----+ =A0 =A0 =A0 =A0 =A0 ^ =A0 ^ =A0 =A0 =A0| < UAL+MSL, =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 +------+ retransmit CLOSE =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 | No packet sent/received =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | for UAL min, send CLOSE =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| CLOSE received, =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | send C= LOSE_ACK =A0 =A0 |ESTABLISHED |>----------------------+ =A0 =A0 +------------+ =2D---------------------------------------------------------------- 6.3.5. Non-existing HIP association If a HIP implementation receives a CLOSE, UPDATE, or PAYLOAD packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate limited, with an ICMP packet with the type Parameter Problem, the Pointer pointing to the the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, BOS, CER, and NOTIFY. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP replies. =2D---------------------------------------------------------------- 8.11 Processing UPDATE packets 0. If there is no corresponding HIP association, the implementation MAY reply with an ICMP Parameter Problem, as specified in 6.3.5. =2D---------------------------------------------------------------- 7.11 =A0CLOSE_ACK - the HIP closing acknowledgment packet =A0 =A0 The HIP header values for the CLOSE_ACK packet: =A0 =A0 Header: =A0=A0=A0=A0=A0=A0=A0=A0Packet Type =3D XXX Tbd. =A0=A0=A0=A0=A0=A0=A0=A0SRC HIT =3D Sender's HIT =A0=A0=A0=A0=A0=A0=A0=A0DST HIT =3D Recipient's HIT =A0 =A0 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) =A0 =A0 Valid control bits: none =A0 =A0 The sender MUST include both an HMAC and signature (calculated over =A0 =A0 the whole HIP envelope). =A0 =A0 The receiver peer MUST validate both the HMAC and the signature. =2D---------------------------------------------------------------- 8.16 Processing CLOSE packets =A0 =A0 When the host receives a CLOSE message it responds with a CLOSE_ACK =A0 =A0 message and moves to CLOSED state. =A0(The authenticity of the CLOSE =A0 =A0 message is verified using both HMAC and SIGNATURE). This processing =A0 =A0 applies whether or not the HIP association state is CLOSING in order =A0 =A0 to handle CLOSE messages from both ends crossing in flight. =A0 =A0 The HIP association is not discarded before the host moves from the =A0 =A0 UNASSOCIATED state. =A0 =A0 Once the closing process has started, any need to send data packets =A0 =A0 will trigger creating and establishing of a new HIP association, =A0 =A0 starting with sending an I1. If there is no corresponding HIP association, the implementation MAY reply to a CLOSE with an ICMP Parameter Problem, as i specified in 6.3.5. =2D---------------------------------------------------------------- 8.17 Processing CLOSE_ACK packets =A0 =A0 When a host receives a CLOSE_ACK message it verifies that it is in =A0 =A0 CLOSING or CLOSED state and that the CLOSE_ACK was in response to t= he =A0 =A0 CLOSE (using the included ECHO_REPLY in response to the sent =A0 =A0 ECHO_REQUEST). =A0 =A0 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state =A0 =A0 is discarded when the state changes to UNASSOCIATED and, after that, =A0 =A0 NOTIFY is sent as a response to a CLOSE message. =2D---------------------------------------------------------------- A fourth form of DoS attack is emulating the end of state. HIP has no end of state packet. It relies on a local policy timer to end state. A fourth form of DoS attack is emulating the end of state. HIP relies on= timers plus a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be= cause both CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a= connection. The presence of an additional SIGNATURE allows middle-boxes to inspect t= hese messages and discard the associated state (for e.g., firewalling, SPI-based NATin= g, etc.). However, the optionnal behavior of replying to CLOSE with an ICMP Parame= ter Problem=20 packet (as described in Section 6.3.5), might allow an IP spoofer sendin= g CLOSE messages to launch reflexion attacks.=20 =2D------------------------------------------------------------------------= =2D---= --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 07:26:28 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09322 for ; Tue, 12 Oct 2004 07:26:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 747E472E2; Tue, 12 Oct 2004 06:17:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id C1C9C72E0 for ; Tue, 12 Oct 2004 06:16:57 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 1F0FE220004 for ; Tue, 12 Oct 2004 14:25:51 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id E28A98; Tue, 12 Oct 2004 14:25:51 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78067BDE-1C41-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo From: Pekka Nikander To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619) Subject: [Hipsec] A new pre version of the HIP arch draft available Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 14:25:49 +0300 Date: Tue, 12 Oct 2004 14:25:49 +0300 Content-Transfer-Encoding: 7bit Folks, We agreed with the ADs that the HIP architecture draft will become a WG item, with the intention of going through a WG LC and then proceeding quickly to the IESG. A preliminary version of the draft is now available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-pre-Oct12.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-pre-Oct12.html I plan to submit it within a few days to the repositories, and expect the chairs to announce a WG LC soon after that. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 07:50:28 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10522 for ; Tue, 12 Oct 2004 07:50:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C326772E2; Tue, 12 Oct 2004 06:41:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id AC51772E0 for ; Tue, 12 Oct 2004 06:40:06 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9CBn1NH015353 for ; Tue, 12 Oct 2004 05:49:01 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5G0072SZHPZI@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:49:01 -0600 (MDT) Received: from [140.77.26.100] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5G003MJZH8QG@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:48:46 -0600 (MDT) From: Julien Laganier To: hipsec@honor.trusecure.com Cc: Pekka Nikander Message-id: <200410121350.22666.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 Subject: [Hipsec] Pre-version of 'HIP DNS Extensions' I-D Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 13:50:22 +0200 Date: Tue, 12 Oct 2004 13:50:22 +0200 Content-Transfer-Encoding: 7BIT Folks, We plan to submit this draft as a WG item (draft-ietf-hip-rvs-00) within a few days (deadline is on Monday, 9:00 ET). In the meantime, it is available here: Thanks, -- Julien Laganier SUN Microsystems Laboratories _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 07:53:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10725 for ; Tue, 12 Oct 2004 07:53:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 42D7A72E2; Tue, 12 Oct 2004 06:44:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 947B372E0 for ; Tue, 12 Oct 2004 06:43:41 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9CBqaui009711 for ; Tue, 12 Oct 2004 05:52:36 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5G009NCZNO1V@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:52:37 -0600 (MDT) Received: from [140.77.26.100] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5G003MQZN8QG@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 05:52:21 -0600 (MDT) From: Julien Laganier To: hipsec@honor.trusecure.com Cc: Lars.Eggert@netlab.nec.de Message-id: <200410121353.57902.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 Subject: [Hipsec] Pre-version of 'HIP Rendezvous Extensions' I-D Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 13:53:57 +0200 Date: Tue, 12 Oct 2004 13:53:57 +0200 Content-Transfer-Encoding: 7BIT Folks, We plan to submit this draft as a WG item (draft-ietf-hip-rvs-00) within a few days (deadline is on Monday, 9:00 ET). In the meantime, it is available here: Thanks, -- Julien Laganier SUN Microsystems Laboratories _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 12:58:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08859 for ; Tue, 12 Oct 2004 12:58:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9AFF972F3; Tue, 12 Oct 2004 11:49:06 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id DA58A72E6 for ; Tue, 12 Oct 2004 11:48:25 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9CGvINH008113 for ; Tue, 12 Oct 2004 10:57:18 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5H0073YDRHZI@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 10:57:18 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5H00CHWDREE1@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 12 Oct 2004 10:57:17 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Digital Signature Algorithms In-reply-to: <416543F8.6040006@piuha.net> To: hipsec@honor.trusecure.com, jari.arkko@piuha.net Message-id: <200410121858.38644.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <200410071521.16054.julien.laganier@sun.com> <416543F8.6040006@piuha.net> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 18:58:38 +0200 Date: Tue, 12 Oct 2004 18:58:38 +0200 Content-Transfer-Encoding: 7BIT On Thursday 07 October 2004 15:26, Jari Arkko wrote: > There used to be IPR concerns with RSA, but I believe > the patents expired. ECC is a mine field of IPR, so > I'd rather stay out of it if possible. > > I'd go for RSA, personally. > > --Jari So how does people feel about making both DSA and RSA mandatory in HIP? Thanks, --julien > Julien Laganier wrote: > > Hi Folks, > > > > Looking at the paper "Experience with the Host Identity Protocol > > for Secure Mobility and Multihoming" by Henderson et al., I found > > that DSA signing and verification account for a huge part of the > > association set-up latency. > > > > Hence, I am wondering what is the rationale for HIP to specify > > DSA as a MANDATORY algorithm, although RSA signatures > > verification might be ten times faster than DSA? > > > > Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) > > which has reduced P.K. and signatures size, and can be as fast or > > faster than RSA? > > > > Thanks, > > > > --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 12 13:16:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10134 for ; Tue, 12 Oct 2004 13:16:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 97591735D; Tue, 12 Oct 2004 12:07:05 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by honor.icsalabs.com (Postfix) with ESMTP id 131FD7304 for ; Tue, 12 Oct 2004 12:06:34 -0400 (EDT) Received: from [192.168.1.105] (adsl-69-108-117-230.dsl.irvnca.pacbell.net [69.108.117.230]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9CHElJ26730; Tue, 12 Oct 2004 10:14:47 -0700 (PDT) Message-ID: <416C1106.6050609@isi.edu> From: Yu-Shun Wang User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> In-Reply-To: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050302090005000406040106" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: yushunwa@isi.edu Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 10:14:46 -0700 Date: Tue, 12 Oct 2004 10:14:46 -0700 This is a cryptographically signed message in MIME format. --------------ms050302090005000406040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Pekka & all, Jumping into this really, really late. Aplogized in advance if I missed some previous context. I am not a big fan of IKE (v1/v2), but just feel something is still missing in the reasoning below. Pekka Nikander wrote: > Here is the revised text: > > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for this, > and there are also a few architectural reasons. First, the > authors feel that the way IKE uses UDP is architecturally wrong. > A protocol controlling another protocol (like ICMP controlling > IP) should be located either at the same layer with or the layer > immediately above the controlled protocol, unless there are > important reasons for doing otherwise. I am not sure about this argument. In a way, the HIP exchange is analogous to DNS, you contact somebody to resolve an identity in one domain into an identity in another domain. It just happens in this case the 'somebody' is also the destination you want to communicate with. This exchange should be considered a separate communication, and is free to use whatever protocol or even out- of-band information if available. It is just a process of resolving identities, I am a bit unsure about the phrase "A protocol controlling another protocol..." Maybe I miss something here? > Second, IKE and IKEv2 were not design with middle boxes in > mind. As adding a new naming layer allows one to potentially add > a new forwarding layer (see Section , below), > it is very important that the HIP protocols are friendly towards > any middle boxes. Not a very strong one, but I agree. > Third, from a conceptual point of view, the IPsec Security > Parameter Index (SPI) in ESP provides a simple compression of > the HITs. This does require per-HIT-pair SAs (and SPIs), and a > decrease of policy granularity over other Key Management > Protocols, such as IKE and IKEv2. In particular, the current > thinking is limited to a situation where, conceptually, there is > only one pair of SAs between any given pair of HITs. In other > words, from an architectural point of view, HIP only supports > host-to-host (or endpoint-to-endpoint) Security Associations. > If two hosts need more pairs of parallel SAs, they should use > separate HITs for that. However, future HIP extensions may > provide for more granularity and creation of several ESP SAs > between a pair of HITs. This sounds like what we want is a subset of what IKEv1/v2 have. This is an efficiency and optimization issue. I guess what I'd like to see is a more compelling reasoning why we have to use a different protocol. Otherwise another side of the argument would be why not define HIP exchange as a profile of IKE to save the trouble of inventing another protocol? (I'm sure you hear about all that by now. Maybe even an ID in the work?) (Again, I missed the previous discussion. Feel free to give me pointers if all have been said.) Thanks, yushun > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec -- Yu-Shun Wang USC Information Sciences Institute --------------ms050302090005000406040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MTAxMjE3MTQ0NlowIwYJKoZIhvcNAQkEMRYEFG17yjofeVfpU2qES3u5Lt9o 6zAqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBADDLoWv7fc59oLv47xgrVvwfT5OFAmwIuc4a unRvM54bjOG4NjEzVenrKvXWKMs46e+XknBK2r2Cbn/QJJVJx6szcuzD+WuM1yfSXRAsIMgt sofKoBu4M8fxM0jrLRvwhuhted/Am29oO6f+FUvY8Z1PkCHO6Nn29+1qcTZNKVaQczOXU2M+ cxgaswcStWmYIIxsOoDRkw53cp7yaD+NDviQkqlTtT9Dasiqk6MeU6vSq9yyyOissRd3V4MM AOGk61eddlpc7Pt5emT7vTa401e0Ll6knYDktsDOR/6L8FWHrgk2BwJSfxh+vbzMc6qfJb1T Z2/XQrqMcBjW4VUvj4sAAAAAAAA= --------------ms050302090005000406040106-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 00:37:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19600 for ; Wed, 13 Oct 2004 00:37:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 314B47310; Tue, 12 Oct 2004 23:28:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by honor.icsalabs.com (Postfix) with ESMTP id DB83D72F9 for ; Tue, 12 Oct 2004 23:27:53 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D4aoF16487; Wed, 13 Oct 2004 07:36:51 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 07:36:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9D4aEnq006382; Wed, 13 Oct 2004 07:36:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ORTUgn; Wed, 13 Oct 2004 07:36:13 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D4aCa15893; Wed, 13 Oct 2004 07:36:12 +0300 (EET DST) Received: from [10.241.50.253] ([10.241.50.253]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 07:36:08 +0300 Message-ID: <416CB0B0.6010500@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Miika Komu Cc: ext Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1BB8A63B49EB151A6E76C45D" X-OriginalArrivalTime: 13 Oct 2004 04:36:09.0071 (UTC) FILETIME=[290617F0:01C4B0DE] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 23:36:00 -0500 Date: Tue, 12 Oct 2004 23:36:00 -0500 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1BB8A63B49EB151A6E76C45D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > I think I misunderstood the notation here. g^ir (or g^xy) is the shared > Diffie-Hellman secret, not the concatenation of the Diffie-Hellman > parameters. Just forget my alternative above =) > > So, I guess we need to include the shared secret in the calculation of the > HMAC in I2 and R2? Still, I am a bit confused why this should be done. > Yogesh, would you care to explain this point in more depth? I am not a > crypto specialist... > Well, I am not a crypto expert either :-) The signature and HMAC are complementary. Signature prevents from MITM; HMAC ensures that the people who are verified to be alice and bob actually know the session key. I guess SIGMA paper is the best place for in depth analysis of all this. Yogesh --------------enig1BB8A63B49EB151A6E76C45D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWywtXkjMhOId4nzAQJ42QgApwC7ZHZUO15bHmpnTsYEhGNSRBVogBSE mAJmw03Iws9tQ7smvngbRSJTpSTeJoYQOxUFgNyvEoh3MLLtTbtSfcg7EPT+q57Y U0sUXX54DC5q+in/kK9zp2JIp8h+uxoZt3npKBVJgQRDvJy+WYih6u4wtFw4wihZ rPx1PHH2vQnFiUZPYHt9SRqzD7jv3EALbskTrUHmU4KkFqq1jjRNbOroMm25GVDM 8viui6oFi3iJUbXYJ5w5Dz+GANNsFMEb+mWusbHAEJuq12+jF05ru+OPUDKmzOCS w1dgZrFWSm0T8t8vj27b9Nr9UlAUyRdEiUcPLLnZVJKs0Hk/yw8Pww== =4k3T -----END PGP SIGNATURE----- --------------enig1BB8A63B49EB151A6E76C45D-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 00:57:31 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20521 for ; Wed, 13 Oct 2004 00:57:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7B49F7310; Tue, 12 Oct 2004 23:48:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id 098E672F9 for ; Tue, 12 Oct 2004 23:47:24 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id XAA01462; Tue, 12 Oct 2004 23:55:56 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9D4ttD08380; Tue, 12 Oct 2004 21:55:55 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Oct 2004 21:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Thread-Index: AcSwfyr7vbASffjFQXOX0lyD3kCN3QAX/PcA From: "Henderson, Thomas R" To: "Yu-Shun Wang" , "Pekka Nikander" Cc: , "Robert Moskowitz" , X-OriginalArrivalTime: 13 Oct 2004 04:55:55.0296 (UTC) FILETIME=[EC11AA00:01C4B0E0] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 21:55:54 -0700 Date: Tue, 12 Oct 2004 21:55:54 -0700 Content-Transfer-Encoding: quoted-printable > > First, the > > authors feel that the way IKE uses UDP is=20 > architecturally wrong. > > A protocol controlling another protocol (like ICMP controlling > > IP) should be located either at the same layer with=20 > or the layer > > immediately above the controlled protocol, unless there are > > important reasons for doing otherwise. >=20 > I am not sure about this argument.=20 FWIW, I tend to agree. Do the authors feel the same way about BGP using = TCP? If control plane protocols can make use of existing transport protocols, = so much the better. Tom =20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 00:59:30 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20684 for ; Wed, 13 Oct 2004 00:59:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4CD92731F; Tue, 12 Oct 2004 23:50:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 32F9D7310 for ; Tue, 12 Oct 2004 23:49:44 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA12640; Tue, 12 Oct 2004 21:58:40 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9D4wes29486; Tue, 12 Oct 2004 21:58:40 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Oct 2004 21:58:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452271B@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview Thread-Index: AcSviA74BYsL8BovQomSOwxlfcm2vQBWRtXg From: "Henderson, Thomas R" To: "Mika Kousa" , X-OriginalArrivalTime: 13 Oct 2004 04:58:40.0014 (UTC) FILETIME=[4E3FA2E0:01C4B0E1] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 12 Oct 2004 21:58:39 -0700 Date: Tue, 12 Oct 2004 21:58:39 -0700 Content-Transfer-Encoding: quoted-printable Mika, I agree that we can generalize these figures, and=20 will adapt some of them along the lines that you suggested, or else point it out in the corresponding text. Tom > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi] > Sent: Monday, October 11, 2004 4:46 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] review of comments on=20 > draft-ietf-hip-mm-00 preview >=20 >=20 > 5.1 Mobility with single SA pair >=20 > Mobile Host Peer Host >=20 > UPDATE(REA, SEQ) > -----------------------------------> > UPDATE(SPI, SEQ, ACK, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> >=20 > Figure 3: Readdress without rekeying, but with address check >=20 >=20 >=20 > Now that we have seen the change needed for address check procedure=20 > (ECHO_REQUESTs are sent to each of the addresses listed in=20 > the REA, see=20 > this same thread), this section needs some editing. >=20 > Peer Host does not need to send ACK for the REA-UPDATE in=20 > every UPDATE it=20 > sends related to address check procedure, it could send just=20 > ACK-UPDATE=20 > and after that the Peer Host sends the ECHO_REQUEST-UPDATEs: >=20 > For example: >=20 >=20 > Mobile Host Peer Host >=20 > UPDATE(REA(addr_1,addr_2), SEQ) > -----------------------------------> > UPDATE(ACK) > <----------------------------------- >=20 > sent to addr_1: UPDATE(SPI, SEQ, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> >=20 > sent to addr_2: UPDATE(SPI, SEQ, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> > ... >=20 >=20 > Maybe the other figures and related texts in section 5 need similar=20 > changes when there is a possibility that REA contains many=20 > addresses, too. > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 01:15:35 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21954 for ; Wed, 13 Oct 2004 01:15:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0AD7C7317; Wed, 13 Oct 2004 00:06:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by honor.icsalabs.com (Postfix) with ESMTP id 6AD197310 for ; Wed, 13 Oct 2004 00:05:06 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D5E4F24218; Wed, 13 Oct 2004 08:14:04 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 08:12:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9D5CO5D018380; Wed, 13 Oct 2004 08:12:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 006NREeF; Wed, 13 Oct 2004 08:12:23 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D5CIS22779; Wed, 13 Oct 2004 08:12:18 +0300 (EET DST) Received: from [10.241.50.253] ([10.241.50.253]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 08:12:09 +0300 Message-ID: <416CB921.2060700@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Pekka Nikander Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> In-Reply-To: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD470BD3312D66E2E992CA37" X-OriginalArrivalTime: 13 Oct 2004 05:12:09.0668 (UTC) FILETIME=[30D70840:01C4B0E3] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 00:12:01 -0500 Date: Wed, 13 Oct 2004 00:12:01 -0500 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD470BD3312D66E2E992CA37 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ext Pekka Nikander wrote: > Tnx, Jari. > > Here is the revised text: > > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for this, > and there are also a few architectural reasons. First, the > authors feel that the way IKE uses UDP is architecturally wrong. I think you also need to say something about connection-less-ness and connection-oriented-ness. The way HIP is right now, it makes layer 3.5 connection oriented, and honestly, I don't like it. (I remember you said ESP is connection oriented because of sequence number. But I checked rfc2401bis and it says sequence numbers are optional. ESP supports multicast, so it has to be connectionless.) Also, the draft needs to say how HIP architecture affect multicast. If HIP doesn't target multicast, then that should also be stated, IMO. Yogesh --------------enigCD470BD3312D66E2E992CA37 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWy5JXkjMhOId4nzAQIwaQf/VmkkpIE6SFcbT30Rt9CVUnphYWkdgOuR QAliHuoyNzSVd/biZdsLAUrpN4PrcArGd6DmH078BQICPpUK45FG30eRcQQ1y/3y +PBdX8/BFwEJD8G5NrvIRWbkiliWMpAWnsK3tLvR8mEBKwTKMlYvJrJs7wLYMCw2 k8ukN2403llcgcNiZYWxqCTbF72HO2Mu6HPgki6BpfIKmyeC5Y4fVtWNOwzIhB3o V/jaH0vHEZgZoUVAiHaNHkDomgRsmM6BDd1piHaAtmoPIna5HrtqGHuVE9wvRQ+o KZXmkhkSTsbEKv4NAhelqQd5Gfvha09HUCJW6Lkf5Udm4L8IoNdlVg== =MU32 -----END PGP SIGNATURE----- --------------enigCD470BD3312D66E2E992CA37-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 02:03:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28331 for ; Wed, 13 Oct 2004 02:03:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 295967310; Wed, 13 Oct 2004 00:54:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 6C7C872F9 for ; Wed, 13 Oct 2004 00:53:12 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 7B594220004; Wed, 13 Oct 2004 09:02:10 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id F22EE8; Wed, 13 Oct 2004 09:02:10 +0300 (EEST) In-Reply-To: <200410121858.38644.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <416543F8.6040006@piuha.net> <200410121858.38644.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Digital Signature Algorithms To: Julien Laganier X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 09:02:08 +0300 Date: Wed, 13 Oct 2004 09:02:08 +0300 Content-Transfer-Encoding: 7bit > So how does people feel about making both DSA and RSA mandatory in > HIP? I don't have any strong opinions. IIRC, the usual IETF crypto guidelines state that a) there must be at least one common MUST implement algorithm that is considered secure enough b) the algorithms must be negotiable so that if the currently MUST implement turns out to be insecure, the implementations can be easily upgraded to use some other, new MUST implement algorithm Anyone care to check what the guidelines and other documents actually say? draft-ietf-ipsec-ikev2-algorithms-05.txt draft-iab-auth-mech-03.txt crypto forum? From a robustness point of view, it would of course good to have multiple MUST implement algorithms. OTOH, I think that there should also be some guidelines how to use them so that the chances of interoperability are maintained even in the case that one of the hosts only supports one algorithm, e.g., due to policy reasons. Maybe we could have DSA as MUST and RSA as SHOULD? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 04:12:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00275 for ; Wed, 13 Oct 2004 04:12:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B28EC7310; Wed, 13 Oct 2004 03:03:01 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 3E45372F9 for ; Wed, 13 Oct 2004 03:02:51 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 6C906220008; Wed, 13 Oct 2004 11:11:43 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2F8018; Wed, 13 Oct 2004 11:11:41 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81E5C2E2-1CEF-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , "Yu-Shun Wang" , "Robert Moskowitz" , From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 11:11:38 +0300 Date: Wed, 13 Oct 2004 11:11:38 +0300 Content-Transfer-Encoding: 7bit On Oct 13, 2004, at 7:55, Henderson, Thomas R wrote: >>> First, the >>> authors feel that the way IKE uses UDP is architecturally >>> wrong. >>> A protocol controlling another protocol (like ICMP controlling >>> IP) should be located either at the same layer with or the >>> layer >>> immediately above the controlled protocol, unless there are >>> important reasons for doing otherwise. >> >> I am not sure about this argument. > > FWIW, I tend to agree. Do the authors feel the same way about BGP > using TCP? Personally, I do. I haven't got any answer from Bob on this, yet. In the BGP case, there is this "important reason for doing otherwise", which is reusing TCP's reliability mechanism. FWIW, I think it would probably be better to run BGP over the top of SCTP; maybe some people are already thinking along those lines. > If control plane protocols can make use of existing transport > protocols, > so much the better. Actually, that makes a lot of things harder. You have to have special rules in firewalls and middle boxes, etc. As a result, building intelligent routers that separate fast path and slow path becomes slightly more involved. In this respect, the current HIP design is quite elegant, while e.g. IKE is not. But maybe I should tone down the argument and replace "architecturally wrong" with "architecturally inelegant"? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 04:30:35 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01886 for ; Wed, 13 Oct 2004 04:30:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 45FA07317; Wed, 13 Oct 2004 03:21:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 123E972F9 for ; Wed, 13 Oct 2004 03:20:19 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id D6F76220007; Wed, 13 Oct 2004 11:29:17 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 3B6728; Wed, 13 Oct 2004 11:29:18 +0300 (EEST) In-Reply-To: <416C1106.6050609@isi.edu> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: Yu-Shun Wang X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 11:29:16 +0300 Date: Wed, 13 Oct 2004 11:29:16 +0300 Content-Transfer-Encoding: 7bit > I am not a big fan of IKE (v1/v2), but just feel something > is still missing in the reasoning below. Well, as Bob has written before, there is a largish number of historical reasons. First, I don't even know them all. Second, even if I did, I am not sure if we should list them in the draft. As Bob wrote, he was told to remove any argumentation about HIP vs. IKE from the earlier versions of the architecture document. However, lately people have asked about this, and therefore IMHO it would be a good idea to say something. But I don't know what. One of my personal problems is that I've been doing this HIP thing now for a little bit too long. I start to be blind to many things. That is, I take some things for granted, while they are not that for people coming from outside. Hence, community feedback in getting this argument right is very important. I already answered to a part of this argument in a separate mail. Let me consider the rest here: > In a way, the HIP exchange is > analogous to DNS, you contact somebody to resolve an identity in > one domain into an identity in another domain. It just happens > in this case the 'somebody' is also the destination you want to > communicate with. This exchange should be considered a separate > communication, and is free to use whatever protocol or even out- > of-band information if available. Hmm... Interesting thought. Yes, HIP does involve a resolution or translation concept, and even more so in the case of Hi3. It is a nice idea that maybe we could disentangle the HIP protocol from the rest of HIP architecture. In a way, both BEET and CELP are steps into that direction (though in almost completely different levels.) Perhaps we need a kind of API that could be used both to control BEET IPsec based translation and CELP like translation? However, IIRC, we were not in that level last fall. As the intention is to publish the architecture document as reflecting our thoughts as they were a year ago, it may not be possible to include anything about this into the draft. > It is just a process of resolving identities, I am a bit unsure > about the phrase "A protocol controlling another protocol..." > Maybe I miss something here? Well, the HIP protocol is more than just identity translation. It is also about maintaining those translations in the face of mobility and multi-homing. Some people have thought about adding QoS signalling features to HIP. And so on. Besides, if we think about some other "control plane" or "signalling" protocols, such as SIP, their primary function seems to be creating connection (id to address translation, if you will), and then maintenance of the session. >> Third, from a conceptual point of view, the IPsec Security >> Parameter Index (SPI) in ESP provides a simple compression of >> the HITs. This does require per-HIT-pair SAs (and SPIs), and a >> decrease of policy granularity over other Key Management >> Protocols, such as IKE and IKEv2. ... > > This sounds like what we want is a subset of what IKEv1/v2 have. > This is an efficiency and optimization issue. I guess what I'd > like to see is a more compelling reasoning why we have to use > a different protocol. Otherwise another side of the argument > would be why not define HIP exchange as a profile of IKE to save > the trouble of inventing another protocol? (I'm sure you hear > about all that by now. Maybe even an ID in the work?) I think it would be a very useful exercise to try to write an IKEv2 profile that would allow HIP-like SA creation. You probably also need MOBIKE extensions. Indeed, if that would become good enough, it might be even good to trash the current HIP protocol almost completely and move to IKEv2. However, I'm almost sure that some important aspects of the current HIP design would probably be lost. It is then another question to decide whether such loss is important enough to retain a separate protocol or not. However, even if such an exercise would be quite useful, that should not slow down current progress with HIP. It is most important to get some deployment experience. Only that helps us with the next stages of design. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 08:16:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20341 for ; Wed, 13 Oct 2004 08:16:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 36C427310; Wed, 13 Oct 2004 07:06:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 79C9572F9 for ; Wed, 13 Oct 2004 07:05:07 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 067B022000A; Wed, 13 Oct 2004 15:14:07 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 6BF8E8; Wed, 13 Oct 2004 15:14:07 +0300 (EEST) In-Reply-To: <416CB921.2060700@acm.org> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416CB921.2060700@acm.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: Yogesh Prem Swami X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 15:14:04 +0300 Date: Wed, 13 Oct 2004 15:14:04 +0300 Content-Transfer-Encoding: 7bit >> While it would be possible, at least in theory, to use some >> existing cryptographic protocol, such as IKEv2, together with >> Host Identifiers to establish the needed SAs, HIP defines a new >> protocol. There are a number of historical reasons for this, >> and there are also a few architectural reasons. First, the >> authors feel that the way IKE uses UDP is architecturally wrong. > > I think you also need to say something about connection-less-ness and > connection-oriented-ness. The way HIP is right now, it makes layer 3.5 > connection oriented, and honestly, I don't like it. (I remember you > said ESP is connection oriented because of sequence number. But I > checked rfc2401bis and it says sequence numbers are optional. ESP > supports multicast, so it has to be connectionless.) We didn't think in that way back last fall. It is hard to say anything about that in the draft, as that was not thought about. Going to the actual issue, host IP is not stateless. In addition to the ESP state, it has quite a lot of state, e.g. ND cache, routing entries, etc. When people speak about the stateless nature of IP, they typically mean that there is no per-connection state, especially in the network. Some IP implementations do maintain some state per active peer IP address, e.g. MTU, cached best route, etc. See e.g. BSD sources. That is soft state. In HIP case, there is still no per-connection state, there is just host-to-host (or end-point-to-end-point) state, and that is soft. It can be taken down and re-created independent on the upper layer state. The only real exception where I do see a difference is the HIT->IP mapping, which currently needs to be maintained at the HIP layer. But that kind of mapping you do need to maintain on any layer 3.5 solution. But apparently you mean something else by HIP being connection-oriented. Could you be more specific? > Also, the draft needs to say how HIP architecture affect multicast. If > HIP doesn't target multicast, then that should also be stated, IMO. I'm adding a statement that back in 2003 nobody, AFAIK, had thought about HIP and multicast. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 10:06:37 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28939 for ; Wed, 13 Oct 2004 10:06:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8867D72F9; Wed, 13 Oct 2004 08:57:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from smtp806.mail.sc5.yahoo.com (smtp806.mail.sc5.yahoo.com [66.163.168.185]) by honor.icsalabs.com (Postfix) with SMTP id 4DBB472E6 for ; Wed, 13 Oct 2004 08:56:22 -0400 (EDT) Received: from unknown (HELO ?127.0.0.1?) (prem?yogesh@sbcglobal.net@67.64.149.176 with plain) by smtp806.mail.sc5.yahoo.com with SMTP; 13 Oct 2004 14:05:23 -0000 Message-ID: <416D35C7.1030801@acm.org> From: Yogesh Prem Swami User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416CB921.2060700@acm.org> <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> In-Reply-To: <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 09:03:51 -0500 Date: Wed, 13 Oct 2004 09:03:51 -0500 Content-Transfer-Encoding: 7bit > >> Also, the draft needs to say how HIP architecture affect multicast. >> If HIP doesn't target multicast, then that should also be stated, IMO. > > > I'm adding a statement that back in 2003 nobody, AFAIK, had thought > about HIP and multicast. This should be good enough. Yogesh _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 10:23:37 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00958 for ; Wed, 13 Oct 2004 10:23:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6540872F4; Wed, 13 Oct 2004 09:14:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id E9C0172E6 for ; Wed, 13 Oct 2004 09:13:25 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9DEMRui006313 for ; Wed, 13 Oct 2004 08:22:27 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5J007NF19E18@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 08:22:26 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5J00CMX19BE1@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 08:22:26 -0600 (MDT) From: Julien Laganier In-reply-to: <212DBB48-1BAF-11D9-97E8-000D9331AFB0@nomadiclab.com> To: hipsec@honor.trusecure.com Cc: Pekka Nikander Message-id: <200410131623.48807.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <200410051944.56646.julien.laganier@sun.com> <200410111912.37238.julien.laganier@sun.com> <212DBB48-1BAF-11D9-97E8-000D9331AFB0@nomadiclab.com> Subject: [Hipsec] Is a HIT 126 or 128 bits long? Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 16:23:48 +0200 Date: Wed, 13 Oct 2004 16:23:48 +0200 Content-Transfer-Encoding: 7BIT Folks, In a private conversation (excerpt included at the end of the mail), Pekka and I talked about making HITs stored in the DNS type-opaque (the HIT doesn't contains bits telling its type), i.e.: Type1_HIT = SHA1_128(HI) Type2_HIT = HAA_64 + SHA1_64(HI) While the HIP base spec currently specifies that HITs used in the base protocol are of the form: Type1_HIT = 01 + SHA1_126(HI) Type2_HIT = 10 + HAA_62 + SHA1_64(HI) So at this point, I'd like to know what the WG consensus is w.r.t. the following questions: o Should we store 128 and 64+64 bits HITs in the DNS? o Should we use 128 and 64+64 bits HITs in the HIP header? o Should we derive and use 127 and 63+64 bits HITs in the legacy IPv6-compatible API for IPv6 apps? (This would be similar to the HIP-internal NATing that some people evocate about LSIs, or IP addresses as AIDs) o Should we think now to use longer HITs (e.g. using SHA256) in the protocol and the DNS? Thanks, --julien Pekka Nikander wrote: > >Julien Laganier wrote: > > > >Pekka Nikander wrote: > >> If we remove the HIT vs IPv6 LSI discussion from earlier on, > >> we have to change 5.1.3. My suggestion is that we store the > >> full 128 bit hash into the Type 1 HIT field, and define the > >> Type 2 and HAA fields to have 64 bits of HAA, where the HAA > >> includes the prefix (if any). > > > > If I understand correctly, that means that HITs would be > > type-opaque, right? Is this not a problem if one wants to perform > > HIT-based access control? Also, how does a node verify its peer's > > HIT with the current protocol (the exchange doesn't include the > > peers' HIT type) ? > > Remember that we are defining only DNS use, not how HITs are used, > e.g., in the base spec. We can use 128-bit hashes in the DNS, > as the RR explicitly lists the HIT type, and then use only 126-bit > hashes in the base exchange. Maybe add: > > Note that the format how HITs are stored in the DNS may be > different form the format actually used in protocols, the > HIP base exchange included. This is because the DNS > RR explicitly contains the HIT type, while some protocols > may prefer to use a prefix to indicate the HIT type. The > implementations are expected to use the actual HI when > comparing Host Identities. > > >> But this seems to be something that we probably have to discuss > >> at the WG. > > > > Should I send an email to the ML? > > Yes. I think the suggestion is that > > - use 128 or 64+64 bit HITs in the DNS > - continue using 2+126 and 2+62+64 bit HITs in the > base specification, for now > - be open to even longer HITs, e.g. 256-bit long -- Julien Laganier SUN Microsystems Laboratories _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 10:53:37 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05029 for ; Wed, 13 Oct 2004 10:53:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6F7F772F4; Wed, 13 Oct 2004 09:44:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id 6435972E6 for ; Wed, 13 Oct 2004 09:43:39 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1CHkUX-0003wu-00; Wed, 13 Oct 2004 10:52:37 -0400 From: Tim Shepard To: Julien Laganier Cc: hipsec@honor.trusecure.com, Pekka Nikander Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? In-reply-to: Your message of Wed, 13 Oct 2004 16:23:48 +0200. <200410131623.48807.julien.laganier@sun.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 10:52:36 -0400 Date: Wed, 13 Oct 2004 10:52:36 -0400 > o Should we think now to use longer HITs (e.g. using SHA256) in the > protocol and the DNS? > I don't know if we want to change the base spec at this particular point in time, but I believe a deployable HIP will need to support longer HITs. There was also an understanding (in hallway conversations at IETF meetings) that the LSI's passed accross IPv6 APIs would be a few to a dozen bits shorter than 128 bits (with a constant prefix prepended to fill 128 bits), so as not to consume too much of the IPv6 address space with this hack to allow references to HITs to be passed where APIs already support IPv6 addresses. The kernel could maintain a table maping these LSIs to the acutal HITs, whatever there lenght may be, and would presumably use the bottom 120 or so bits of the HIT as the bottom bits of the LSI. (Collisions would be unlikely.) At least that's my memory of this issue. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 10:53:44 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05050 for ; Wed, 13 Oct 2004 10:53:44 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 280427310; Wed, 13 Oct 2004 09:44:08 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id AF34372E6 for ; Wed, 13 Oct 2004 09:43:55 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA18104; Wed, 13 Oct 2004 07:52:36 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9DEqZs08404; Wed, 13 Oct 2004 07:52:35 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Oct 2004 07:52:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608A9@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Thread-Index: AcSw/EkF8bEv51AfTieXA3Z8xMIqiAANeVdg From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: , "Yu-Shun Wang" , "Robert Moskowitz" , X-OriginalArrivalTime: 13 Oct 2004 14:52:34.0652 (UTC) FILETIME=[4625E1C0:01C4B134] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 07:52:34 -0700 Date: Wed, 13 Oct 2004 07:52:34 -0700 Content-Transfer-Encoding: quoted-printable >=20 > > If control plane protocols can make use of existing transport=20 > > protocols, > > so much the better. >=20 > Actually, that makes a lot of things harder. You have to have special > rules in firewalls and middle boxes, etc. As a result, building > intelligent routers that separate fast path and slow path becomes > slightly more involved. >=20 > In this respect, the current HIP design is quite elegant, while e.g. > IKE is not. >=20 > But maybe I should tone down the argument and replace "architecturally > wrong" with "architecturally inelegant"? >=20 I agree with your argument about middleboxes-- that HIP admits new=20 architectural solutions that are middlebox-oriented. But that was made in a separate point in your proposed text. I think that it would suffice to say that IKE's use of UDP makes it architecturally more difficult to incorporate middleboxes. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 11:42:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09193 for ; Wed, 13 Oct 2004 11:42:40 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 999DA72F4; Wed, 13 Oct 2004 10:33:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id AF01372E6 for ; Wed, 13 Oct 2004 10:32:36 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9DFfcui024317 for ; Wed, 13 Oct 2004 09:41:39 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5J0075F4XD18@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 09:41:38 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5J00LJ64X5SV@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 09:41:31 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Digital Signature Algorithms In-reply-to: <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> To: Pekka Nikander Cc: hipsec@honor.trusecure.com Message-id: <200410131742.54278.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.7 References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 17:42:54 +0200 Date: Wed, 13 Oct 2004 17:42:54 +0200 Content-Transfer-Encoding: quoted-printable On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: > > So how does people feel about making both DSA and RSA mandatory > > in HIP? > > I don't have any strong opinions. IIRC, the usual IETF crypto > guidelines state that > > a) there must be at least one common MUST implement > algorithm that is considered secure enough > > b) the algorithms must be negotiable so that if the > currently MUST implement turns out to be insecure, > the implementations can be easily upgraded to use > some other, new MUST implement algorithm > > Anyone care to check what the guidelines and other > documents actually say? > > draft-ietf-ipsec-ikev2-algorithms-05.txt This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA=20 and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt.=20 However, an interesting thing is the new requirements keywords defined=20 in draft-ietf-ipsec-ikev2-algorithms-05.txt: SHOULD+ This term means the same as SHOULD. However it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This terms means the same as SHOULD. However an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time,it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD-. >=A0 =A0draft-iab-auth-mech-03.txt It said: =2D------------------- While the desire to support legacy authentication systems is under- standable, it should be resisted to the extent possible. Having mul- tiple equivalent mechanisms dramatically increases both implementa- tion complexity and interoperability problems. When designing a new system, designers should choose a very small number of authentication mechanisms, with no more than one of any given class. =2D------------------- And later =2D------------------- 13.2. Use As Few Mechanisms as You Can Preferably, systems should have only one form of authentication. The more methods of authentication a system allows, the more things there are to go wrong. Remember that a chain is only as strong as its weak- est link. In general, there are two reasons why systems allow more than one authentication mechanism. The first is that you're retrofitting a system which already has a large number of authentica- tion mechanisms which cannot be displaced. The second is that users have widely different environments which for some reason cannot use the same authentication mechanism conveniently (e.g. some users have tokens and some do not). Naturally, designers need to take such considerations into account but they should take reasonable steps to minimize the number of mech- anisms. Designers should take special care to minimize the number of equivalent mechanisms. For instance, a system that provides a chal- lenge/response mechanism and a public key based mechanism is a rea- sonable design, one that provides three different challenge/response mechanisms is not. This doesn't mean that designers should not use security frameworks where multiple mechanisms are appropriate, but it does mean that they should be avoided unless necessary. Where generic security frameworks are used, they supported mechanisms should be carefully profiled to a minimal set. =2D------------------- >=A0 =A0crypto forum? I can ask them. > From a robustness point of view, it would of course good to > have multiple MUST implement algorithms. OTOH, I think > that there should also be some guidelines how to use them > so that the chances of interoperability are maintained > even in the case that one of the hosts only supports one > algorithm, e.g., due to policy reasons. > > Maybe we could have DSA as MUST and RSA as SHOULD? > > --Pekka I'm a bit confused by what I've read on the subject: IKEv2 has DSA as=20 MUST and RSA as MUST, but draft-iab-auth-mech says that it should be=20 avoided unless necessary. If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI=20 algorithm capabilities (between RSA and DSA), so I tend to think that=20 we should have both as MUST. Is there any other opinions the subject? Thanks, =2D-julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 11:54:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09867 for ; Wed, 13 Oct 2004 11:54:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9779D72F4; Wed, 13 Oct 2004 10:45:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 912F772E6 for ; Wed, 13 Oct 2004 10:44:07 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9DFrAui001224 for ; Wed, 13 Oct 2004 09:53:10 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5J004YW5GLQR@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 09:53:09 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5J00LIE5GIT4@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 13 Oct 2004 09:53:09 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? In-reply-to: To: Tim Shepard Cc: hipsec@honor.trusecure.com, Pekka Nikander Message-id: <200410131754.31591.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 17:54:31 +0200 Date: Wed, 13 Oct 2004 17:54:31 +0200 Content-Transfer-Encoding: 7BIT On Wednesday 13 October 2004 16:52, Tim Shepard wrote: > > o Should we think now to use longer HITs (e.g. using SHA256) in > > the protocol and the DNS? > > I don't know if we want to change the base spec at this particular > point in time, but I believe a deployable HIP will need to support > longer HITs. I agree that changing the base spec at this point might be problematic (especially because HITs are in the base header which is supposed to have a fixed length). I think, however, that we can easily introduce variable length data structure to store HIT in the DNS, which might be useful in the future. Thanks, --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 12:25:37 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12785 for ; Wed, 13 Oct 2004 12:25:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 018F072F4; Wed, 13 Oct 2004 11:16:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 65B6E72E6 for ; Wed, 13 Oct 2004 11:15:33 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1439E89882; Wed, 13 Oct 2004 19:24:32 +0300 (EEST) Message-ID: <416D566A.4070909@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> In-Reply-To: <200410131742.54278.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 19:23:06 +0300 Date: Wed, 13 Oct 2004 19:23:06 +0300 Content-Transfer-Encoding: 7bit I'd be fine with just one algorithm (for now). And my slight preference for that algorithm is RSA... --Jari Julien Laganier wrote: > On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: > >>>So how does people feel about making both DSA and RSA mandatory >>>in HIP? >> >>I don't have any strong opinions. IIRC, the usual IETF crypto >>guidelines state that >> >> a) there must be at least one common MUST implement >> algorithm that is considered secure enough >> >> b) the algorithms must be negotiable so that if the >> currently MUST implement turns out to be insecure, >> the implementations can be easily upgraded to use >> some other, new MUST implement algorithm >> >>Anyone care to check what the guidelines and other >>documents actually say? >> >> draft-ietf-ipsec-ikev2-algorithms-05.txt > > > This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA > and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt. > > However, an interesting thing is the new requirements keywords defined > in draft-ietf-ipsec-ikev2-algorithms-05.txt: > > SHOULD+ This term means the same as SHOULD. However it is > likely that an algorithm marked as SHOULD+ will be > promoted at some future time to be a MUST. > SHOULD- This terms means the same as SHOULD. However an > algorithm marked as SHOULD- may be deprecated to a > MAY in a future version of this document. > MUST- This term means the same as MUST. However we > expect at some point that this algorithm will no > longer be a MUST in a future document. Although > its status will be determined at a later time,it > is reasonable to expect that if a future revision > of a document alters the status of a MUST- > algorithm, it will remain at least a SHOULD or a > SHOULD-. > > >> draft-iab-auth-mech-03.txt > > > It said: > > -------------------- > While the desire to support legacy authentication systems is under- > standable, it should be resisted to the extent possible. Having mul- > tiple equivalent mechanisms dramatically increases both implementa- > tion complexity and interoperability problems. When designing a new > system, designers should choose a very small number of authentication > mechanisms, with no more than one of any given class. > -------------------- > > And later > > -------------------- > 13.2. Use As Few Mechanisms as You Can > > Preferably, systems should have only one form of authentication. The > more methods of authentication a system allows, the more things there > are to go wrong. Remember that a chain is only as strong as its weak- > est link. In general, there are two reasons why systems allow more > than one authentication mechanism. The first is that you're > retrofitting a system which already has a large number of authentica- > tion mechanisms which cannot be displaced. The second is that users > have widely different environments which for some reason cannot use > the same authentication mechanism conveniently (e.g. some users have > tokens and some do not). > > Naturally, designers need to take such considerations into account > but they should take reasonable steps to minimize the number of mech- > anisms. Designers should take special care to minimize the number of > equivalent mechanisms. For instance, a system that provides a chal- > lenge/response mechanism and a public key based mechanism is a rea- > sonable design, one that provides three different challenge/response > mechanisms is not. > > This doesn't mean that designers should not use security frameworks > where multiple mechanisms are appropriate, but it does mean that they > should be avoided unless necessary. Where generic security frameworks > are used, they supported mechanisms should be carefully profiled to a > minimal set. > -------------------- > > >> crypto forum? > > > I can ask them. > > >> From a robustness point of view, it would of course good to >>have multiple MUST implement algorithms. OTOH, I think >>that there should also be some guidelines how to use them >>so that the chances of interoperability are maintained >>even in the case that one of the hosts only supports one >>algorithm, e.g., due to policy reasons. >> >>Maybe we could have DSA as MUST and RSA as SHOULD? >> >>--Pekka > > > I'm a bit confused by what I've read on the subject: IKEv2 has DSA as > MUST and RSA as MUST, but draft-iab-auth-mech says that it should be > avoided unless necessary. > > If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI > algorithm capabilities (between RSA and DSA), so I tend to think that > we should have both as MUST. > > Is there any other opinions the subject? > > Thanks, > > --julien > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 13 13:21:37 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17142 for ; Wed, 13 Oct 2004 13:21:36 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 11DC772F4; Wed, 13 Oct 2004 12:12:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by honor.icsalabs.com (Postfix) with ESMTP id 852F972E6 for ; Wed, 13 Oct 2004 12:11:28 -0400 (EDT) Received: from [192.168.1.105] (adsl-69-227-177-34.dsl.irvnca.pacbell.net [69.227.177.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9DHJcJ24193; Wed, 13 Oct 2004 10:19:38 -0700 (PDT) Message-ID: <416D63A6.6090904@isi.edu> From: Yu-Shun Wang User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080800080009040505040401" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: yushunwa@isi.edu Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 13 Oct 2004 10:19:34 -0700 Date: Wed, 13 Oct 2004 10:19:34 -0700 This is a cryptographically signed message in MIME format. --------------ms080800080009040505040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> I am not a big fan of IKE (v1/v2), but just feel something >> is still missing in the reasoning below. > As Bob wrote, he was told to remove any argumentation about HIP vs. > IKE from the earlier versions of the architecture document. However, > lately people have asked about this, and therefore IMHO it would be > a good idea to say something. But I don't know what. Understood. I suspect not all reasons back then were technical. >> In a way, the HIP exchange is >> analogous to DNS, you contact somebody to resolve an identity in >> one domain into an identity in another domain. It just happens >> in this case the 'somebody' is also the destination you want to >> communicate with. This exchange should be considered a separate >> communication, and is free to use whatever protocol or even out- >> of-band information if available. > Hmm... Interesting thought. Yes, HIP does involve a resolution > or translation concept, and even more so in the case of Hi3. Yes, I know most people don't think of IKE-style of exchanging keys as a form of resolution, but in the aspect of HIP, the result of exchange is then used as a form of IDs. That's why. > It is a nice idea that maybe we could disentangle the HIP protocol > from the rest of HIP architecture. In a way, both BEET and CELP > are steps into that direction (though in almost completely different > levels.) Perhaps we need a kind of API that could be used both > to control BEET IPsec based translation and CELP like translation? Another part is to re-use existing protocols if it's good enough to support what we want. > However, IIRC, we were not in that level last fall. As the intention > is to publish the architecture document as reflecting our thoughts > as they were a year ago, it may not be possible to include anything > about this into the draft. Fair enough. I wasn't aware of this context. >> It is just a process of resolving identities, I am a bit unsure >> about the phrase "A protocol controlling another protocol..." >> Maybe I miss something here? > Well, the HIP protocol is more than just identity translation. It is > also about maintaining those translations in the face of mobility and > multi-homing. Some people have thought about adding QoS signalling > features to HIP. And so on. > > Besides, if we think about some other "control plane" or "signalling" > protocols, such as SIP, their primary function seems to be creating > connection (id to address translation, if you will), and then > maintenance of the session. Actually, I was expecting something closer to what you said above as the argument of why IKE isn't enough. (But then you also mentioned MOBIKE below which sort of fill this gap...:-) Anyways, this type of reasoning is imho stronger than the architectural point of view at the beginning. >>> Third, from a conceptual point of view, the IPsec Security >>> Parameter Index (SPI) in ESP provides a simple compression of >>> the HITs. This does require per-HIT-pair SAs (and SPIs), and a >>> decrease of policy granularity over other Key Management >>> Protocols, such as IKE and IKEv2. ... >> This sounds like what we want is a subset of what IKEv1/v2 have. >> This is an efficiency and optimization issue. I guess what I'd >> like to see is a more compelling reasoning why we have to use >> a different protocol. Otherwise another side of the argument >> would be why not define HIP exchange as a profile of IKE to save >> the trouble of inventing another protocol? (I'm sure you hear >> about all that by now. Maybe even an ID in the work?) > I think it would be a very useful exercise to try to write an > IKEv2 profile that would allow HIP-like SA creation. You probably > also need MOBIKE extensions. Indeed, if that would become good > enough, it might be even good to trash the current HIP protocol > almost completely and move to IKEv2. However, I'm almost sure > that some important aspects of the current HIP design would probably > be lost. It is then another question to decide whether such loss > is important enough to retain a separate protocol or not. Yes, I don't know HIP well enough to enumerate what could be lost if we use IKE. But the comparison and what's lost if IKEv2 is used are what most of us would really like to see. Though it doesn't have to be in this document as it would surely delay the process. > However, even if such an exercise would be quite useful, that > should not slow down current progress with HIP. It is most > important to get some deployment experience. Only that helps > us with the next stages of design. Good enough for me. As a practical suggestion, I think your original first reason (the arch point of view) should probably be removed. Then we just need a simple, high level list of what could be lost or hard to do if using IKEv2 in place of HIP exchange with the statement that we are not closing the door on future development of HIP exchange as an IKE profile. Though this seems like a reverse of what brought on this whole discussion, the original text IMO does not really serve the purpose of explaining "why not IKE(v2)". Thanks, yushun -- Yu-Shun Wang USC Information Sciences Institute --------------ms080800080009040505040401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MTAxMzE3MTkzNFowIwYJKoZIhvcNAQkEMRYEFBuKxiwOfhjM+Wx+U7FxS8QE v2OtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBAGb8P5xgBTh6KhgTpUg+jmQ88TZOn100lRNs 3KWzSfsZcsjgXP0xZFxBeYdXntxSRFD/i76mtL/ZQnx1s/iY2P827tZtxIRvXNTJOkOeom6K LYMoaJtsIJbNHXEMPk2TjnVNbXC/xL4P0V2/0RzG+MtEhFeYq+N/QRHboNHSqP3yqgtCPkRX LyRAk+69gdkQCunrAae1rihOM9Vmezyd4YOpopI9kp1u/wx6ofaD7eCi5JEO58BjBgFQHh0l M4qhLwEqzKDoPxUtbuqS/NBIaoglyjdpsO0+/8JpDjuqEYWGLRlTpGqdzfrqsUdmlb8JFLEO ZzFv4cQF0kIVp6qBKSUAAAAAAAA= --------------ms080800080009040505040401-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 14 02:08:41 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02958 for ; Thu, 14 Oct 2004 02:08:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A9D8572F4; Thu, 14 Oct 2004 00:59:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id BC84372E6 for ; Thu, 14 Oct 2004 00:58:56 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 3AB09220004; Thu, 14 Oct 2004 09:08:01 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 9FEA18; Thu, 14 Oct 2004 09:08:01 +0300 (EEST) In-Reply-To: <416D63A6.6090904@isi.edu> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> <416D63A6.6090904@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, Robert Moskowitz , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: Yu-Shun Wang X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 14 Oct 2004 09:07:59 +0300 Date: Thu, 14 Oct 2004 09:07:59 +0300 Content-Transfer-Encoding: 7bit > Actually, I was expecting something closer to what you said > above as the argument of why IKE isn't enough. (But then you > also mentioned MOBIKE below which sort of fill this gap...:-) > Anyways, this type of reasoning is imho stronger than the > architectural point of view at the beginning. Well, AFAIK, the real reasons for a separate protocol were mostly political (attitude at IPsec WG, among other things) and architectural. Back when Bob began, technically it would have been fairly easy to develop IKE into a direction where it would have also served HIP purposes. Unfortunately, few people understood the HIP idea, and quite a few people opposed it, some bitterly. Hence, making IKE HIP-friendly would never have worked out politically. Hence, if we now list technical arguments why we need a separate protocol, that is more an afterthought than the original, architectural baseline. The architectural stance towards middle boxes is one big difference, the other one being policy granularity. Both are _architectural_ in nature. The third issue, a separate protocol instead of running on the top of UDP, is also architectural in nature, but much harder to argue about. Here people seem to have widely different opinions. My firm belief is that we've made the right choice. As an indication of this is that we don't need separate IPsec policy rules to except some UDP ports from others. That may seem as a minor issue, but getting the architecture right often manifests itself initially in very subtle ways, and the big picture becomes fully visible only later on. Other people believe that the choice is detrimental since it makes it harder to work with current NATs. As I have repeatedly stated, from a practical point of view I agree with the UDP proponents, but I can't agree from an architectural point of view. Maybe I am stubborn, dull, and stupid. Or maybe I'm just dense and got my intuition right. Anyway, I think it is useless to argue too much about this point now. We'll have much better perspective once we have some initial deployment experience. > Yes, I don't know HIP well enough to enumerate what could be > lost if we use IKE. But the comparison and what's lost if IKEv2 > is used are what most of us would really like to see. Please go ahead. There may be other people that are interested. At this point, the results belong to the HIP RG. However, I presume that they would be very useful at the next HIP WG re-chartering time. > ... As a practical suggestion, I think your original > first reason (the arch point of view) should probably be removed. I understand. It looks like that people agree with - the middle box friendliness argument (enable layer 3.5 routing) - the policy granularity argument (layer 3.5 is end-point- to-end-point, as connection multiplexing happens only on layer 4) I can certainly remove the separate protocol argument. However, if we are able to find a wording that the WG deems easy enough to understand, I'd like to preserve something of it. What I want to say, basically, is that most "signalling" protocols either - use in-line signalling (TCP, SCTP, SSH, ...) - are directly on the top of controlled protocol (ICMP, portmapper, SIP, PPP control protocols, ...) - and this seems to be right. There are a few notable exceptions, BGP and IKE being the prime examples. They both may get it "right", given their requirements, but I doubt the IKE case. In the BGP case, my (perhaps flawed) understanding is that they wanted to use the reliability mechanisms from TCP. I don't remember what (if any) the arguments were in the IKE case. I'm sure there are other exceptions, but I can't remember them now. Now, the real question is why would it be better to place the signalling protocols either in-line or directly on the top? Here I am more on my own wits than on anything that I've heard or read, hence be careful. But let's go. 1. If there is a protocol X between the protocol P and its control protocol S, the protocol X may have its own control functions that make the system complex and unstable. [In the IKE case, UDP has little control at all. In the BGP case, TCP control is in-line. Hence, this problem doesn't manifest itself there.] 2. If the protocol P somehow controls the functions of the protocol X on the top of it, the system becomes complicated. This is the case for IKE. This complication manifests itself in the exception policy rules; see above. [This would not be a big deal if we considered HIP alone. However, some people (me included) would want to be able to run HIP in parallel with IKE, and there this is an issue.] 3. When designing fast middle boxes, it often becomes important to separate the data plane and control plane from each other. One wants to process data plane packets using the fast path, e.g., a few tens or hundreds of micro code instructions per packet, while the control protocol goes to slow path. [This requires more complex micro code for IKE, since you have to check UDP ports, while in HIP case you don't.] There are probably other technical issues embedded in this, but they evade my mind now. Now, the question is how to put this all in a succinct way to the architecture document. I don't want to go in this detail there, as the document is also otherwise quite content laden, and expanding all the details wouldn't serve the purpose. I'd be grateful if someone could propose some text. I'll try to do it myself tomorrow, but help is appreciated. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 14 06:15:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25996 for ; Thu, 14 Oct 2004 06:15:42 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A97C472F4; Thu, 14 Oct 2004 05:06:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id C4FA172E6 for ; Thu, 14 Oct 2004 05:05:01 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 035B9220004; Thu, 14 Oct 2004 13:13:59 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 7786F8; Thu, 14 Oct 2004 13:13:59 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julien Laganier , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? To: Tim Shepard X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 14 Oct 2004 13:13:57 +0300 Date: Thu, 14 Oct 2004 13:13:57 +0300 Content-Transfer-Encoding: 7bit >> o Should we think now to use longer HITs (e.g. using SHA256) in the >> protocol and the DNS? > > I don't know if we want to change the base spec at this particular > point in time, but I believe a deployable HIP will need to support > longer HITs. I concur. > There was also an understanding (in hallway conversations at IETF > meetings) that the LSI's passed accross IPv6 APIs would be a few to a > dozen bits shorter than 128 bits (with a constant prefix prepended to > fill 128 bits), so as not to consume too much of the IPv6 address > space with this hack to allow references to HITs to be passed where > APIs already support IPv6 addresses. The kernel could maintain a > table maping these LSIs to the acutal HITs, whatever there lenght may > be, and would presumably use the bottom 120 or so bits of the HIT as > the bottom bits of the LSI. (Collisions would be unlikely.) > > At least that's my memory of this issue. Your memory matches closely with mine. IIRC, we also felt that for practical purposes, we could continue with the HIT prefixes for then, and review the issue when we get close to publication. Maybe we are now closer to publication. If the WG feels so, I would suggest the following changes to the base and DNS specs: 1. Change the common header to include HIT types in Control: The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHT | DHT | | | | | | | | |C|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SHT Sender's HIT Type. Currently the following values are specified: 0 RESERVED 1 Type 1 HIT 2 Type 2 HIT 3-6 UNASSIGNED 7 RESERVED DHT Destionation's HIT type. 2. Change the DNS draft so that HAA has the HIT type of 7: 5.1.1 RDATA format HIT type .... 2 A 128-bit Type 2 HIT is present. 7 A 128-bit HAA is present. The idea is that there is only one IANA registry for the values 1-6, and values 0 and 7 are reserved in the IANA registry. 3. Change the text so that Type 1 HITs don't have any prefix at all, Type 2 HITs have a prefix TBD of length TBD. (To be assigned by IANA) > There are two types of HITs. HITs of the first type, called *type 1 > HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits consist of 128 bits > of the SHA-1 hash of the public key. HITs of the second type > consist > of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) TBD-bit prefix of TBD, > field, and only the last 64 bits come from a SHA-1 hash of the Host > Identity. This latter format for HIT is recommended for 'well known' > systems. It is possible to support a resolution mechanism for these > names in hierarchical directories, like the DNS. Another use of HAA > is in policy controls, see Section 12. Add: As the type of a HIT cannot be determined by inspecting its contents, the HIT type must be communicated by some external means. Historically, some early implementations had a 2-bit prefix of 01 for Type 1 HITs. It is expected to be a common practice to use that or a similar but longer prefix at the legacy IPv6 API; see Appendix A. Consequently, it is RECOMMENDED that implementations ignore the left most TBD bits when comparing HITs for equality. 4. Add some text about IPv6 LSIs to Appendix A (I think the -00 version of the DNS draft has text that might fit in there, at least if slightly edited.) Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 14 09:31:44 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14247 for ; Thu, 14 Oct 2004 09:31:43 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id BACE372F9; Thu, 14 Oct 2004 08:22:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id 99EA872F4 for ; Thu, 14 Oct 2004 08:21:07 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9EDUFNH008211 for ; Thu, 14 Oct 2004 07:30:15 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5K004JUTIFDG@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 14 Oct 2004 07:30:15 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5K00L44TIBT4@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 14 Oct 2004 07:30:14 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? In-reply-to: To: Pekka Nikander Cc: Tim Shepard , hipsec@honor.trusecure.com Message-id: <200410141531.37251.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 14 Oct 2004 15:31:37 +0200 Date: Thu, 14 Oct 2004 15:31:37 +0200 Content-Transfer-Encoding: 7BIT Hi Pekka, I basically agree with the changes you are proposing. I modified the IPv6 LSI text of the -00 of the DNS draft, included below, On Thursday 14 October 2004 12:13, Pekka Nikander wrote: > If the WG feels so, I would suggest the following changes to the > base and DNS specs: > > 1. Change the common header to include HIT types in Control: > > The following fields have been defined: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SHT | DHT | | | | | | | | |C|A| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > SHT Sender's HIT Type. Currently the following values are > specified: > > 0 RESERVED > 1 Type 1 HIT > 2 Type 2 HIT > 3-6 UNASSIGNED > 7 RESERVED > > DHT Destionation's HIT type. > > 2. Change the DNS draft so that HAA has the HIT type of 7: > > 5.1.1 RDATA format HIT type > > .... > > 2 A 128-bit Type 2 HIT is present. > 7 A 128-bit HAA is present. > > The idea is that there is only one IANA registry for the values > 1-6, and values 0 and 7 are reserved in the IANA registry. > > 3. Change the text so that Type 1 HITs don't have any prefix at > all, Type 2 HITs have a prefix TBD of length TBD. (To be assigned > by IANA) > > > There are two types of HITs. HITs of the first type, called > > *type 1 HIT*, consist of an initial 2 bit prefix of 01, followed > > by 126 bits > > consist of 128 bits > > > of the SHA-1 hash of the public key. HITs of the second type > > consist > > of an initial 2 bit prefix of 10, a Host Assigning Authority > > (HAA) > > TBD-bit prefix of TBD, > > > field, and only the last 64 bits come from a SHA-1 hash of the > > Host Identity. This latter format for HIT is recommended for > > 'well known' systems. It is possible to support a resolution > > mechanism for these names in hierarchical directories, like the > > DNS. Another use of HAA is in policy controls, see Section 12. > > Add: > > As the type of a HIT cannot be determined by inspecting its > contents, > the HIT type must be communicated by some external means. > > Historically, some early implementations had a 2-bit prefix of > 01 for Type 1 HITs. It is expected to be a common practice to use > that or a similar but longer prefix at the legacy IPv6 API; see > Appendix A. Consequently, it is RECOMMENDED that implementations > ignore the left most TBD bits when comparing HITs for equality. > > 4. Add some text about IPv6 LSIs to Appendix A > > (I think the -00 version of the DNS draft has text that might > fit in there, at least if slightly edited.) => Here's a modified excerpt matching the modifications you proposed: The first bit of a HIT is used to differentiate between Type 1 and Type 2 format. If the first bit is 0 then the rest of a HIT is the 127 upper bits of a SHA-1 hash of the Host Identity. If the first bit is 1 then the next 63 bits is the HAA field, and only the last 64 bits come from the hash of the Host Identity. Additionnaly, this document defines an internal IPv6-compatible LSI representation format, to be used within the legacy IPv6-compatible API (e.g., socket over AF_INET6). The format of these IPv6-compatible LSIs is designed to avoid the most commonly occurring IPv6 addresses in RFC3596 [9]. An IPv6-compatible LSI representation is easily computed by replacing the first TBDth bits of the corresponding HIT by the TBD bits long prefix "0xTBD". Allocation Prefix Fraction of IPv6 (binary) Address Space ------------------------ -------- ------------- IPv6 Address space 00 1/4 IPv6-compatible LSI TBD 1/2^TBD IPv6 Address space 11 1/4 => Question: Do we need to include the type of the HIT in one of the IPv6 LSI bits? If so, replace the last sentence and the table of the text above by: An IPv6-compatible LSI representation is easily computed by replacing the first TBDth bits of the corresponding HIT by the TBD-2 bits long prefix "0xTBD", while TBD-1th and TBDth bits are set to 01 for a Type 1 HIT, and 10 for a Type2 HIT Allocation Prefix Fraction of IPv6 (binary) Address Space ------------------------ -------- ------------- IPv6 Address space 00 1/4 Type 1 IPv6-compatible LSI TBD:01 1/2^(TBD+2) Type 2 IPv6-compatible LSI TBD:10 1/2^(TBD+2) IPv6 Address space 11 1/4 > Opinions? IMHO the following changes are worth. If the WG agrees, I'll also modify the DNS draft accordingly. Thanks, > --Pekka --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 14 10:34:42 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24555 for ; Thu, 14 Oct 2004 10:34:41 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9E9C17310; Thu, 14 Oct 2004 09:25:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by honor.icsalabs.com (Postfix) with ESMTP id C1F1972F9 for ; Thu, 14 Oct 2004 09:24:36 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1CI6ff-0004Vm-00; Thu, 14 Oct 2004 10:33:35 -0400 From: Tim Shepard To: Julien Laganier Cc: Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? In-reply-to: Your message of Thu, 14 Oct 2004 15:31:37 +0200. <200410141531.37251.julien.laganier@sun.com> Message-Id: Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 14 Oct 2004 10:33:35 -0400 Date: Thu, 14 Oct 2004 10:33:35 -0400 > (binary) Address Space > ------------------------ -------- ------------- > > IPv6 Address space 00 1/4 > Type 1 IPv6-compatible LSI TBD:01 1/2^(TBD+2) > Type 2 IPv6-compatible LSI TBD:10 1/2^(TBD+2) > IPv6 Address space 11 1/4 > I would guess that if we get a prefix in the IPv6 address space allocated for this purpose, it would start with 00 or 11. In particular, looking at http://www.iana.org/assignments/ipv6-address-space and thinking about what's already been allocated, it would seem to make the best sense would be something inside of (binary) 0000 0000. So I guess what I'm saying is that does not make sense to include the first and last lines in that table. -Tim Shepard shep@alum.mit.edu _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 15 08:07:52 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21661 for ; Fri, 15 Oct 2004 08:07:52 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id DF24772F9; Fri, 15 Oct 2004 06:58:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id 8237B72E8 for ; Fri, 15 Oct 2004 06:57:29 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9FC6fui004971 for ; Fri, 15 Oct 2004 06:06:41 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5M000H4KB446@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 15 Oct 2004 06:06:41 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5M00LEDKB1T4@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 15 Oct 2004 06:06:40 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Digital Signature Algorithms In-reply-to: <200410131742.54278.julien.laganier@sun.com> To: hipsec@honor.trusecure.com Cc: Pekka Nikander Message-id: <200410151408.04279.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <200410071521.16054.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 15 Oct 2004 14:08:04 +0200 Date: Fri, 15 Oct 2004 14:08:04 +0200 Content-Transfer-Encoding: 7BIT Folks, About the DSA vs RSA issue, here's an excerpt of a CFRG email mentionning an opinion about what algorithm should be used in existing, and new protocol/applications. --julien ---------- Forwarded Message ---------- Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory Date: Thursday 26 August 2004 19:32 From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , "Hughes, James P" Cc: "'saag@mit.edu'" , "'cfrg@ietf.org'" , "'kent@bbn.com'" I think that we should track status of crypto algs independently of their standards status. In particular I think that we should distinguish between Recommended and Acceptable status. New applications should specify algorithms with Recommended status Continued use of algorithms with Acceptable status should not raise concern. So I would classify as follows: Proposed: SHA-2 Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024 Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4 Depricated: IDEA, RSA1024+MD5 Obsolete: MD4, MD5, RSA-512, DES The reason that I distinguish between Depricated and obsolete is that there are uses of RSA signatures with MD5 hash that are still acceptably secure and the applications concerned do not support SHA1. The reason I put DSA as acceptable rather than recommended is that it does need a good random seed, the key size is small and it is unlikely at this point to see much use. RC4 has been compromised by Shamir & co, but as a general rule I don't think any stream cipher should ever get a higher status than acceptable. A stream cipher always allows a person who has a plaintext and ciphertext corresponding to a key to encode or decode all messages with that key that are shorter or the same size. In effect all stream ciphers are vulnerable to a trivial form of known plaintext attack, the attack does not reveal the key but this is not necessary. I do not feel confident in recommending moving to SHA2 at this point. Before jumping I want to see that the place we are going to is better than where we left. SHA2 is not currently widely used. If it turns out that the recent cryptanalysis of SHA1 is also applicable to the structures used in SHA2 then the rationale for a change is lost. I would feel happier moving to a hash function based on AES encryption (which i had eroneously assumed had been the point of the SHA2 work). _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Oct 16 01:43:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09907 for ; Sat, 16 Oct 2004 01:43:56 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 541C77338; Sat, 16 Oct 2004 00:34:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 6DF7B731F for ; Sat, 16 Oct 2004 00:33:44 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 732C1220003; Sat, 16 Oct 2004 08:42:55 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 1DE358; Sat, 16 Oct 2004 08:42:56 +0300 (EEST) In-Reply-To: <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> <416D63A6.6090904@isi.edu> <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3ABC363C-1F36-11D9-861F-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Jari Arkko , Robert Moskowitz , Yu-Shun Wang From: Pekka Nikander Subject: Re: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 16 Oct 2004 08:42:55 +0300 Date: Sat, 16 Oct 2004 08:42:55 +0300 Content-Transfer-Encoding: 7bit > It looks like that people agree with > > - the middle box friendliness argument (enable layer 3.5 > routing) > - the policy granularity argument (layer 3.5 is end-point- > to-end-point, as connection multiplexing happens only on > layer 4) > > I can certainly remove the separate protocol argument. However, > if we are able to find a wording that the WG deems easy enough > to understand, I'd like to preserve something of it. I decided to remove the argument about any architectural needs for a separate protocol. After contemplating it a little bit, I came to the conclusion that a) the argument is not very well baked, at least not yet b) historically, it was not really so in the beginning of the HIP process As a result, the proposed text now looks like the following: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2 together with Host Identifiers, to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, IKE (and IKEv2) were not design with middle boxes in mind. As adding a new naming layer allows one to potentially add a new forwarding layer (see , below), it is very important that the HIP protocols are friendly towards any middle boxes. Second, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. I'm now posting the draft to the repositories. If anyone feels so, we can return to this issue during the forthcoming WC LC. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Oct 16 02:11:52 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19948 for ; Sat, 16 Oct 2004 02:11:51 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C13D07338; Sat, 16 Oct 2004 01:02:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 31459731F for ; Sat, 16 Oct 2004 01:01:59 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id BC9EE220003 for ; Sat, 16 Oct 2004 09:11:16 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 905288 for ; Sat, 16 Oct 2004 09:11:17 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <312A5693-1F3A-11D9-861F-000D9331AFB0@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@honor.trusecure.com From: Pekka Nikander X-Mailer: Apple Mail (2.619) Subject: [Hipsec] draft-ietf-hip-arch-00.txt posted Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 16 Oct 2004 09:11:17 +0300 Date: Sat, 16 Oct 2004 09:11:17 +0300 Content-Transfer-Encoding: 7bit I have posted draft-ietf-hip-arch-00.txt. Due to the large number of -00 drafts posted at this time, it may take a few days before it appears in the repositories. In the meanwhile, the draft is available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00.html http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00.txt There are also diffs available against draft-moskowitz-hip-arch-06.txt: http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-diff.html As you can see from the diff, there are a number of mostly editorial changes in the introduction, and two more substantial changes - a new section saying that Multicast was not considered back then - new text in the IPsec section trying to clarify the relationship to IKEv2 --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Oct 16 03:50:52 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29929 for ; Sat, 16 Oct 2004 03:50:52 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EDCCB7338; Sat, 16 Oct 2004 02:41:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by honor.icsalabs.com (Postfix) with ESMTP id 0531D731F for ; Sat, 16 Oct 2004 02:40:32 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9G7ngRU018741 for ; Sat, 16 Oct 2004 09:49:43 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sat, 16 Oct 2004 09:49:42 +0200 Received: from ericsson.com (EFO9N000L5C7100 [153.88.42.141]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J521A63; Sat, 16 Oct 2004 09:49:42 +0200 Message-ID: <4170D296.5060909@ericsson.com> X-Sybari-Trust: 721e51ff 74898554 636f5656 00000139 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: Pekka Nikander , David Ward , Robert Moskowitz References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> In-Reply-To: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2004 07:49:42.0058 (UTC) FILETIME=[B22488A0:01C4B354] Subject: [Hipsec] WG LC on architecture draft Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 16 Oct 2004 10:49:42 +0300 Date: Sat, 16 Oct 2004 10:49:42 +0300 Content-Transfer-Encoding: 7bit Folks, I would like to start the WGLC on the architecture draft. This WGLC will finish on November 15th. The draft will appear shortly in the archives. In the meantime, you can fetch it from: http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt A few words on the scope of this WGLC. This draft was originally intended to be published before WG formation, but it has been delayed for a number of reasons. As the draft states, the purpose of the document is to document the architectural reasoning as it was stated during the time of WG formation, and therefore the draft is informational or almost historical in nature. Hence, we ask people for clarifications, so that the content is understandable and easy to comprehend. However, asking for new argumentation (that did not exist back in fall 2003) or inclusion of new text may not be appropriate. Please, send you comments to the authors and to the mailing list. Thanks, Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 07:34:13 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07372 for ; Mon, 18 Oct 2004 07:34:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2BF9172E8; Mon, 18 Oct 2004 06:24:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id BDBE872E2 for ; Mon, 18 Oct 2004 06:23:49 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 20281212CF1; Mon, 18 Oct 2004 14:33:20 +0300 (EEST) Message-ID: <4173A99D.6000303@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: Julien Laganier , Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> In-Reply-To: <416D566A.4070909@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 14:31:41 +0300 Date: Mon, 18 Oct 2004 14:31:41 +0300 Content-Transfer-Encoding: 7bit So, what people think? We have (at least) four alternatives: 1) Stay at current: DSA mandatory 2) Both DSA and RSA mandatory 3) DSA mandatory, RSA SHOULD 4) Change the mandatory to RSA Opinions? /petri Jari Arkko wrote: > I'd be fine with just one algorithm (for now). > And my slight preference for that algorithm is > RSA... > > --Jari > > Julien Laganier wrote: > >> On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: >> >>>> So how does people feel about making both DSA and RSA mandatory >>>> in HIP? >>> >>> >>> I don't have any strong opinions. IIRC, the usual IETF crypto >>> guidelines state that >>> >>> a) there must be at least one common MUST implement >>> algorithm that is considered secure enough >>> >>> b) the algorithms must be negotiable so that if the >>> currently MUST implement turns out to be insecure, >>> the implementations can be easily upgraded to use >>> some other, new MUST implement algorithm >>> >>> Anyone care to check what the guidelines and other >>> documents actually say? >>> >>> draft-ietf-ipsec-ikev2-algorithms-05.txt >> >> >> >> This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA >> and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt. >> However, an interesting thing is the new requirements keywords defined >> in draft-ietf-ipsec-ikev2-algorithms-05.txt: >> >> SHOULD+ This term means the same as SHOULD. However it is >> likely that an algorithm marked as SHOULD+ will be >> promoted at some future time to be a MUST. >> SHOULD- This terms means the same as SHOULD. However an >> algorithm marked as SHOULD- may be deprecated to a >> MAY in a future version of this document. >> MUST- This term means the same as MUST. However we >> expect at some point that this algorithm will no >> longer be a MUST in a future document. Although >> its status will be determined at a later time,it >> is reasonable to expect that if a future revision >> of a document alters the status of a MUST- >> algorithm, it will remain at least a SHOULD or a >> SHOULD-. >> >> >>> draft-iab-auth-mech-03.txt >> >> >> >> It said: >> >> -------------------- >> While the desire to support legacy authentication systems is under- >> standable, it should be resisted to the extent possible. Having mul- >> tiple equivalent mechanisms dramatically increases both implementa- >> tion complexity and interoperability problems. When designing a new >> system, designers should choose a very small number of authentication >> mechanisms, with no more than one of any given class. >> -------------------- >> >> And later >> >> -------------------- >> 13.2. Use As Few Mechanisms as You Can >> >> Preferably, systems should have only one form of authentication. The >> more methods of authentication a system allows, the more things there >> are to go wrong. Remember that a chain is only as strong as its weak- >> est link. In general, there are two reasons why systems allow more >> than one authentication mechanism. The first is that you're >> retrofitting a system which already has a large number of authentica- >> tion mechanisms which cannot be displaced. The second is that users >> have widely different environments which for some reason cannot use >> the same authentication mechanism conveniently (e.g. some users have >> tokens and some do not). >> >> Naturally, designers need to take such considerations into account >> but they should take reasonable steps to minimize the number of mech- >> anisms. Designers should take special care to minimize the number of >> equivalent mechanisms. For instance, a system that provides a chal- >> lenge/response mechanism and a public key based mechanism is a rea- >> sonable design, one that provides three different challenge/response >> mechanisms is not. >> >> This doesn't mean that designers should not use security frameworks >> where multiple mechanisms are appropriate, but it does mean that they >> should be avoided unless necessary. Where generic security frameworks >> are used, they supported mechanisms should be carefully profiled to a >> minimal set. >> -------------------- >> >> >>> crypto forum? >> >> >> >> I can ask them. >> >> >>> From a robustness point of view, it would of course good to >>> have multiple MUST implement algorithms. OTOH, I think >>> that there should also be some guidelines how to use them >>> so that the chances of interoperability are maintained >>> even in the case that one of the hosts only supports one >>> algorithm, e.g., due to policy reasons. >>> >>> Maybe we could have DSA as MUST and RSA as SHOULD? >>> >>> --Pekka >> >> >> >> I'm a bit confused by what I've read on the subject: IKEv2 has DSA as >> MUST and RSA as MUST, but draft-iab-auth-mech says that it should be >> avoided unless necessary. >> >> If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI >> algorithm capabilities (between RSA and DSA), so I tend to think that >> we should have both as MUST. >> >> Is there any other opinions the subject? >> >> Thanks, >> >> --julien >> _______________________________________________ >> Hipsec mailing list >> Hipsec@honor.trusecure.com >> http://honor.trusecure.com/mailman/listinfo/hipsec >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 07:44:08 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08169 for ; Mon, 18 Oct 2004 07:44:08 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 10BF472E6; Mon, 18 Oct 2004 06:34:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 4D32872E2 for ; Mon, 18 Oct 2004 06:33:04 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 5ACA5220003 for ; Mon, 18 Oct 2004 14:42:30 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2ACDA8 for ; Mon, 18 Oct 2004 14:42:26 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200410151408.04279.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Digital Signature Algorithms To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 13:46:02 +0300 Date: Mon, 18 Oct 2004 13:46:02 +0300 Content-Transfer-Encoding: 7bit My sense from the discussion so far is that people slightly favour RSA. Hence, apparently we should go for - RSA MUST implement algorithm - DSA SHOULD implement algorithm What comes to algorithm negotiation, I think that we can go with the following approach: 1. In the case where the Initiator pre-fetches the Responder's HIT from somewhere (DNS, DHT, local storage), it can select a HIT that uses the desirable algorithm. That is, if the Initiator wants to use RSA, it selects an RSA based HIT for the Responder. 2. In the case where the Initiator sends a NULL HIT in I1 (opportunistic mode), we can simply state that the Initiator MUST support both RSA and DSA, and that the Responder SHOULD use a MUST algorithm (RSA) based key. To facilitate that, it seems that changing Step 4 in Section 8.5 is enough: -- 4. The R1 MUST contain the received responder HIT, unless the received HIT is NULL, in which case the Responder SHOULD select a HIT that is constructed with the MUST algorithm in Section 3, which is currently RSA. Other than that, selecting the HIT is a local policy matter. -- Adding some text to 7.1 doesn't seem to hurt: Add after "NULL (all zeros) as the Responder's HIT": -- If the Initiator send a NULL as the Responder's HIT, it MUST be able to handle all MUST and SHOULD algorithms from Section 3, which are currently RSA and DSA. -- If everybody is happy with that, we apparently need the following changes: - change second paragraph of Section 3 as follows: -- HIP implementations MUST support the Rivest Shamir Adelman (RSA) [XXX] public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) [13] algorithm; other algorithms MAY be supported. -- - new text to 3.1.1 to define, exactly, how to compute a HIT from a given RSA key. [I'm off-line so I can't prepare a proposal.] - fix the references in 6.2.10 - change the example text in the end of 6.2.13 to include text for RSA. - Add RFC 3110 reference which seems to be missing. I couldn't find any other places in the base spec, but may be there are others. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 07:46:07 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08309 for ; Mon, 18 Oct 2004 07:46:07 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 23FCF72F9; Mon, 18 Oct 2004 06:36:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id C56D772E2 for ; Mon, 18 Oct 2004 06:35:06 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 62264220003; Mon, 18 Oct 2004 14:44:39 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 67EC78; Mon, 18 Oct 2004 14:44:25 +0300 (EEST) In-Reply-To: <200410141531.37251.julien.laganier@sun.com> References: <200410141531.37251.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Tim Shepard , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Is a HIT 126 or 128 bits long? To: Petri Jokela (JO/LMF) , Julien Laganier X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 14:42:38 +0300 Date: Mon, 18 Oct 2004 14:42:38 +0300 Content-Transfer-Encoding: 7bit > I basically agree with the changes you are proposing. I modified the > IPv6 LSI text of the -00 of the DNS draft, included below, Ok. Unless someone objects, IMHO you and Petri could edit in the changes to the -01 versions. To reduce secretariat load, it may not be necessary to post an -01 version of the dns draft, but it would be good if a pre-01 version was available prior to the meeting. But then, I'm afraid, we have to be prepared at the meeting that some people have only read -00 version, and adjust the presentation accordingly. >> 4. Add some text about IPv6 LSIs to Appendix A >> >> (I think the -00 version of the DNS draft has text that might >> fit in there, at least if slightly edited.) > > => Here's a modified excerpt matching the modifications you proposed: > > The first bit of a HIT is used to differentiate between Type 1 and > Type 2 format. If the first bit is 0 then the rest of a HIT is the > 127 upper bits of a SHA-1 hash of the Host Identity. If the first bit > is 1 then the next 63 bits is the HAA field, and only the last 64 > bits come from the hash of the Host Identity. Actually my suggestion was that there is no content differences between Type 1 and Type 2, but that the difference is always communicated by some external means. In the DNS it is the type field, in the HIP protocol the proposed SHT and DHT control fields. Hence, I would rewrite the paragraph, and what followed, as follows: -- Historically, the first two bits of a HIT were used to differentiate between Type 1, Type 2, and IPv6 address formats. This was changed in October 2004, when the Working Group decided that all (currently defined) HITs are 128-bit long. Hence, a Type 1 HIT consists of 128 bits of the SHA-1 hash of the public key, and a Type 2 HIT consists of a 64-bits long HAA field, followed by a 64-bits of the SHA-1 hash. [The format of the HAA field is left undefined in this document.] In this document, we additionally define an internal IPv6-compatible LSI- representation format, to be used within the legacy IPv6-compatible API (e.g., socket over AF_INET6). The format of these IPv6-compatible LSIs is designed to avoid the most commonly occurring IPv6 addresses in RFC3596 [9]. An IPv6-compatible LSI representation of a HIT can be easily computed by replacing the first TBDth bits of the HIT by the TBD bits long prefix "0xTBD". Accordingly, this specification also RECOMMENDS that conforming implementations ignore the TBD prefix bits when comparing HITs for equality; see Section XXX. -- As the text above is supposed to be in an appendix, we have to add in the HIT section of the base document text like the following: -- When comparing HITs for equality, it is RECOMMENDED that conforming implementations ignore the TBD top most bits. This is to allow better compatibility for legacy IPv6 applications; see Appendix A. However, independent of how many bits are actually used for HIT comparison, it is also RECOMMENDED that the final equality decision is based on the public key and not the HIT, if possible. See also Section for related discussion. -- I don't think we need the HIT space allocation table, but separately seek for IANA registration for the prefix, perhaps writing a brief separate document (one page long?) that defines IPv6 LSI usage and the prefix. > => Question: Do we need to include the type of the HIT in one of the > IPv6 LSI bits? If so, replace the last sentence and the table of the > text above by: IMHO, no. If we decide to get rid of the prefix, IMHO we should get rid of it altogether, and use all of the 128 bits of a (Type 1) HIT for hash. > IMHO the following changes are worth. If the WG agrees, I'll also > modify the DNS draft accordingly. Hence, opinions, others? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 08:08:07 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09610 for ; Mon, 18 Oct 2004 08:08:07 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8833B7305; Mon, 18 Oct 2004 06:58:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id B1A0872E2 for ; Mon, 18 Oct 2004 06:57:21 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id EB658212CAA for ; Mon, 18 Oct 2004 15:06:54 +0300 (EEST) Message-ID: <4173B17C.9@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base draft - 01-pre2 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 15:05:16 +0300 Date: Mon, 18 Oct 2004 15:05:16 +0300 Content-Transfer-Encoding: 7bit The 01-pre2 version of the base draft is available at http://hip4inter.net/drafts.php /petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 12:01:14 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27459 for ; Mon, 18 Oct 2004 12:01:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7BED172E8; Mon, 18 Oct 2004 10:51:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id EDE5072E6 for ; Mon, 18 Oct 2004 10:50:23 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA23145; Mon, 18 Oct 2004 10:59:48 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9IFxl317455; Mon, 18 Oct 2004 10:59:47 -0500 (CDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 08:59:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Digital Signature Algorithms Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Hipsec] Digital Signature Algorithms Thread-Index: AcS1BlTDwzBbl3RySyWqRh66iNM2JAAI8mgA From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" Cc: X-OriginalArrivalTime: 18 Oct 2004 15:59:47.0395 (UTC) FILETIME=[7DEA6130:01C4B52B] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 08:59:46 -0700 Date: Mon, 18 Oct 2004 08:59:46 -0700 Content-Transfer-Encoding: quoted-printable (4) sounds fine to me. Pekka's text on negotiation seems reasonable. After reading the excerpts that Julien had posted, (2) does not sound desirable. -Jeff > So, what people think? We have (at least) four alternatives: >=20 > 1) Stay at current: DSA mandatory >=20 > 2) Both DSA and RSA mandatory >=20 > 3) DSA mandatory, RSA SHOULD >=20 > 4) Change the mandatory to RSA >=20 > Opinions? >=20 > /petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 14:19:11 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08842 for ; Mon, 18 Oct 2004 14:19:11 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E088C72E6; Mon, 18 Oct 2004 13:09:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 2E37B72E2 for ; Mon, 18 Oct 2004 13:08:55 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 27778898A9; Mon, 18 Oct 2004 21:18:29 +0300 (EEST) Message-ID: <41740896.2080905@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" Cc: Petri Jokela , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 21:16:54 +0300 Date: Mon, 18 Oct 2004 21:16:54 +0300 Content-Transfer-Encoding: 7bit 4 is OK for me. Ahrenholz, Jeffrey M wrote: > (4) sounds fine to me. Pekka's text on negotiation seems reasonable. > After reading the excerpts that Julien had posted, (2) does not sound > desirable. > > -Jeff > > >>So, what people think? We have (at least) four alternatives: >> >>1) Stay at current: DSA mandatory >> >>2) Both DSA and RSA mandatory >> >>3) DSA mandatory, RSA SHOULD >> >>4) Change the mandatory to RSA >> >>Opinions? >> >>/petri > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 18 15:57:09 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17926 for ; Mon, 18 Oct 2004 15:57:09 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2D20B72E8; Mon, 18 Oct 2004 14:47:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by honor.icsalabs.com (Postfix) with ESMTP id B66A772E6 for ; Mon, 18 Oct 2004 14:46:47 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9IJuLNH002828 for ; Mon, 18 Oct 2004 13:56:21 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S00KW7Q1WCF@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Mon, 18 Oct 2004 13:56:21 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5S00I3LQ1UDL@mail.sun.net> for hipsec@honor.trusecure.com; Mon, 18 Oct 2004 13:56:20 -0600 (MDT) From: Julien Laganier Subject: Re: [Hipsec] Digital Signature Algorithms In-reply-to: <41740896.2080905@piuha.net> To: hipsec@honor.trusecure.com, jari.arkko@piuha.net Cc: "Ahrenholz, Jeffrey M" , Petri Jokela Message-id: <200410182157.48001.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> <41740896.2080905@piuha.net> Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 18 Oct 2004 21:57:47 +0200 Date: Mon, 18 Oct 2004 21:57:47 +0200 Content-Transfer-Encoding: 7BIT 4 is also OK for me. --julien On Monday 18 October 2004 20:16, Jari Arkko wrote: > 4 is OK for me. > > Ahrenholz, Jeffrey M wrote: > > (4) sounds fine to me. Pekka's text on negotiation seems > > reasonable. After reading the excerpts that Julien had posted, > > (2) does not sound desirable. > > > > -Jeff > > > >>So, what people think? We have (at least) four alternatives: > >> > >>1) Stay at current: DSA mandatory > >> > >>2) Both DSA and RSA mandatory > >> > >>3) DSA mandatory, RSA SHOULD > >> > >>4) Change the mandatory to RSA > >> > >>Opinions? > >> > >>/petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 07:47:14 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14129 for ; Tue, 19 Oct 2004 07:47:14 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0F7E172F2; Tue, 19 Oct 2004 06:37:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id 89C4F72E8 for ; Tue, 19 Oct 2004 06:36:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13897; Tue, 19 Oct 2004 07:46:05 -0400 (EDT) Message-Id: <200410191146.HAA13897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-arch-00.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 19 Oct 2004 07:46:05 -0400 Date: Tue, 19 Oct 2004 07:46:05 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Architecture Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-arch-00.txt Pages : 24 Date : 2004-10-18 This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18172758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172758.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 10:39:19 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01872 for ; Tue, 19 Oct 2004 10:39:17 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7477172F3; Tue, 19 Oct 2004 09:29:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from kyoto.netlab.nec.de (unknown [195.37.70.21]) by honor.icsalabs.com (Postfix) with ESMTP id C030972F2 for ; Tue, 19 Oct 2004 09:28:36 -0400 (EDT) Received: from [10.1.1.112] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 510D91BAC4D; Tue, 19 Oct 2004 16:38:07 +0200 (CEST) Message-ID: <417526CC.3070502@netlab.nec.de> From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: HIP , Pekka Nikander , David Ward , Robert Moskowitz Subject: Re: [Hipsec] WG LC on architecture draft References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> <4170D296.5060909@ericsson.com> In-Reply-To: <4170D296.5060909@ericsson.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040300000408010609010902" Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 19 Oct 2004 16:38:04 +0200 Date: Tue, 19 Oct 2004 16:38:04 +0200 This is a cryptographically signed message in MIME format. --------------ms040300000408010609010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gonzalo, Gonzalo Camarillo wrote: > > I would like to start the WGLC on the architecture draft. This WGLC will > finish on November 15th. The draft will appear shortly in the archives. > In the meantime, you can fetch it from: > > http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt ... > As the draft states, the purpose of the document is to document the > architectural reasoning as it was stated during the time of WG > formation, and therefore the draft is informational or almost historical > in nature. Hence, we ask people for clarifications, so that the content > is understandable and easy to comprehend. However, asking for new > argumentation (that did not exist back in fall 2003) or inclusion of new > text may not be appropriate. what are we shooting for here, standards track or other? Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms040300000408010609010902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMTkxNDM4MDRaMCMGCSqGSIb3DQEJBDEWBBSE8HxYbp7RMqgOSEhvF+l5Rzy+bzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQB7l/Txf+RYtrpjQPNMl50pi6yhTdhwLgafjjCn3Rzd+h6X 1E5D1h2xQUzi8yTjeaHHgmmjwp0bjKNfS9wVUvS2aTFr9Rjv8DkbW0iLb/Ebu2dA556IDDt8 uSRDLPRC21sm4DXx/FVYmzruIGYXxendLJSwJK1OoVaxsWJKSc6vrRE+94CL79KLDP0sxNvj uZWE40v92c3pNvtCMvaHLZw8ASGEougoOSKHT6vkkezGp/Em4nwdxpsvq2tUgJil/k/zTkNn 0o7osmK5OZGDteQcM00DsMtXCi5R09EB+B/1bP2olg9bYmkxCK9wjjn2LMMSsQg9SvmpqrqJ LOGuU+MpAAAAAAAA --------------ms040300000408010609010902-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 14:34:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26334 for ; Tue, 19 Oct 2004 14:34:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6BAA872F2; Tue, 19 Oct 2004 13:24:06 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id BE7FF72E0 for ; Tue, 19 Oct 2004 13:23:55 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 68434337B; Tue, 19 Oct 2004 21:33:37 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9JIXaU28719; Tue, 19 Oct 2004 21:33:36 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Cc: jari.arkko@piuha.net, Julien Laganier , Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms In-Reply-To: <4173A99D.6000303@nomadiclab.com> Message-ID: References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 19 Oct 2004 21:33:36 +0300 (EEST) Date: Tue, 19 Oct 2004 21:33:36 +0300 (EEST) On Mon, 18 Oct 2004, Petri Jokela wrote: > So, what people think? We have (at least) four alternatives: > > 1) Stay at current: DSA mandatory > > 2) Both DSA and RSA mandatory > > 3) DSA mandatory, RSA SHOULD > > 4) Change the mandatory to RSA > > Opinions? First, I was going to say that I have had already enough fun with debugging host identifiers, and that changing the RSA as the default in our implementation will be a pain in you-know-where, but then I came up with something more productive :) There are some performance measurements on DSA and RSA e.g. in http://www.eskimo.com/~weidai/benchmarks.html: DSA 1024 Signature 2.18 ms RSA 1024 Signature 4.75 ms => DSA signing is 2.2 faster DSA 1024 Verification 2.49 ms RSA 1024 Verification 0.18 ms => RSA verification is 13.9 faster The initiator does two verifications (on R1 and R2) and one signature (I2). Since the RSA verification is much more faster, and the initiator does two of them, the initiator would get the most benefit. Without precreated R1s, the responder does one verification (I2) and two signatures (R1, R2). As the RSA signature creation is slower than with DSA, the responder has to do more work when using RSA. Intuitively, changing the default algorithm from DSA to RSA favours more initiators. We can verify this with a quick-and-dirty calculation based on the number of the cryptographic operations, and the time required for the cryptographic operations: initiator(dsa): 2 * 2.49 ms + 2.18 ms = 7.16 ms responder(dsa): 2 * 2.18 ms + 2.49 ms = 6.85 ms ==== total = 14.01 ms initiator(rsa): 2 * 0.18 ms + 4.75 ms = 5.11 ms responder(rsa): 2 * 4.75 ms + 0.18 ms = 9.68 ms ==== total = 14.79 ms We can see the favouring of the initiator of the above figures quite clearly. It should be noticed that the total time spent for signing and verifying remains almost the same with both the RSA and DSA. Of course, the figures are greater when a real HIP base exchange is conserned, but still proportional to the figures above. With precreated R1s the figures are as follows (responder "skips" one signature): initiator(dsa): 2 * 2.49 ms + 2.18 ms = 7.16 ms responder(dsa): 2.18 ms + 2.49 ms = 4.67 ms ==== total = 11.83 initiator(rsa): 2 * 0.18 ms + 4.75 ms = 5.11 ms responder(rsa): 4.75 ms + 0.18 ms = 4.93 ms ==== total = 10.04 ms The total time is almost the same with RSA and DSA. The initiator is now half the faster using RSA and responder is only slightly slower. This is a much better situation than before from the viewpoint of the responder, but performance obtained by the initiator is still quite minimal. In the light of these performance estimation figures, I still prefer the DSA because it is more friendly for the responders (i.e. busy servers) in the case where R1s are created on-the-fly; this is also coherent with the current architecture in which the initiators should do more work than responders due to DoS protection. On the other hand, we may have the increase the cookie size artificially in the implementation when using RSA because the responder will be doing more work in such a case. As a result, the *total* amount of work done by both the initiator and responder increases, and it is a bad idea IMHO. We should also notice that DSA is about 60 times faster in the key generation than RSA. Maybe this is useful e.g. for hosts that create lots of anonymous identifiers on the fly. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 15:15:16 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01082 for ; Tue, 19 Oct 2004 15:15:16 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A6AFF72F4; Tue, 19 Oct 2004 14:05:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 4CEF072F3 for ; Tue, 19 Oct 2004 14:04:35 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4A04A89882; Tue, 19 Oct 2004 22:14:14 +0300 (EEST) Message-ID: <41756725.1060002@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miika Komu Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 19 Oct 2004 22:12:37 +0300 Date: Tue, 19 Oct 2004 22:12:37 +0300 Content-Transfer-Encoding: 7bit Hi Miika, and thanks for doing the math for the rest of us! Your numbers are indeed interesting, and somewhat surprising, taking into account the difference between initiators and responders. Just one comment: > In the light of these performance estimation figures, I still prefer the > DSA because it is more friendly for the responders (i.e. busy servers) in > the case where R1s are created on-the-fly; this is also coherent with the I think the precreated R1 case is the default assumption, and should be at any rate if performance is a concern. So I'd like us to consider that situation as our primary problem. If I understood your numbers right, there was a minor increase dsa->rsa for responders in this case and a bigger decrease dsa->rsa for initiators. Based on this, RSA appears better from my point of view, though certainly not quite as much as I initially thought. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 16:27:16 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09790 for ; Tue, 19 Oct 2004 16:27:16 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 0136672F4; Tue, 19 Oct 2004 15:17:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from enso.acheron.indranet.co.nz (ns.indranet.co.nz [210.54.239.210]) by honor.icsalabs.com (Postfix) with ESMTP id 766AB72F2 for ; Tue, 19 Oct 2004 15:16:30 -0400 (EDT) Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id JAA30561; Wed, 20 Oct 2004 09:25:39 +1300 From: Andrew McGregor To: jari.arkko@piuha.net, Miika Komu Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms Message-ID: In-Reply-To: <41756725.1060002@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 09:25:31 +1300 Date: Wed, 20 Oct 2004 09:25:31 +1300 Content-Transfer-Encoding: 7bit If I recall correctly, Miika has done the same math as Bob did when he was designing this. In other words, that DSA is lighter on the responder is the reason for DSA being the default at present. Bob's opinion was, I seem to recall, that the difference wasn't large but did slightly favour DSA. Andrew --On Tuesday, October 19, 2004 10:12 PM +0300 Jari Arkko wrote: > Hi Miika, and thanks for doing the math for > the rest of us! Your numbers are indeed interesting, > and somewhat surprising, taking into account the > difference between initiators and responders. > > Just one comment: > >> In the light of these performance estimation figures, I still prefer the >> DSA because it is more friendly for the responders (i.e. busy servers) in >> the case where R1s are created on-the-fly; this is also coherent with the > > I think the precreated R1 case is the default assumption, > and should be at any rate if performance is a concern. > So I'd like us to consider that situation as our primary > problem. If I understood your numbers right, there was a > minor increase dsa->rsa for responders in this case and > a bigger decrease dsa->rsa for initiators. Based on this, > RSA appears better from my point of view, though certainly > not quite as much as I initially thought. > > --Jari > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 19 23:49:17 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22554 for ; Tue, 19 Oct 2004 23:49:17 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AEC8472F2; Tue, 19 Oct 2004 22:39:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 8E4D772E8 for ; Tue, 19 Oct 2004 22:38:48 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 10984220003; Wed, 20 Oct 2004 06:48:25 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 91FF78; Wed, 20 Oct 2004 06:48:25 +0300 (EEST) In-Reply-To: <417526CC.3070502@netlab.nec.de> References: NEC Network Laboratories <417526CC.3070502@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Gonzalo Camarillo (JO/LMF)" , David Ward , HIP , Robert Moskowitz From: Pekka Nikander Subject: Re: [Hipsec] WG LC on architecture draft To: Lars Eggert X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 19 Oct 2004 22:32:45 +0300 Date: Tue, 19 Oct 2004 22:32:45 +0300 Content-Transfer-Encoding: 7bit > what are we shooting for here, standards track or other? Informative, or if not even that is possible, Historical. AFAIK, nothing from HIP WG is currently chartered for Standards Track. The base spec etc. are chartered for Experimental, but with standards track quality; the reason for Experimental being that we don't understand the consequences of id/loc split. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 09:03:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00491 for ; Wed, 20 Oct 2004 09:03:24 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5279C72F5; Wed, 20 Oct 2004 07:53:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by honor.icsalabs.com (Postfix) with ESMTP id 10C0E72F2 for ; Wed, 20 Oct 2004 07:52:45 -0400 (EDT) Received: from [10.1.1.112] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5D9F31BAC4D; Wed, 20 Oct 2004 15:02:29 +0200 (CEST) Message-ID: <417661E2.90003@netlab.nec.de> From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: HIP , Pekka Nikander , David Ward , Robert Moskowitz Subject: Re: [Hipsec] WG LC on architecture draft References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> <4170D296.5060909@ericsson.com> In-Reply-To: <4170D296.5060909@ericsson.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060805050200000908080404" Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 15:02:26 +0200 Date: Wed, 20 Oct 2004 15:02:26 +0200 This is a cryptographically signed message in MIME format. --------------ms060805050200000908080404 Content-Type: multipart/mixed; boundary="------------050906060906000206070309" This is a multi-part message in MIME format. --------------050906060906000206070309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > I would like to start the WGLC on the architecture draft. This WGLC will > finish on November 15th. The draft will appear shortly in the archives. ... > Please, send you comments to the authors and to the mailing list. I have some comments and some editing nits. I'll summarize the comments below, the attached diff has both them and the nits. Section 2, 2nd paragraph: "A Host Identity is assigned to each host. Each host will have at least one Host Identity..." So does it get a single one, or at least one? I think the latter, and would just remove the first sentence. Section 2, 2nd paragraph: "which can either be public (e.g. published in DNS), or unpublished." If one is "public", shouldn't we call the other kind "private" instead of "unpublished?" Section 2, 4th paragraph: A sentence on why we didn't go with IKE may be useful. Page 8: "Sometimes the names may contain a delegation component." Formatting is weird. Is this a new bullet or belongs to the previous one? Section 8, last paragraph: Uses upper-case "MAY" without referring to RFC 2119. We should probably change all RFC 2119 terms to lower case for this document. Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs and the corresponding IPsec SPIs to an IP address." Not sure what this sentence is supposed to mean. All section headings: Use consistent capitalization througout the document. -- Lars Eggert NEC Network Laboratories --------------050906060906000206070309 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="draft-ietf-hip-arch-00-diff.txt" Content-Disposition: inline; filename="draft-ietf-hip-arch-00-diff.txt" Content-Transfer-Encoding: 7bit --- draft-ietf-hip-arch-00.txt Wed Oct 20 15:00:26 2004 +++ draft-ietf-hip-arch-00-le.txt Wed Oct 20 14:59:55 2004 @@ -40,15 +40,15 @@ Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2004.) Abstract This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the - Host Identity Protocol, between the internetworking and transport - layers. Herein are presented the basics of the current namespaces, - strengths and weaknesses, and how a new namespace will add + Host Identity Protocol, between the network and transport + layers. It describes the Internet's current namespaces, their + strengths and weaknesses, and how the new Host Identity namespace integrates with them. @@ -57,8 +57,7 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - completeness to them. The roles of this new namespace in the - protocols are defined. The memo describes the thinking of the + The memo describes the thinking of the authors as of Fall 2003. Table of Contents @@ -118,28 +117,27 @@ The purpose of this memo is to provide a stable reference point in the development of the Host Identity Protocol architecture. This memo describes the thinking of the authors as of Fall 2003; their - thinking may have evolved since then. In occasions, this memo may be + thinking may have changed since then. Occasionally, this memo may be confusing or self-contradicting. That is (partially) intentional, and reflects the snapshot nature of this memo. 2. Introduction - The Internet has created two important global namespaces: Internet + The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These - two namespaces have a set of features and abstractions that have - powered the Internet to what it is today. They also have a number of - weaknesses. Basically, since they are all we have, we try and do too + two namespaces have sets of features and abstractions that have + enabled the growth of the Internet to this day. They also have a number of + weaknesses. Basically, because they are all we have, we try to do too much with them. Semantic overloading and functionality extensions - have greatly complicated these namespaces. + have greatly complicated interactions with or changes to these namespaces. The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. The Host Identity namespace consists of - Host Identifiers (HI). A Host Identifier is cryptographic in its - nature; it is the public key of an asymmetric key-pair. A Host - Identity is assigned to each host. Each host will have at least one - Host Identity and a corresponding Host Identifier, which can either - be public (e.g. published in DNS), or unpublished. Client systems - will tend to have both public and unpublished Identities. + Host Identifiers (HI.) A Host Identifier is cryptographic; + it is the public key of an asymmetric key-pair. Each host will have at least one + Host Identity and at least one corresponding Host Identifier, which can either + be public (e.g., published in DNS), or private. Client systems + will tend to have both public and private Identities. There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that @@ -284,10 +282,10 @@ 4. Background The Internet is built from three principal components: computing - platforms (end-points), packet transport (i.e. internetworking) - infrastructure, and services (applications). The Internet exists to + platforms (end-points), packet transport (i.e., internetworking) + infrastructure, and services (applications.) The Internet exists to service two principal components: people and robotic services - (silicon based people, if you will). All these components need to be + (silicon based people, if you will.) All these components need to be named in order to interact in a scalable manner. Here we concentrate on naming computing platforms and packet transport elements. @@ -298,7 +296,7 @@ IP numbers are a confounding of two namespaces, the names of a host's networking interfaces and the names of the locations ('confounding' is a term used in statistics to discuss metrics that are merged into - one with a gain in indexing, but a loss in informational value). The + one with a gain in indexing, but a loss in informational value.) The names of locations should be understood as denoting routing direction vectors, i.e., information that is used to deliver packets to their destinations. @@ -345,7 +343,7 @@ This could support rapid readdressing of the internetworking layer because of mobility, rehoming, or renumbering. - If the namespace for computing platforms is based on public key + If the namespace for computing platforms is based on public-key cryptography, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity. @@ -359,7 +357,7 @@ o The namespace should fully decouple the internetworking layer from the higher layers. The names should replace all occurrences of IP - addresses within applications (like in the TCB). This may require + addresses within applications (like in the TCB.) This may require changes to the current APIs. In the long run, it is probable that some new APIs are needed. @@ -369,7 +367,7 @@ o The names should have a fixed length representation, for easy inclusion in datagram headers and existing programming interfaces - (e.g the TCB). + (e.g the TCB.) o Using the namespace should be affordable when used in protocols. This is primarily a packet size issue. There is also a @@ -409,7 +407,7 @@ In this document, a new namespace approaching these ideas is called the Host Identity namespace. Using Host Identities requires its own protocol layer, the Host Identity Protocol, between the - internetworking and transport layers. The names are based on public + internetworking and transport layers. The names are based on public- key cryptography to supply authentication services. Properly designed, it can deliver all of the above stated requirements. @@ -430,11 +428,11 @@ unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As documented in the Host Identity Protocol - specification [4], a public key based HI can authenticate the HIP - packets and protect them for man-in-the-middle attacks. Since + specification [4], a public-key-based HI can authenticate the HIP + packets and protect them for man-in-the-middle attacks. Because authenticated datagrams are mandatory to provide much of HIP's denial-of-service protection, the Diffie-Hellman exchange in HIP has - to be authenticated. Thus, only public key HI and authenticated HIP + to be authenticated. Thus, only public-key HI and authenticated HIP messages are supported in practice. In this document, the non-cryptographic forms of HI and HIP are presented to complete the theory of HI, but they should not be implemented as they could @@ -462,7 +460,7 @@ The only completely defined structure of the Host Identity is that of a public/private key pair. In this case, the Host Identity is referred to by its public component, the public key. Thus, the name - representing a Host Identity in the Host Identity namespace, i.e. + representing a Host Identity in the Host Identity namespace, i.e., the Host Identifier, is the public key. In a way, the possession of the private key defines the Identity itself. If the private key is possessed by more than one node, the Identity can be considered to be @@ -491,12 +489,12 @@ The public Host Identifiers should be stored in DNS; the unpublished Host Identifiers should not be stored anywhere (besides the - communicating hosts themselves). The (public) HI is stored in a new + communicating hosts themselves.) The (public) HI is stored in a new RR type, to be defined. This RR type is likely to be quite similar to the IPSECKEY RR [5]. Alternatively, or in addition to storing Host Identifiers in the DNS, - they may be stored in various kinds of Public Key Infrastructure + they may be stored in various kinds of public-key infrastructure @@ -505,7 +503,7 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - (PKI). Such a practice may allow them to be used for purposes other + (PKI.) Such a practice may allow them to be used for purposes other than pure host identification. 5.3 Host Identity Tag (HIT) @@ -590,14 +588,14 @@ 6.1 Transport associations and end-points - Architecturally, HIP provides for a different binding of transport - layer protocols. That is, the transport layer associations, i.e., + Architecturally, HIP provides for a different binding of transport- + layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but to Host Identities. It is possible that a single physical computer hosts several logical end-points. With HIP, each of these end-points would have a distinct - Host Identity. Furthermore, since the transport associations are + Host Identity. Furthermore, because the transport associations are bound to Host Identities, HIP provides for process migration and clustered servers. That is, if a Host Identity is moved from one physical computer to another, it is also possible to simultaneously @@ -621,7 +619,7 @@ HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities (through actually - either the HIT or LSI). Consequently, HIP can provide for a degree + either the HIT or LSI.) Consequently, HIP can provide for a degree of internetworking mobility and multi-homing at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if its IP address @@ -643,7 +641,7 @@ that the mobile node is reachable through these addresses. This is especially helpful for those situations where the peer node is sending data periodically to the mobile node (that is re-starting a - connection after the initial connection). + connection after the initial connection.) 7.1 Rendezvous mechanism @@ -655,7 +653,7 @@ new static infrastructure to facilitate rendezvous between HIP nodes. The mobile node keeps the rendezvous infrastructure continuously - updated with its current IP address(es). The mobile nodes must trust + updated with its current IP address(es.) The mobile nodes must trust the rendezvous mechanism to properly maintain their HIT and IP address mappings. @@ -678,7 +676,7 @@ 7.2 Protection against Flooding Attacks - While the idea of informing about address changes by simply sending + Although the idea of informing about address changes by simply sending packets with a new source address appears appealing, it is not secure enough. That is, even if HIP does not rely on the source address for anything (once the base exchange has been completed), it appears to @@ -717,7 +715,7 @@ enable ESP in an end-to-end manner. This is implemented in a way that can span addressing realms. - While it would be possible, at least in theory, to use some existing + Although it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2 together with Host Identifiers, to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few @@ -729,16 +727,15 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - architectural reasons. First, IKE (and IKEv2) were not design with - middle boxes in mind. As adding a new naming layer allows one to + architectural reasons. First, IKE (and IKEv2) were not designed with + middleboxes in mind. Because adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is - very important that the HIP protocols are friendly towards any middle - boxes. + very important that the HIP protocols can traverse any middleboxes. Second, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy - granularity over other Key Management Protocols, such as IKE and + granularity over other key-management protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, @@ -748,24 +745,24 @@ may provide for more granularity and creation of several ESP SAs between a pair of HITs. - Since HIP is designed for host usage, not for gateways or so called - Bump-in-the-Wire (BITW) implementations, only ESP transport mode is + Because HIP is designed for host usage, not for gateways or so called + bump-in-the-wire (BITW) implementations, only ESP transport mode is supported. An ESP SA pair is indexed by the SPIs and the two HITs - (both HITs since a system can have more than one HIT). The SAs need + (both HITs, because a system can have more than one HIT.) The SAs need not to be bound to IP addresses; all internal control of the SA is by the HITs. Thus, a host can easily change its address using Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs. - Since the transports are bound to the SA (via an LSI or a HIT), any + Because the transports are bound to the SA (via an LSI or a HIT), any active transport is also maintained. Thus, real world conditions like loss of a PPP connection and its re-establishment or a mobile handover will not require a HIP negotiation or disruption of - transport services. [12] + transport services [12]. - Since HIP does not negotiate any SA lifetimes, all lifetimes are + Because HIP does not negotiate any SA lifetimes, all lifetimes are local policy. The only lifetimes a HIP implementation MUST support are sequence number rollover (for replay protection), and SA - timeout[4]. An SA times out if no packets are received using that - SA. Implementations MAY support lifetimes for the various ESP + timeout [4]. An SA times out if no packets are received using that + SA. Implementations may support lifetimes for the various ESP transforms. 9. HIP and NATs @@ -785,35 +782,35 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - In a network environment where the identification is based on the IP + In a network environment where identification is based on IP addresses, identifying the communicating nodes is difficult when NAT - is used. With HIP, the transport layer end-points are bound to the + is used. With HIP, the transport-layer end-points are bound to Host Identities. Thus, a connection between two hosts can traverse many addressing realm boundaries. The IP addresses are used only for - routing purposes; the IP addresses may be changed freely during + routing purposes; IP addresses may be changed freely during packet traversal. - For a HIP based flow, a HIP-aware NAT or NAT-PT system tracks the + For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs and the corresponding IPsec SPIs to an IP address. Many HITs can map to a single IP address on a NAT, simplifying connections on address poor NAT interfaces. The NAT can gain much of its knowledge from the HIP packets themselves; however, some NAT configuration may be necessary. - The NAT systems cannot touch the datagrams within the IPsec envelope, - thus application specific address translation must be done in the end + NAT systems cannot touch datagrams within the IPsec envelope, + thus application-specific address translation must be done in the end systems. HIP provides for 'Distributed NAT', and uses the HIT or the - LSI as a place holder for embedded IP addresses. + LSI as a placeholder for embedded IP addresses. -9.1 HIP and TCP Checksum +9.1 HIP and TCP Checksums - There is no way for a host to know if any of the IP addresses in the + There is no way for a host to know if any of the IP addresses in an IP header are the addresses used to calculate the TCP checksum. That is, it is not feasible to calculate the TCP checksum using the actual IP addresses in the pseudo header; the addresses received in the incoming packet are not necessarily the same as they were on the - sending host. Furthermore, it is not possible to recompute the upper - layer checksums in the NAT/NAT-PT system, since the traffic is IPsec + sending host. Furthermore, it is not possible to recompute the upper- + layer checksums in the NAT/NAT-PT system, because the traffic is IPsec protected. Consequently, the TCP and UDP checksums are calculated using the HITs in the place of the IP addresses in the pseudo header. Furthermore, only the IPv6 pseudo header format is used. This @@ -821,16 +818,16 @@ 10. Multicast - Back in fall 2003, there was little if any concrete thoughts about - how HIP might affect IP or application layer multi-cast. + Back in the fall of 2003, there were little if any concrete thoughts about + how HIP might affect IP or application-layer multicast. 11. HIP Policies - There are a number of variables that will influence the HIP exchanges + There are a number of variables that influence the HIP exchanges that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS and an unpublished one for anonymous usage. Although unpublished HIs will be rarely used as - responder HIs, they are likely be common for initiators. Support for + responder HIs, they are likely common for initiators. Support for multiple HIs is recommended. @@ -852,7 +849,7 @@ 12. Benefits of HIP - In the beginning, the network layer protocol (i.e. IP) had the + In the beginning, the network layer protocol (i.e., IP) had the following four "classic" invariants: o Non-mutable: The address sent is the address received. @@ -869,26 +866,26 @@ Actually, the fourth can be inferred from 1 and 3, but it is worth mentioning for reasons that will be obvious soon if not already. - In the current "post-classic" world, we are trying intentionally to + In the current "post-classic" world, we are intentionally trying to get rid of the second invariant (both for mobility and for multi-homing), and we have been forced to give up the first and the - fourth. Realm Specific IP [3] is an attempt to reinstate the fourth + fourth. Realm-Specific IP [3] is an attempt to reinstate the fourth invariant without the first invariant. IPv6 is an attempt to reinstate the first invariant. - Few systems on the Internet have DNS names that are meaningful to - them. That is, if they have a Fully Qualified Domain Name (FQDN), - that typically belongs to a NAT device or a dial-up server, and does + Few systems on the Internet have DNS names that are meaningful. + That is, if they have a Fully Qualified Domain Name (FQDN), + that name typically belongs to a NAT device or a dial-up server, and does not really identify the system itself but its current connectivity. - FQDN names (and their extensions as email names) are Application - Layer names; more frequently naming services than a particular - system. This is why many systems on the internet are not registered - in DNS; they do not have services of interest to other Internet + FQDNs (and their extensions as email names) are application- + layer names; more frequently naming services than a particular + system. This is why many systems on the Internet are not registered + in the DNS; they do not have services of interest to other Internet hosts. DNS names are references to IP addresses. This only demonstrates the interrelationship of the networking and application layers. DNS, as - the Internet's only deployed, distributed, database is also the + the Internet's only deployed, distributed database is also the @@ -905,14 +902,14 @@ The Host Identity (HI) namespace fills an important gap between the IP and DNS namespaces. An interesting thing about the HI is that it - actually allows one to give-up all but the 3rd Network Layer + actually allows one to give up all but the 3rd network-layer invariant. That is to say, as long as the source and destination - addresses in the network layer protocol are reversible, then things + addresses in the network-layer protocol are reversible, then things work ok because HIP takes care of host identification, and reversibility allows one to get a packet back to one's partner host. - You don't care if the network layer address changes in transit - (mutable) and you don't care what network layer address the partner - is using (non-omniscient). + You do not care if the network-layer address changes in transit + (mutable) and you do not care what network-layer address the partner + is using (non-omniscient.) 12.1 HIP's Answers to NSRG questions @@ -943,7 +940,7 @@ HIP provides both stable and temporary Host Identifiers. Stable HIs are typically long lived, with a lifetime of years or more. The lifetime of temporary HIs depends on how long - the upper layer connections and applications need them, and + the upper-layer connections and applications need them, and can range from a few seconds to years. @@ -962,7 +959,7 @@ The Host Identifiers may be used directly or indirectly (in the form of HITs or LSIs) by applications when they access network services. Additionally, the Host Identifiers, as - public keys, are used in the built in key agreement protocol, + public keys, are used in the built in key-agreement protocol, called the HIP base exchange, to authenticate the hosts to each other. @@ -986,8 +983,8 @@ HIP reduces dependency on IP addresses, making the so called address ownership [11] problems easier to solve. In practice, HIP provides security for end-host mobility and multi-homing. - Furthermore, since HIP Host Identifiers are public keys, - standard public key certificate infrastructures can be applied + Furthermore, because Host Identifiers are public keys, + standard public-key certificate infrastructures can be applied on the top of HIP. 9. What would the resolution mechanisms be, or what characteristics @@ -998,7 +995,7 @@ However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be - based on the ideas of Distributed Hash Tables, but would + based on the ideas of distributed hash tables, but would require significant new development and deployment. @@ -1019,7 +1016,7 @@ that potentially could be more damaging to a host's ability to conduct business as usual. - Resource exhausting Denial-of-service attacks take advantage of the + Resource exhausting denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP allows a responder to increase the cost of the start of state on the initiator and makes an @@ -1036,7 +1033,7 @@ method to force the start of HIP is expensive on either host, the attacker need only spoof a TCP SYN. This would put both systems into the expensive operations. HIP avoids this attack by having the - responder send a simple HIP packet that it can pre-build. Since this + responder send a simple HIP packet that it can pre-build. Because this packet is fixed and easily replayed, the initiator only reacts to it if it has just started a connection to the responder. @@ -1048,14 +1045,14 @@ initiator can use this to authenticate the signed HIP packets. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it and validate the signed HIP packets. - However, since an initiator may choose to use an unpublished HI, it + However, because an initiator may choose to use an unpublished HI, it knowingly risks a MitM attack. The responder may choose not to accept a HIP exchange with an initiator using an unknown HI. In HIP, the Security Association for IPsec is indexed by the SPI; the source address is always ignored, and the destination address may be - ignored as well. Therefore, HIP enabled IPsec Encapsulated Security - Payload (ESP) is IP address independent. This might seem to make it + ignored as well. Therefore, HIP enabled IPsec encapsulated security + payload (ESP) is IP address independent. This might seem to make it easier for an attacker, but ESP with replay protection is already as @@ -1068,7 +1065,7 @@ well protected as possible, and the removal of the IP address as a check should not increase the exposure of IPsec ESP to DoS attacks. - Since not all hosts will ever support HIP, ICMPv4 'Destination + Because not all hosts will ever support HIP, ICMPv4 'Destination Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem, Unrecognized Next Header' messages are to be expected and present a DoS attack. Against an initiator, the attack would look like the @@ -1088,7 +1085,7 @@ the defense against this attack is for the initiator to wait a reasonable time period to get a valid HIP packet. If one does not come, then the initiator has to assume that the ICMP message is - valid. Since this is the only point in the HIP base exchange where + valid. Because this is the only point in the HIP base exchange where this ICMP message is appropriate, it can be ignored at any other point in the exchange. @@ -1098,20 +1095,20 @@ use HITs to control egress and ingress to networks, with an assurance level difficult to achieve today. As discussed above in Section 8, once a HIP session has been established, the SPI value in an IPsec - packet may be used as an index, indicating the HITs. In practise, - the firewalls can inspect the HIP packets to learn of the bindings + packet may be used as an index, indicating the HITs. In practice, + firewalls can inspect HIP packets to learn of bindings between HITs, SPI values, and IP addresses. They can even explicitly control IPsec usage, dynamically opening IPsec ESP only for specific - SPI values and IP addresses. The signatures in the HIP packets allow - a capable firewall to make sure that the HIP exchange is indeed + SPI values and IP addresses. The signatures in HIP packets allow + a capable firewall to ensure that the HIP exchange is indeed happening between two known hosts. This may increase firewall security. There has been considerable bad experience with distributed ACLs that - contain public key related material, for example, with SSH. If the - owner of the key needs to revoke it for any reason, the task of + contain public-key-related material, for example, with SSH. If the + owner of a key needs to revoke it for any reason, the task of finding all locations where the key is held in an ACL may be - impossible. If the reason for the revocation is due to private key + impossible. If the reason for the revocation is due to private-key theft, this could be a serious issue. @@ -1129,10 +1126,10 @@ HIP-aware NATs, however, are transparent to the HIP aware systems by design. Thus, the host may find it difficult to notify any NAT that - is using a HIT in an ACL. Since most systems will know of the NATs + is using a HIT in an ACL. Because most systems will know of the NATs for their network, there should be a process by which they can notify these NATs of the change of the HIT. This is mandatory for systems - that function as responders behind a NAT. In a similar vein, if a + that function as responders behind a NAT. Similarly, if a host is notified of a change in a HIT of an initiator, it should notify its NAT of the change. In this manner, NATs will get updated with the HIT change. @@ -1141,21 +1138,21 @@ The definition of the Host Identifier states that the HI need not be a public key. It implies that the HI could be any value; for example - an FQDN. This document does not describe how to support such a + a FQDN. This document does not describe how to support such a non-cryptographic HI. A non-cryptographic HI would still offer the - services of the HIT or LSI for NAT traversal. It would be possible - carry the HITs in HIP packets that had neither privacy nor - authentication. Since such a mode would offer so little additional - functionality for so much addition to the IP kernel, it has not been - defined. Given how little public key cryptography HIP requires, HIP - should only be implemented using public key Host Identities. + services of the HIT or LSI for NAT traversal. It would be possible to + carry HITs in HIP packets that have neither privacy nor + authentication. Because such a mode would offer so little additional + functionality for the complexities it adds to an IP kernel, it has not been + defined. Given how little public-key cryptography HIP requires, HIP + should only be implemented using public-key Host Identities. If it is desirable to use HIP in a low security situation where - public key computations are considered expensive, HIP can be used + public-key computations are considered expensive, HIP can be used with very short Diffie-Hellman and Host Identity keys. Such use - makes the participating hosts vulnerable to MitM and connection + makes the participating hosts vulnerable to MitM and connection- hijacking attacks. However, it does not cause flooding dangers, - since the address check mechanism relies on the routing system and + because the address check mechanism relies on the routing system and not on cryptographic strength. 14. Acknowledgments @@ -1327,7 +1324,7 @@ Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2004.) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. --------------050906060906000206070309-- --------------ms060805050200000908080404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMjAxMzAyMjZaMCMGCSqGSIb3DQEJBDEWBBRXbHmECVQhLcDjaNr/XdJFsgKy5TBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQCsUWhcysG5aZYBxzFtwj5qD4g9JXeZfbRb3jKQ6Z+COSa4 u3qajfBJnYsf0C5xmEHDMbElo6B12wDFaN9Qd6gSVBMEgKejYAm7o6Joyb2rAMASBHj5FouU RuuZgYDOFOGcz8WeNOyUTeIFWTTXFb69yId+cJIjD0LYoOH+fzXbJAAB0JDt97gkMARwMc9l 8J0nP991b4KrHMFXYz8Vbw6FsCwn4xJJKneZ+wvJ5Q4dofMQU5rMuXNIr7YW2nd4i4Ct6JNy znBBz3N0b3GxzK/NC1ISO+VwF2DyGzFVOjOWH4DXNyQrihlaKsvAeOycr8TMNf2YLtvqRpka dlXSQA3NAAAAAAAA --------------ms060805050200000908080404-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 10:28:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08425 for ; Wed, 20 Oct 2004 10:28:20 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 866D37303; Wed, 20 Oct 2004 09:18:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id EA8847303 for ; Wed, 20 Oct 2004 09:17:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08010; Wed, 20 Oct 2004 10:26:44 -0400 (EDT) Message-Id: <200410201426.KAA08010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-00.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 10:26:44 -0400 Date: Wed, 20 Oct 2004 10:26:44 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multi-Homing with Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-mm-00.txt Pages : 34 Date : 2004-10-19 This document specifies basic end-host mobility and multi-homing mechanisms for the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 10:28:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08472 for ; Wed, 20 Oct 2004 10:28:28 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C139F7307; Wed, 20 Oct 2004 09:18:08 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id 7125072F5 for ; Wed, 20 Oct 2004 09:17:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08042; Wed, 20 Oct 2004 10:26:55 -0400 (EDT) Message-Id: <200410201426.KAA08042@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-00.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 10:26:54 -0400 Date: Wed, 20 Oct 2004 10:26:54 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-00.txt Pages : 24 Date : 2004-10-19 This document specifies two new resource records for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These records allow a HIP node to store in the DNS its Host Identity (its public key), Host Identity Tag (a truncated hash of its public key), and Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104715.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 10:28:43 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08566 for ; Wed, 20 Oct 2004 10:28:43 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7E5D6730C; Wed, 20 Oct 2004 09:18:12 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id 0DD2B72F5 for ; Wed, 20 Oct 2004 09:17:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08093; Wed, 20 Oct 2004 10:27:04 -0400 (EDT) Message-Id: <200410201427.KAA08093@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-00.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 10:27:04 -0400 Date: Wed, 20 Oct 2004 10:27:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extensions Author(s) : J. Laganier, L. Eggert Filename : draft-ietf-hip-rvs-00.txt Pages : 33 Date : 2004-10-19 This document discusses rendezvous extensions for the Host Identity Protocol (HIP). Rendezvous mechanisms extend HIP for communication with HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. The first part of his document motivates the need for rendezvous mechanisms; the second part describes the protocol extensions in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-rvs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-rvs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-rvs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-rvs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104720.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 11:13:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13407 for ; Wed, 20 Oct 2004 11:13:19 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 51F6F72F5; Wed, 20 Oct 2004 10:03:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 0029972F2 for ; Wed, 20 Oct 2004 10:02:37 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 2EBBD220003; Wed, 20 Oct 2004 18:12:24 +0300 (EEST) Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2CEE18; Wed, 20 Oct 2004 18:12:25 +0300 (EEST) In-Reply-To: <417661E2.90003@netlab.nec.de> References: NEC Network Laboratories <417661E2.90003@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Gonzalo Camarillo (JO/LMF)" , David Ward , HIP , Robert Moskowitz From: Pekka Nikander Subject: Re: [Hipsec] WG LC on architecture draft To: Lars Eggert X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 18:12:27 +0300 Date: Wed, 20 Oct 2004 18:12:27 +0300 Content-Transfer-Encoding: 7bit > I have some comments and some editing nits. I'll summarize the comments > below, the attached diff has both them and the nits. Thanks. I'll return to the nits later. > Section 2, 2nd paragraph: "A Host Identity is assigned to each host. > Each host will have at least one Host Identity..." So does it get a > single one, or at least one? I think the latter, and would just remove > the first sentence. As far as I can understand what Bob has meant, the first sentence says that the HI->host direction of the relationship is unary and non-zero, and the second says that the HI<-host direction is not unary but there may be multiple IDs per host. IMHO, both are needed. OTOH, the sentences could be certainly reformulated, if people find them confusing. Any suggestions for rewording? > Section 2, 2nd paragraph: "which can either be public (e.g. published > in > DNS), or unpublished." If one is "public", shouldn't we call the other > kind "private" instead of "unpublished?" The term that we user before was "anonymous", but some people felt that it was inappropriate. "private" was also thought to be bad, since an unpublished HI may not be secret, and "private" in that sense. As a compromise, I chose "unpublished", which I agree to be bad, but maybe less bad than the others. Anyway, I don't that much care about what term we use, as long as we are consistent. Any suggestions or opinions? > Section 2, 4th paragraph: A sentence on why we didn't go with IKE may > be > useful. Would a reference to Section 8 do? > Page 8: "Sometimes the names may contain a delegation component." > Formatting is weird. Is this a new bullet or belongs to the previous > one? It belongs to a previous one. Any suggestions on how to change the formatting? > Section 8, last paragraph: Uses upper-case "MAY" without referring to > RFC 2119. We should probably change all RFC 2119 terms to lower case > for > this document. Ok, that is an oversight by me. I will fix it. I didn't find anything else but one MUST. Did I miss something? > Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or > NAT-PT system tracks the mapping of HITs and the corresponding IPsec > SPIs to an IP address." Not sure what this sentence is supposed to > mean. I'll take this up separately as this may need some discussion. (Later, now I must go.) > All section headings: Use consistent capitalization througout the > document. Ok, I will fix that. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 12:27:33 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20874 for ; Wed, 20 Oct 2004 12:27:30 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 331E272F5; Wed, 20 Oct 2004 11:17:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by honor.icsalabs.com (Postfix) with ESMTP id EAF9672F2 for ; Wed, 20 Oct 2004 11:16:45 -0400 (EDT) Received: from [10.1.1.112] (dummy.netlab.nec.de [195.37.70.40]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CBBA61BAC4D; Wed, 20 Oct 2004 18:26:24 +0200 (CEST) Message-ID: <417691AD.2090505@netlab.nec.de> From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20041019) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: "Gonzalo Camarillo (JO/LMF)" , David Ward , HIP , Robert Moskowitz Subject: Re: [Hipsec] WG LC on architecture draft References: NEC Network Laboratories <417661E2.90003@netlab.nec.de> <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> In-Reply-To: <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080900090701080707040800" Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 18:26:21 +0200 Date: Wed, 20 Oct 2004 18:26:21 +0200 This is a cryptographically signed message in MIME format. --------------ms080900090701080707040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> I have some comments and some editing nits. I'll summarize the comments >> below, the attached diff has both them and the nits. > > > Thanks. I'll return to the nits later. > >> Section 2, 2nd paragraph: "A Host Identity is assigned to each host. >> Each host will have at least one Host Identity..." So does it get a >> single one, or at least one? I think the latter, and would just remove >> the first sentence. > > As far as I can understand what Bob has meant, the first sentence > says that the HI->host direction of the relationship is unary and > non-zero, and the second says that the HI<-host direction is not unary > but there may be multiple IDs per host. IMHO, both are needed. OTOH, > the sentences could be certainly reformulated, if people find > them confusing. Any suggestions for rewording? How about: "Each host will have at least one host identity, but may have multiple ones. Each host identity uniquely identifies a single host, i.e., no two hosts have the same host identity." >> Section 2, 2nd paragraph: "which can either be public (e.g. published in >> DNS), or unpublished." If one is "public", shouldn't we call the other >> kind "private" instead of "unpublished?" > > The term that we user before was "anonymous", but some people felt > that it was inappropriate. "private" was also thought to be bad, > since an unpublished HI may not be secret, and "private" in that sense. > As a compromise, I chose "unpublished", which I agree to be bad, > but maybe less bad than the others. > > Anyway, I don't that much care about what term we use, as long as > we are consistent. Any suggestions or opinions? Didn't know these had been discussed. The comment was based on the observation that "unpublished" isn't the natural opposite of "public." Anyhow, I don't think this is really too important. >> Section 2, 4th paragraph: A sentence on why we didn't go with IKE may be >> useful. > > Would a reference to Section 8 do? Yup, saw that there is more on that later. >> Page 8: "Sometimes the names may contain a delegation component." >> Formatting is weird. Is this a new bullet or belongs to the previous >> one? > > It belongs to a previous one. Any suggestions on how to change the > formatting? Move it under the previous bullet then? Currently it looks like this, which is probably an xml2rfc issue: o It must be possible to create names locally. This can provide anonymity at the cost of making resolvability very difficult. Sometimes the names may contain a delegation component. This is the cost of resolvability. >> Section 8, last paragraph: Uses upper-case "MAY" without referring to >> RFC 2119. We should probably change all RFC 2119 terms to lower case for >> this document. > > Ok, that is an oversight by me. I will fix it. I didn't find anything > else but one MUST. Did I miss something? Didn't find anything else either. >> Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or >> NAT-PT system tracks the mapping of HITs and the corresponding IPsec >> SPIs to an IP address." Not sure what this sentence is supposed to mean. > > I'll take this up separately as this may need some discussion. > (Later, now I must go.) On second reading, it makes sense. When I first read it, I wasn't able to parse the sentence. Lack of coffee, probably. >> All section headings: Use consistent capitalization througout the >> document. > > Ok, I will fix that. Lars -- Lars Eggert NEC Network Laboratories --------------ms080900090701080707040800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMjAxNjI2MjFaMCMGCSqGSIb3DQEJBDEWBBToN9FXSxIGvxDdyPN1Efrv+olbGjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQA1hIHZh1KVZZyuXWIRNwEkYph8mhnAxjdMMtX6RBD3UfbD lqXUQGKJ63oGlaEnF70EhvTgBYGZEro1lQy6uga+hbWiIH7kCYNCRREs675QfW+nNpwJaT3R unPPrt03EhZXiv2wbVjj++1pfI0rSrrd5X4U/TFwMnfoDDpOyh5aFl88eb0UANBHYB5z455s hc4jo9BA7cx5mghnnNQIPs4c6l8TYlGt8gm5PvcR0/JkfqFA0aVGeV5Z0hn25p88uiQVj10a G79IA7FADYUeLdHoMxgURSiS1v5Kn4uYd2uuWhVs3ArASUa9BjFo2PHsn9R8o0Ubun5B67GA /v75BbRJAAAAAAAA --------------ms080900090701080707040800-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Oct 20 21:52:24 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07642 for ; Wed, 20 Oct 2004 21:52:23 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id ED6DB72F5; Wed, 20 Oct 2004 20:42:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 0571D72F2 for ; Wed, 20 Oct 2004 20:41:53 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA00229; Wed, 20 Oct 2004 18:51:29 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9L1pTD22629; Wed, 20 Oct 2004 18:51:29 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Oct 2004 18:51:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Base draft - 01-pre2 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base draft - 01-pre2 Thread-Index: AcS1CxPuZHEx27QaSqGBYCXCDrItRQCBTLqg From: "Henderson, Thomas R" To: "Petri Jokela" Cc: X-OriginalArrivalTime: 21 Oct 2004 01:51:27.0780 (UTC) FILETIME=[7A9EBE40:01C4B710] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 18:51:27 -0700 Date: Wed, 20 Oct 2004 18:51:27 -0700 Content-Transfer-Encoding: quoted-printable > The 01-pre2 version of the base draft is available at >=20 > http://hip4inter.net/drafts.php >=20 A few comments: Section 5: 5.4.1-- CLOSED HIP SA clos, no data (ESP) can be sent ^^ed =20 in state CLOSING, receive I1, stay at UNASSOCIATED ^^^^^^^^^^^^ CLOSING (same copy and paste error for state CLOSED) =20 Section 6: Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try to = interoperate these packets. Can we pick some values now?=20 Section 8.16: as i specified in Section 6.3.5. ^^ (delete) Section 13: =20 NATing, etc.). However, the optionnal behavior of replying to CLOSE ^^^^^^^^^ optional =20 reflexion attacks. ^^^^^^^^^ reflection _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 00:37:23 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24116 for ; Thu, 21 Oct 2004 00:37:23 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A7B2E72F5; Wed, 20 Oct 2004 23:27:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 0C85472F2 for ; Wed, 20 Oct 2004 23:26:36 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id VAA29975; Wed, 20 Oct 2004 21:36:14 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9L4aED20558; Wed, 20 Oct 2004 21:36:14 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Oct 2004 21:36:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Digital Signature Algorithms Thread-Index: AcS1B7dWd4aH6LBpT++PBEcSCETR/QCHmwuw From: "Henderson, Thomas R" To: "Pekka Nikander" , X-OriginalArrivalTime: 21 Oct 2004 04:36:13.0942 (UTC) FILETIME=[7F3B5960:01C4B727] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Wed, 20 Oct 2004 21:36:13 -0700 Date: Wed, 20 Oct 2004 21:36:13 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Monday, October 18, 2004 3:46 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > My sense from the discussion so far is that people slightly > favour RSA. Hence, apparently we should go for >=20 > - RSA MUST implement algorithm > - DSA SHOULD implement algorithm I support that. >=20 > What comes to algorithm negotiation, I think that we can > go with the following approach: I am not worried about negotiation or evolving this for now, but it seems difficult, if only HITs are known before the handshake, to use anything but RSA. If we ever go away from "MUST" RSA, we may have to consider some extensions for negotiation. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 01:44:28 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27786 for ; Thu, 21 Oct 2004 01:44:27 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B4CDF72F5; Thu, 21 Oct 2004 00:34:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id A0D0772E0 for ; Thu, 21 Oct 2004 00:33:02 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 67E04220005; Thu, 21 Oct 2004 08:42:46 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 47E2C8; Thu, 21 Oct 2004 08:42:47 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0A8E72BE-2324-11D9-B72A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] Digital Signature Algorithms To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 08:42:48 +0300 Date: Thu, 21 Oct 2004 08:42:48 +0300 Content-Transfer-Encoding: 7bit Tom, > I am not worried about negotiation or evolving this > for now, but it seems difficult, if only HITs are known > before the handshake, to use anything but RSA. If we > ever go away from "MUST" RSA, we may have to consider > some extensions for negotiation. I don't quite understand this. If all you have is a HIT, you can't do anything else but use the algorithm associated with the HIT. If you don't know the key type of the HI from which the remote HIT was generated from, you can always test. You'll get the key in an R1. If you get a HI that you can't handle, you have no other option but trying another HIT. So, as far as I can see, there is no need for a negotiation. The problematic case is the opportunistic mode, but for that we outlined the interoperability requirements. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 02:35:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14466 for ; Thu, 21 Oct 2004 02:35:24 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 37A3E72F5; Thu, 21 Oct 2004 01:25:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id B514372E0 for ; Thu, 21 Oct 2004 01:24:19 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id 55787212C8E; Thu, 21 Oct 2004 09:34:10 +0300 (EEST) Message-ID: <417757F0.8020303@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Base draft - 01-pre2 References: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 09:32:16 +0300 Date: Thu, 21 Oct 2004 09:32:16 +0300 Content-Transfer-Encoding: 7bit Thanks for the fixes! Henderson, Thomas R wrote: > Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try to interoperate these packets. Can we pick some values now? How about 10 and 11? /petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 02:58:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15336 for ; Thu, 21 Oct 2004 02:58:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9490772F5; Thu, 21 Oct 2004 01:48:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 0857172E0 for ; Thu, 21 Oct 2004 01:47:34 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 948452FD2; Thu, 21 Oct 2004 09:57:25 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9L6vPc06923; Thu, 21 Oct 2004 09:57:25 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jari Arkko Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Digital Signature Algorithms In-Reply-To: <41756725.1060002@piuha.net> Message-ID: References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 09:57:24 +0300 (EEST) Date: Thu, 21 Oct 2004 09:57:24 +0300 (EEST) On Tue, 19 Oct 2004, Jari Arkko wrote: > Just one comment: > > > In the light of these performance estimation figures, I still prefer the > > DSA because it is more friendly for the responders (i.e. busy servers) in > > the case where R1s are created on-the-fly; this is also coherent with the > > I think the precreated R1 case is the default assumption, > and should be at any rate if performance is a concern. > So I'd like us to consider that situation as our primary > problem. If I understood your numbers right, there was a > minor increase dsa->rsa for responders in this case and > a bigger decrease dsa->rsa for initiators. Based on this, > RSA appears better from my point of view, though certainly > not quite as much as I initially thought. Using RSA as the default algorithm makes dynamically created R1s less appealing from a performance point of view. In a way, this limits the way implementations will be done in the real world. I have understood that most of the current (research prototype) implementations create R1s on-the-fly rather than off-the-shelf. The reason for this is that the precreated R1s are tricky due to numerous variables involved. Introducing the rendezvous server does not help either; it introduces new permutations, and increases the complexity of precreated R1s. But may be this a problem that needs to be solved separately from the DSA/RSA matter. Other than that, I am fine with the change to RSA. I just want us to do it with an understandment of the little trade-offs involved. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 03:09:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16165 for ; Thu, 21 Oct 2004 03:09:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8DDE572F5; Thu, 21 Oct 2004 01:59:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id 1EDB072E0 for ; Thu, 21 Oct 2004 01:58:37 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 21F498982E; Thu, 21 Oct 2004 10:08:28 +0300 (EEST) Message-ID: <4177600A.6010509@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miika Komu Cc: hipsec@honor.trusecure.com Subject: Difficulty of off-the-shelf R1s (Was: Re: [Hipsec] Digital Signature Algorithms) References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 10:06:50 +0300 Date: Thu, 21 Oct 2004 10:06:50 +0300 Content-Transfer-Encoding: 7bit Miika Komu wrote: > I have understood that most of the current (research prototype) > implementations create R1s on-the-fly rather than off-the-shelf. The > reason for this is that the precreated R1s are tricky due to numerous > variables involved. Just for my education, can you elaborate a bit more about these problems? --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 03:38:25 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17803 for ; Thu, 21 Oct 2004 03:38:25 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1BFB372F5; Thu, 21 Oct 2004 02:28:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 75E9072E0 for ; Thu, 21 Oct 2004 02:27:11 -0400 (EDT) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5373030B2; Thu, 21 Oct 2004 10:37:03 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9L7b2A09835; Thu, 21 Oct 2004 10:37:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jari Arkko Cc: hipsec@honor.trusecure.com Subject: Re: Difficulty of off-the-shelf R1s (Was: Re: [Hipsec] Digital Signature Algorithms) In-Reply-To: <4177600A.6010509@piuha.net> Message-ID: References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> <4177600A.6010509@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 10:37:02 +0300 (EEST) Date: Thu, 21 Oct 2004 10:37:02 +0300 (EEST) On Thu, 21 Oct 2004, Jari Arkko wrote: > Miika Komu wrote: > > > I have understood that most of the current (research prototype) > > implementations create R1s on-the-fly rather than off-the-shelf. The > > reason for this is that the precreated R1s are tricky due to numerous > > variables involved. > > Just for my education, can you elaborate a bit more about > these problems? http://honor.trusecure.com/pipermail/hipsec/2004-June/000789.html (especially the third message in the thread) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 11:16:29 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12055 for ; Thu, 21 Oct 2004 11:16:29 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6764972F5; Thu, 21 Oct 2004 10:06:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 3A32E72E0 for ; Thu, 21 Oct 2004 10:05:44 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 4A9B4220009; Thu, 21 Oct 2004 18:15:34 +0300 (EEST) Received: from [127.0.0.1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2E6E38; Thu, 21 Oct 2004 18:15:35 +0300 (EEST) In-Reply-To: <417757F0.8020303@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> <417757F0.8020303@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FD6414C-2374-11D9-B6FB-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Base draft - 01-pre2 To: Petri Jokela X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 18:15:37 +0300 Date: Thu, 21 Oct 2004 18:15:37 +0300 Content-Transfer-Encoding: 7bit >> Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try >> to interoperate these packets. Can we pick some values now? > > How about 10 and 11? I would suggest the following values, and also reordering Sections 7 and 8 to reflect the same logic. I1 1 R1 2 I2 3 R2 4 CER 5 UPDATE 6 NOTIFY 7 CLOSE 8 CACK 9 BOS --remove-- (should be an extension, separate document) PAYLOAD --remove-- (should be an extension, separate document) I do see some strange beauty in the above series, but that is minor. If people prefer to retain existing packet types, I don't have anything against it. 10 and 11 are fine. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 12:19:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19093 for ; Thu, 21 Oct 2004 12:19:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 034BA72F5; Thu, 21 Oct 2004 11:09:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id EDCF172E0 for ; Thu, 21 Oct 2004 11:08:42 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA10504; Thu, 21 Oct 2004 11:18:25 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9LGIPs14080; Thu, 21 Oct 2004 09:18:25 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 09:18:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Digital Signature Algorithms Thread-Index: AcS3MMz3bdIeONtcQkGDx8gGtl7MdAAVrVRg From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 21 Oct 2004 16:18:25.0315 (UTC) FILETIME=[977CAF30:01C4B789] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 09:18:24 -0700 Date: Thu, 21 Oct 2004 09:18:24 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Wednesday, October 20, 2004 10:43 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > Tom, >=20 > > I am not worried about negotiation or evolving this > > for now, but it seems difficult, if only HITs are known > > before the handshake, to use anything but RSA. If we > > ever go away from "MUST" RSA, we may have to consider > > some extensions for negotiation. >=20 > I don't quite understand this. If all you have is a HIT, > you can't do anything else but use the algorithm associated > with the HIT. If you don't know the key type of the HI > from which the remote HIT was generated from, you can always > test. You'll get the key in an R1. If you get a HI that > you can't handle, you have no other option but trying another > HIT. So, as far as I can see, there is no need for a negotiation. Yes, I agree with this. If an initiator wants to talk HIP with this responder, it has no other choice than to send opportunistic I1, and hope that the R1 comes from the same machine (maybe there might be some way to securely establish linkage between this RSA HI and the first HIT, specified in some future extension). >=20 > The problematic case is the opportunistic mode, but for that > we outlined the interoperability requirements. >=20 My only point on that outline was that, unless there was some=20 negotiation extension, it would be difficult to move away from=20 DSA or RSA in opportunistic mode in the future, while maintaining backward compatibility. Maybe this is obvious, but I was just=20 pointing out the implication. I don't think we need more complexity than what you proposed. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 12:52:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22330 for ; Thu, 21 Oct 2004 12:52:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 97BC1730A; Thu, 21 Oct 2004 11:42:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by honor.icsalabs.com (Postfix) with ESMTP id 2503472F5 for ; Thu, 21 Oct 2004 11:41:39 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA07633; Thu, 21 Oct 2004 09:51:21 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9LGpK325630; Thu, 21 Oct 2004 11:51:21 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 09:51:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608CA@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Digital Signature Algorithms Thread-Index: AcS3O05pVzhMzjWUTbyacBJSPwRihQAUAuHw From: "Henderson, Thomas R" To: "Miika Komu" Cc: X-OriginalArrivalTime: 21 Oct 2004 16:51:20.0293 (UTC) FILETIME=[30AA6950:01C4B78E] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 09:51:19 -0700 Date: Thu, 21 Oct 2004 09:51:19 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Wednesday, October 20, 2004 11:57 PM > To: Jari Arkko > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms > Using RSA as the default algorithm makes dynamically created R1s less > appealing from a performance point of view. In a way, this=20 > limits the way > implementations will be done in the real world. I am not convinced that the above is true. The tradeoff seems to=20 be about a factor of two in sign performance in software=20 implementations, but some cycles will be recouped by faster verification, and in hardware, it might be a wash (e.g., http://www.safenet-inc.com/Library/3/SafeXcel-1741_ProductBrief.pdf). Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 12:54:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22487 for ; Thu, 21 Oct 2004 12:54:25 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EB7947312; Thu, 21 Oct 2004 11:44:02 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id EADF6730A for ; Thu, 21 Oct 2004 11:43:11 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA04245; Thu, 21 Oct 2004 09:52:57 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9LGqu327207; Thu, 21 Oct 2004 11:52:56 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 09:52:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Base draft - 01-pre2 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452279F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Base draft - 01-pre2 Thread-Index: AcS3gNIcmBAYYJCNTJisCWcvtwL8UAADXLnw From: "Henderson, Thomas R" To: "Pekka Nikander" , "Petri Jokela" Cc: X-OriginalArrivalTime: 21 Oct 2004 16:52:52.0632 (UTC) FILETIME=[67B43980:01C4B78E] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 09:52:52 -0700 Date: Thu, 21 Oct 2004 09:52:52 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, October 21, 2004 8:16 AM > To: Petri Jokela > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Base draft - 01-pre2 >=20 >=20 > >> Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it=20 > tough to try=20 > >> to interoperate these packets. Can we pick some values now? > > > > How about 10 and 11? >=20 > I would suggest the following values, and also reordering > Sections 7 and 8 to reflect the same logic. >=20 > I1 1 > R1 2 > I2 3 > R2 4 > CER 5 > UPDATE 6 > NOTIFY 7 > CLOSE 8 > CACK 9 > BOS --remove-- (should be an extension, separate=20 > document) > PAYLOAD --remove-- (should be an extension, separate document) >=20 I agree with the above renumbering and dropping BOS and PAYLOAD for now. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 13:36:26 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26549 for ; Thu, 21 Oct 2004 13:36:26 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 803C172F5; Thu, 21 Oct 2004 12:26:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 224E272E0 for ; Thu, 21 Oct 2004 12:25:54 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 129EB220009; Thu, 21 Oct 2004 20:35:47 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id F336D8; Thu, 21 Oct 2004 20:35:47 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] Digital Signature Algorithms To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 20:35:50 +0300 Date: Thu, 21 Oct 2004 20:35:50 +0300 Content-Transfer-Encoding: 7bit > My only point on that outline was that, unless there was some > negotiation extension, it would be difficult to move away from > DSA or RSA in opportunistic mode in the future, while maintaining > backward compatibility. Maybe this is obvious, but I was just > pointing out the implication. I see. But, if we need to move away from DSA or RSA for security reasons, I'm afraid that we can't maintain backward compatibility. Independent of what kind of a negotiation mechanism you would have, you would be vulnerable to bidding-down attacks. Maybe we should add a paragraph to the security considerations section: If an initiator wants to use opportunistic mode, it is vulnerable to man-in-the-middle attacks. Furthermore, the available HI types are limited to the MUST implement algorithms, as per . Hence, if a future specification deprecates the current MUST implement algorithm(s) and replaces it (them) with some new one(s), backward compatibility cannot be preserved. However, given the generally insecure nature of the opportunistic mode, this is not considered to be a serious problem. Or something like that? The above text is slightly vague, but I'm just too tired right now to provide a better one. Any takers? > I don't think we need more complexity than what you proposed. Good. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 21 14:22:33 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02203 for ; Thu, 21 Oct 2004 14:22:31 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 004547303; Thu, 21 Oct 2004 13:12:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by honor.icsalabs.com (Postfix) with ESMTP id 2BDE972F5 for ; Thu, 21 Oct 2004 13:11:44 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA08721; Thu, 21 Oct 2004 11:21:24 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9LILOs03682; Thu, 21 Oct 2004 11:21:24 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 11:21:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608CB@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Digital Signature Algorithms Thread-Index: AcS3lGjrLywKW4M1QvCsHpxkruT3rwABN8Kw From: "Henderson, Thomas R" To: "Pekka Nikander" Cc: X-OriginalArrivalTime: 21 Oct 2004 18:21:21.0699 (UTC) FILETIME=[C4278F30:01C4B79A] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 21 Oct 2004 11:21:21 -0700 Date: Thu, 21 Oct 2004 11:21:21 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, October 21, 2004 10:36 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > > My only point on that outline was that, unless there was some > > negotiation extension, it would be difficult to move away from > > DSA or RSA in opportunistic mode in the future, while maintaining > > backward compatibility. Maybe this is obvious, but I was just > > pointing out the implication. >=20 > I see. But, if we need to move away from DSA or RSA for > security reasons, I'm afraid that we can't maintain backward > compatibility. Independent of what kind of a negotiation > mechanism you would have, you would be vulnerable to > bidding-down attacks. good point. >=20 > Maybe we should add a paragraph to the security considerations > section: >=20 > If an initiator wants to use opportunistic mode, it is > vulnerable to man-in-the-middle attacks. Furthermore, > the available HI types are limited to the MUST implement > algorithms, as per . Hence, if a future > specification deprecates the current MUST implement algorithm(s) > and replaces it (them) with some new one(s), backward=20 > compatibility > cannot be preserved. However, given the generally insecure > nature of the opportunistic mode, this is not considered to > be a serious problem. >=20 I would delete the last sentence (opportunistic is not "generally insecure" although it has a specific security vulnerability),=20 otherwise I would support adding that paragraph. Tom =20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 22 05:01:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13873 for ; Fri, 22 Oct 2004 05:01:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5685372F3; Fri, 22 Oct 2004 03:51:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id 6D3B572EA for ; Fri, 22 Oct 2004 03:50:37 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id A6E8D212CAA; Fri, 22 Oct 2004 12:00:32 +0300 (EEST) Message-ID: <4178CBB8.7010202@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] HIP base draft 01 - preliminary version 3 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 22 Oct 2004 11:58:32 +0300 Date: Fri, 22 Oct 2004 11:58:32 +0300 Content-Transfer-Encoding: 7bit Hello everyone, I uploaded base draft 01 pre3 version to our server. Thanks to Julien for his efforts on these editions. The deadline for submitting 01 draft is on Monday, so I will make last editions before the deadline and after that submit the 01 version. (Sorry, it was not purpose to generate work for you for the weekend, but... :-) http://hip4inter.net/drafts.php Some comments: - New state picture. - HIP packet numbering changed (payload, bos removed and close, close_ack added) - One paragraph added in Security Considerations. Issue #44: SIGMA An additional HMAC in I2 and changed HMAC in R2. The HMAC in R2 covers, in addition to the packet, the HOST_ID of the Responder. I changed this type now to HMAC_2. Are the changes ok, or are there errors: o SIGMA vs. current HIP o packet definitions o packet handling o ... Issue #47: DSA/RSA The RSA is now defined as MUST, DSA as RECOMMENDED. Issue #46: HIT 126 vs. 128 bits Text edited. Issue #48: PAYLOAD + BOS PAYLOAD and BOS packets were removed from the draft (as proposed by Pekka). Left for future drafts. Any comments on this? Text still missing / open things: 1) There was discussion about the D-H usage. Shall we edit the base spec text related to this? Base spec (Miika 11.10): "The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes." Pekka in one of his mails (11.10.2004): "Well, my understanding has been that you shouldn't reuse your DH-key, ever. (Maybe the docs don't say that.)" 2) Random value: text still to be added to base spec Yogesh (20.9.2004) o In the draft it's important to say that the responder should keep the random value r for at least 2*MSL (and possibly longer) from the last time it sent message 2. In case Message 3 arrives after 2*MSL, and no random number r can be found, it should be dropped and an ICMP message should be sent. If the Initiator receives an ICMP after sending message-3, it should not assume that the responder sent the message, and should not close that session. An Initiator MAY however start with a new parallel I1 with a new nonce value. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 22 11:13:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12550 for ; Fri, 22 Oct 2004 11:13:34 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 22FF77315; Fri, 22 Oct 2004 10:02:56 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by honor.icsalabs.com (Postfix) with ESMTP id B58F37302 for ; Fri, 22 Oct 2004 10:01:01 -0400 (EDT) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9MFAxui029738 for ; Fri, 22 Oct 2004 09:11:00 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5Z00499RIAFW@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Fri, 22 Oct 2004 09:10:58 -0600 (MDT) Received: from [192.168.1.100] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5Z001Q3RI86I@mail.sun.net> for hipsec@honor.trusecure.com; Fri, 22 Oct 2004 09:10:58 -0600 (MDT) From: Julien Laganier In-reply-to: <200410151408.04279.julien.laganier@sun.com> To: hipsec@honor.trusecure.com Message-id: <200410221628.40425.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.7 References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> Subject: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 22 Oct 2004 16:28:40 +0200 Date: Fri, 22 Oct 2004 16:28:40 +0200 Content-Transfer-Encoding: quoted-printable On Friday 15 October 2004 14:08, Julien Laganier wrote: > Folks, > > About the DSA vs RSA issue, here's an excerpt of a CFRG email > mentionning an opinion about what algorithm should be used in > existing, and new protocol/applications. > > --julien BTW, I=A0just thought about having as mandatory encryption algorithm=20 "AES-CBC with HMAC-SHA1" instead of "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? =2D-julien > ---------- Forwarded Message ---------- > > Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory > Date: Thursday 26 August 2004 19:32 > From: "Hallam-Baker, Phillip" > To: "'Steven M. Bellovin'" , "Hughes, James > P" > Cc: "'saag@mit.edu'" , "'cfrg@ietf.org'" > , "'kent@bbn.com'" > > I think that we should track status of crypto algs independently of > their standards status. In particular I think that we should > distinguish between Recommended and Acceptable status. > > New applications should specify algorithms with Recommended status > Continued use of algorithms with Acceptable status should not raise > concern. > > > So I would classify as follows: > > Proposed: SHA-2 > Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024 > Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4 > Depricated: IDEA, RSA1024+MD5 > Obsolete: MD4, MD5, RSA-512, DES > > The reason that I distinguish between Depricated and obsolete is > that there are uses of RSA signatures with MD5 hash that are still > acceptably secure and the applications concerned do not support > SHA1. The reason I put DSA as acceptable rather than recommended is > that it does need a good random seed, the key size is small and it > is unlikely at this point to see much use. > > RC4 has been compromised by Shamir & co, but as a general rule I > don't think any stream cipher should ever get a higher status than > acceptable. A stream cipher always allows a person who has a > plaintext and ciphertext corresponding to a key to encode or > decode all messages with that key that are shorter or the same > size. In effect all stream ciphers are vulnerable to a trivial form > of known plaintext attack, the attack does not reveal the key but > this is not necessary. > > I do not feel confident in recommending moving to SHA2 at this > point. Before jumping I want to see that the place we are going to > is better than where we left. SHA2 is not currently widely used. If > it turns out that the recent cryptanalysis of SHA1 is also > applicable to the structures used in SHA2 then the rationale for a > change is lost. I would feel happier moving to a hash function > based on AES encryption (which i had eroneously assumed had been > the point of the SHA2 work). > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec =2D-=20 Julien Laganier=20 SUN Microsystems Laboratories "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian W. Kernighan *NOTICE*: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 22 12:07:36 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16886 for ; Fri, 22 Oct 2004 12:07:35 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 7015F7314; Fri, 22 Oct 2004 10:57:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by honor.icsalabs.com (Postfix) with ESMTP id AB48B7307 for ; Fri, 22 Oct 2004 10:56:01 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7865489830; Fri, 22 Oct 2004 19:06:01 +0300 (EEST) Message-ID: <41792F86.9040500@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> <200410221628.40425.julien.laganier@sun.com> In-Reply-To: <200410221628.40425.julien.laganier@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 22 Oct 2004 19:04:22 +0300 Date: Fri, 22 Oct 2004 19:04:22 +0300 Content-Transfer-Encoding: 7bit Julien Laganier wrote: > BTW, I just thought about having as mandatory encryption algorithm > "AES-CBC with HMAC-SHA1" instead of > "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? Yes. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 22 12:21:38 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17793 for ; Fri, 22 Oct 2004 12:21:37 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EDC4E7314; Fri, 22 Oct 2004 11:11:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 6577D7307 for ; Fri, 22 Oct 2004 11:10:07 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id BB0FE22000C; Fri, 22 Oct 2004 19:20:00 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id BA92B8; Fri, 22 Oct 2004 19:20:01 +0300 (EEST) In-Reply-To: <200410221628.40425.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> <200410221628.40425.julien.laganier@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3A3C8F30-2446-11D9-B6FB-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: quoted-printable Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) To: Julien Laganier X-Mailer: Apple Mail (2.619) Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 22 Oct 2004 19:20:02 +0300 Date: Fri, 22 Oct 2004 19:20:02 +0300 Content-Transfer-Encoding: quoted-printable > BTW, I=A0just thought about having as mandatory encryption algorithm > "AES-CBC with HMAC-SHA1" instead of > "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? Ok to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 25 08:15:57 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19785 for ; Mon, 25 Oct 2004 08:15:57 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B175172E6; Mon, 25 Oct 2004 07:05:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by honor.icsalabs.com (Postfix) with ESMTP id 9C09572E2 for ; Mon, 25 Oct 2004 07:04:09 -0400 (EDT) Received: from nomadiclab.com (n69.nomadiclab.com [131.160.193.69]) by n2.nomadiclab.com (Postfix) with ESMTP id D3F21212CAA for ; Mon, 25 Oct 2004 15:14:23 +0300 (EEST) Message-ID: <417CED96.6050407@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Base draft -01 submitted Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 25 Oct 2004 15:12:06 +0300 Date: Mon, 25 Oct 2004 15:12:06 +0300 Content-Transfer-Encoding: 7bit Hello folks, I submitted the base draft version -01 to IETF. The draft and diffs to previous versions can be found from: http://hip4inter.net/drafts.php I made the proposed change from mandatory 3DES to AES (key length 128 bits). This issue is still open for comments and discussion. /Petri _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 25 09:22:56 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24558 for ; Mon, 25 Oct 2004 09:22:55 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 36E7872E6; Mon, 25 Oct 2004 08:12:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 1AFD272E2 for ; Mon, 25 Oct 2004 08:11:45 -0400 (EDT) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0E3D031AD; Mon, 25 Oct 2004 16:22:04 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 6FCF83176 for ; Mon, 25 Oct 2004 16:22:02 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9PDM2J06224; Mon, 25 Oct 2004 16:22:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com In-Reply-To: <417CED96.6050407@nomadiclab.com> Message-ID: References: <417CED96.6050407@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.0-niksula20040914 (2004-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.0-niksula20040914 Subject: [Hipsec] SIGMA and ECHO_REQUEST/REPLY in base-01 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 25 Oct 2004 16:22:02 +0300 (EEST) Date: Mon, 25 Oct 2004 16:22:02 +0300 (EEST) There may be a slight problem with SIGMA compliancy in base-01. I think the ECHO_REQUEST/REPLY must be mandatory, or otherwise the base exchange is not SIGMA compliant. The SIGMA papers states (page 18, first paragraph) that the messages should carry either a fresh nonce (i.e. ECHO_REQUEST/REPLY), or the peer DH should be included in the signature. As the latter is not true in the base exchange, we need to make the former mandatory. (Also, the ECHO needs to be included in the signature.) However, I don't think that we need to have a two-way ECHO (i.e. the initiator send its own echo) if we intepret HIP as SIGMA-I with the peer awareness property (= R2 packet). On the figure on page 19 in the SIGMA paper, we can subsitute g^x in the second packet with ECHO_REQUEST and g^y in the third packet with ECHO_REPLY in SIGMA-I. Agree? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Oct 25 11:01:14 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02414 for ; Mon, 25 Oct 2004 11:01:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D950272E6; Mon, 25 Oct 2004 09:50:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from pegasus.hiit.fi (pegasus.hiit.fi [212.68.1.186]) by honor.icsalabs.com (Postfix) with ESMTP id 549F072E2 for ; Mon, 25 Oct 2004 09:49:55 -0400 (EDT) Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 69989220004 for ; Mon, 25 Oct 2004 18:00:05 +0300 (EEST) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 29FFB8; Mon, 25 Oct 2004 18:00:06 +0300 (EEST) In-Reply-To: <4178CBB8.7010202@nomadiclab.com> References: <4178CBB8.7010202@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9101DB2E-2696-11D9-AFFD-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander To: Petri Jokela X-Mailer: Apple Mail (2.619) Subject: [Hipsec] Re: HIP base draft 01 - preliminary version 3 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 25 Oct 2004 17:00:10 +0200 Date: Mon, 25 Oct 2004 17:00:10 +0200 Content-Transfer-Encoding: 7bit Some comments on base-01-pre3. I'm late, I know, and these probably won't make it to -01, but maybe then to -02. --Pekka More substantial: - Rename the REKEYING state into a more generic one, like UPDATE pending or UPDATING or something? - HMAC_2 description must be fixed. Here is my initial proposal 160 low order bits of the HMAC computed over a given set of data, which includes some data that is NOT in the packet that carries this payload. The exact contents is defined case-by-case; see the relevant packet description. - The HMAC_2 calculation in 7.4 is too vague. It needs to have a picture of what to hash etc. - We need a proper IANA Considerations section. - Remove Appendix E. This needs to be a separate specification. More editorial: - Section 5.4 seems to be slightly out of date. The state machine has grown into fairly complex, contrary to the claims in this section. - In 5.4.2, there is strange cross reference to Sec 6.3 in the HTML version - Same for 6.2.9. An idea: would it be better to move to a table presentation, or to include an appendix that gives a table with states as rows and incoming messsages as columns. There are now nine packets and nine states, so the table has 81 cells altogether. However, in many cases the response is identical for a number of messages or number of states, and therefore quite a number of the cells actual merge. - In 5.4.3 (state diagram), remove the phrase "and NES received", as it does not need to be there. That makes UPDATE more generic update mechanism, not NES specific. - the cases where the arcs cross each other are closing, as the diagram uses the same symbol for crossing arcs (+) and arc turns/joins. I think a crossing arc should be just a vertical bar, giving the visual image that the horisontal arc goes beneath the vertical one. - In 6.2.7, I think that the sentence "The OAKLEY well known group 5 is the same as the 1536-bit MODP group." is no longer needed and confusing - In order not the have to rewrite all "Valid Control Bits" text in Section 7, it may be better to make SHT and RHT not to be part of Controls? Or just update the various places in Section 7. - Move 8.12 (CER) after 8.8 (R2) - Move 8.9 (dropping) before 8.14 (CLOSE), and update it accordingly currently the text is not in line with the close mechanism _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Oct 26 02:00:01 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16155 for ; Tue, 26 Oct 2004 02:00:00 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4190172F2; Tue, 26 Oct 2004 00:49:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 067D672E2 for ; Tue, 26 Oct 2004 00:48:10 -0400 (EDT) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D8A60310C; Tue, 26 Oct 2004 08:58:33 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4E1EF30AD for ; Tue, 26 Oct 2004 08:58:33 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9Q5wXJ18662; Tue, 26 Oct 2004 08:58:33 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] SIGMA and ECHO_REQUEST/REPLY in base-01 In-Reply-To: Message-ID: References: <417CED96.6050407@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.0-niksula20040914 (2004-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.0-niksula20040914 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Tue, 26 Oct 2004 08:58:33 +0300 (EEST) Date: Tue, 26 Oct 2004 08:58:33 +0300 (EEST) On Mon, 25 Oct 2004, Miika Komu wrote: > There may be a slight problem with SIGMA compliancy in base-01. I think > the ECHO_REQUEST/REPLY must be mandatory, or otherwise the base exchange > is not SIGMA compliant. (Forget this - this wasn't true. I should not post messages when I am tired ;) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 28 10:43:16 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18864 for ; Thu, 28 Oct 2004 10:43:14 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 61658730B; Thu, 28 Oct 2004 09:32:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by honor.icsalabs.com (Postfix) with ESMTP id 4F68D7307 for ; Thu, 28 Oct 2004 09:31:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18682; Thu, 28 Oct 2004 10:41:43 -0400 (EDT) Message-Id: <200410281441.KAA18682@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: hipsec@honor.trusecure.com From: Internet-Drafts@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-01.txt Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 28 Oct 2004 10:41:43 -0400 Date: Thu, 28 Oct 2004 10:41:43 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-01.txt Pages : 104 Date : 2004-10-27 This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105621.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 28 11:02:15 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21644 for ; Thu, 28 Oct 2004 11:02:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 194A4730F; Thu, 28 Oct 2004 09:51:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from mail.iinet.net.au (mail-01.iinet.net.au [203.59.3.33]) by honor.icsalabs.com (Postfix) with SMTP id C7F3E7307 for ; Thu, 28 Oct 2004 09:50:11 -0400 (EDT) Received: (qmail 26000 invoked from network); 28 Oct 2004 15:00:39 -0000 Received: from unknown (HELO T40) (203.217.52.86) by mail.iinet.net.au with SMTP; 28 Oct 2004 15:00:39 -0000 From: "Joseph" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4BD52.B07804C0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcS8/t2xJH61Ot41RcyT1LFLpxpvvQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20041028135011.C7F3E7307@honor.icsalabs.com> Subject: [Hipsec] What is changed in draft-ietf-hip-base-01? Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 29 Oct 2004 01:00:30 +1000 Date: Fri, 29 Oct 2004 01:00:30 +1000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4BD52.B07804C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, What is different between draft-ietf-hip-base-01 with 00? I cannot find the track of change in this draft. Thanks a lot. Yours faithfully, Joseph ------=_NextPart_000_0000_01C4BD52.B07804C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
    What is=20 different between draft-ietf-hip-base-01 with 00? I cannot find the = track of=20 change in this draft. Thanks a lot.
Yours=20 faithfully,
Joseph
------=_NextPart_000_0000_01C4BD52.B07804C0-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Oct 28 11:09:13 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22945 for ; Thu, 28 Oct 2004 11:09:13 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8D1407314; Thu, 28 Oct 2004 09:58:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by honor.icsalabs.com (Postfix) with ESMTP id 95C687307 for ; Thu, 28 Oct 2004 09:57:07 -0400 (EDT) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 801B62ED3; Thu, 28 Oct 2004 18:07:46 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DD9912EC9; Thu, 28 Oct 2004 18:07:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id i9SF7ia03035; Thu, 28 Oct 2004 18:07:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Joseph Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] What is changed in draft-ietf-hip-base-01? In-Reply-To: <20041028135011.C7F3E7307@honor.icsalabs.com> Message-ID: References: <20041028135011.C7F3E7307@honor.icsalabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.0-niksula20040914 (2004-09-13) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.0-niksula20040914 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Thu, 28 Oct 2004 18:07:44 +0300 (EEST) Date: Thu, 28 Oct 2004 18:07:44 +0300 (EEST) On Fri, 29 Oct 2004, Joseph wrote: > Dear All, > What is different between draft-ietf-hip-base-01 with 00? I cannot find > the track of change in this draft. Thanks a lot. > Yours faithfully, http://hip4inter.net/documentation/drafts/diff_00_01.html -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 29 19:08:23 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24196 for ; Fri, 29 Oct 2004 19:08:23 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 621C17328; Fri, 29 Oct 2004 17:57:04 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from sapo.pt (relay5.ptmail.sapo.pt [212.55.154.25]) by honor.icsalabs.com (Postfix) with SMTP id 1D3D17312 for ; Fri, 29 Oct 2004 17:56:01 -0400 (EDT) Received: (qmail 3538 invoked from network); 29 Oct 2004 23:06:41 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.152) by relay5 with SMTP; 29 Oct 2004 23:06:41 -0000 Received: (qmail 3820 invoked from network); 29 Oct 2004 23:06:40 -0000 Received: from unknown (HELO [192.168.1.2]) ([81.193.27.141]) (envelope-sender ) by mta2 (qmail-ldap-1.03) with SMTP for ; 29 Oct 2004 23:06:40 -0000 From: Halestino Pimentel To: hipsec@honor.trusecure.com User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410300008.14731.halestino@ipb.pt> Subject: [Hipsec] Problem installing patched ipsec-tools-0.3.3 Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Sat, 30 Oct 2004 00:08:14 +0100 Date: Sat, 30 Oct 2004 00:08:14 +0100 Content-Transfer-Encoding: 7bit Hello, I'm trying to test the Boeing Linux HIP implementation. I compiled a new (patched) kernel and booted from. No problem till here. My problems started when I install ipsec-tools-0.3.3 (patched with ipsec-tools-0.3.3-hip.patch). I issue ./configure --with-openssl=/usr/local/ssl (the directory where I installed openssl-0.9.7a) and get no errors. When I issue make install I get the following: make[2]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src/include-glibc' Making install in libipsec make[2]: Entering directory `/usr/local/src/ipsec-tools-0.3.3/src/libipsec' if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_dump_policy.lo -MD -MP -MF ".deps/ipsec_dump_policy.Tpo" -c -o ipsec_dump_policy.lo ipsec_dump_policy.c; \ then mv -f ".deps/ipsec_dump_policy.Tpo" ".deps/ipsec_dump_policy.Plo"; else rm -f ".deps/ipsec_dump_policy.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_dump_policy.lo -MD -MP -MF .deps/ipsec_dump_policy.Tpo -c ipsec_dump_policy.c -o ipsec_dump_policy.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_get_policylen.lo -MD -MP -MF ".deps/ipsec_get_policylen.Tpo" -c -o ipsec_get_policylen.lo ipsec_get_policylen.c; \ then mv -f ".deps/ipsec_get_policylen.Tpo" ".deps/ipsec_get_policylen.Plo"; else rm -f ".deps/ipsec_get_policylen.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_get_policylen.lo -MD -MP -MF .deps/ipsec_get_policylen.Tpo -c ipsec_get_policylen.c -o ipsec_get_policylen.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_strerror.lo -MD -MP -MF ".deps/ipsec_strerror.Tpo" -c -o ipsec_strerror.lo ipsec_strerror.c; \ then mv -f ".deps/ipsec_strerror.Tpo" ".deps/ipsec_strerror.Plo"; else rm -f ".deps/ipsec_strerror.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_strerror.lo -MD -MP -MF .deps/ipsec_strerror.Tpo -c ipsec_strerror.c -o ipsec_strerror.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT key_debug.lo -MD -MP -MF ".deps/key_debug.Tpo" -c -o key_debug.lo key_debug.c; \ then mv -f ".deps/key_debug.Tpo" ".deps/key_debug.Plo"; else rm -f ".deps/key_debug.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT key_debug.lo -MD -MP -MF .deps/key_debug.Tpo -c key_debug.c -o key_debug.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT pfkey.lo -MD -MP -MF ".deps/pfkey.Tpo" -c -o pfkey.lo pfkey.c; \ then mv -f ".deps/pfkey.Tpo" ".deps/pfkey.Plo"; else rm -f ".deps/pfkey.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT pfkey.lo -MD -MP -MF .deps/pfkey.Tpo -c pfkey.c -o pfkey.o pfkey.c: In function `pfkey_send_hip_x1': pfkey.c:1500: error: invalid application of `sizeof' to an incomplete type pfkey.c: In function `pfkey_setsadbhit': pfkey.c:2701: error: invalid application of `sizeof' to an incomplete type pfkey.c:2707: error: dereferencing pointer to incomplete type pfkey.c:2708: error: dereferencing pointer to incomplete type pfkey.c:2708: error: `SADB_EXT_HIT' undeclared (first use in this function) pfkey.c:2708: error: (Each undeclared identifier is reported only once pfkey.c:2708: error: for each function it appears in.) pfkey.c:2709: error: dereferencing pointer to incomplete type make[2]: *** [pfkey.lo] Error 1 make[2]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src/libipsec' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src' make: *** [install-recursive] Error 1 The problem is with a function in directory libipsec. Does anybody knows why this happens? Thanks in advance, Halestino _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Oct 29 19:11:20 2004 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24388 for ; Fri, 29 Oct 2004 19:11:19 -0400 (EDT) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 85E3C7339; Fri, 29 Oct 2004 18:00:03 -0400 (EDT) Delivered-To: hipsec@honor.trusecure.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by honor.icsalabs.com (Postfix) with ESMTP id BB41E7312 for ; Fri, 29 Oct 2004 17:59:26 -0400 (EDT) Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA09129; Fri, 29 Oct 2004 18:10:12 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9TNABN12612; Fri, 29 Oct 2004 18:10:11 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Oct 2004 16:10:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Problem installing patched ipsec-tools-0.3.3 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452283E@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Problem installing patched ipsec-tools-0.3.3 Thread-Index: AcS+DCObBTEQK39mTTSnbjRcjcwSzAAABjTg From: "Henderson, Thomas R" To: "Halestino Pimentel" Cc: X-OriginalArrivalTime: 29 Oct 2004 23:10:10.0749 (UTC) FILETIME=[7060BED0:01C4BE0C] Sender: hipsec-admin@honor.trusecure.com Errors-To: hipsec-admin@honor.trusecure.com X-BeenThere: hipsec@honor.trusecure.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: HIP Protocol Discussion List List-Unsubscribe: , List-Archive: X-Original-Date: Fri, 29 Oct 2004 16:10:10 -0700 Date: Fri, 29 Oct 2004 16:10:10 -0700 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Halestino Pimentel [mailto:halestino@ipb.pt]=20 > Sent: Friday, October 29, 2004 4:08 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Problem installing patched ipsec-tools-0.3.3 >=20 >=20 > Hello, >=20 > I'm trying to test the Boeing Linux HIP implementation. I=20 > compiled a new=20 > (patched) kernel and booted from. No problem till here. > My problems started when I install ipsec-tools-0.3.3 (patched with=20 > ipsec-tools-0.3.3-hip.patch). I issue ./configure=20 > --with-openssl=3D/usr/local/ssl (the directory where I installed=20 > openssl-0.9.7a) and get no errors.=20 Please refer installation problems directly to the implementors = themselves. Thanks, Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec