From ticsa-info-admin@honor.trusecure.com Tue Mar 1 05:01:20 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08368 for ; Tue, 1 Mar 2005 05:01:20 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id AF7627353 for ; Tue, 1 Mar 2005 05:00:45 -0500 (EST) Date: Tue, 01 Mar 2005 05:00:45 -0500 Message-ID: <20050301100045.18840.20186.Mailman@honor> Subject: honor.trusecure.com mailing list memberships reminder From: mailman-owner@honor.icsalabs.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 mailman-owner@honor. 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 Tue Mar 1 05:19:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09533 for ; Tue, 1 Mar 2005 05:19:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 00AE57312; Tue, 1 Mar 2005 05:19:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from web14306.mail.yahoo.com (web14306.mail.yahoo.com [216.136.173.82]) by honor.icsalabs.com (Postfix) with SMTP id 9ED8F72F5 for ; Tue, 1 Mar 2005 05:18:41 -0500 (EST) Received: (qmail 75934 invoked by uid 60001); 1 Mar 2005 10:18:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=e7KeS59ehCKxObzpZYF14cieU4kkZOPmosFuUsl/97R8OffEKyI/SqjwCQUya8HfT6wOmV7k38ozHPp5H1W4g4e6S3e4ehU2vcdq81afQrfd5MGdx8BDFEtDHxozgIocdL0KqA9nsizc+TvXwMyT8Vj2OVRGcbiJJjx7r5CDkAI= ; Message-ID: <20050301101842.75932.qmail@web14306.mail.yahoo.com> Received: from [192.35.17.15] by web14306.mail.yahoo.com via HTTP; Tue, 01 Mar 2005 02:18:41 PST From: Murugaraj To: Petri Jokela , hipsec@honor.trusecure.com In-Reply-To: <42020300.5040302@nomadiclab.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-119296128-1109672321=:75418" Subject: [Hipsec] Draft: ESP usage in HIP?? 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, 1 Mar 2005 02:18:41 -0800 (PST) Date: Tue, 1 Mar 2005 02:18:41 -0800 (PST) --0-119296128-1109672321=:75418 Content-Type: text/plain; charset=us-ascii Hi , I am really confused about the splitting of ESP usage from the base draft. Does it mean that the HIP hosts "optionally" carry ESP stuff or is it just to address seperately for simplictiy? I feel that the HIP still suggests the "mandatory" usage of ESP for the data traffic. am i right? Because in the HIP-base-02 dratft, it is quoted that HIP must implement the ESP transport format. ciao, Raj. --------------------------------- Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. --0-119296128-1109672321=:75418 Content-Type: text/html; charset=us-ascii
Hi ,
 
  I am really confused about the splitting of ESP usage from the base draft.
 
Does it mean that the HIP hosts "optionally" carry ESP stuff
           or
 is it just to address seperately for simplictiy?
 
I feel that the HIP still suggests the "mandatory" usage of ESP for the data traffic. am i right? Because in the HIP-base-02 dratft, it is quoted that HIP must implement the ESP transport format.
 
ciao,
Raj.

Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less. --0-119296128-1109672321=:75418-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 1 08:21:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23253 for ; Tue, 1 Mar 2005 08:21:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D249F72F5; Tue, 1 Mar 2005 08:21:01 -0500 (EST) 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 0977572EA for ; Tue, 1 Mar 2005 08:20:03 -0500 (EST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j21DJqO6019344; Tue, 1 Mar 2005 14:19:52 +0100 Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 14:20:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 14:20:37 +0100 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 06DBA189CC; Tue, 1 Mar 2005 15:19:50 +0200 (EET) Message-ID: <42246C25.6010501@ericsson.com> From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: David Ward , HIP Subject: Re: [Hipsec] Agenda IETF 62 References: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 13:20:37.0610 (UTC) FILETIME=[752754A0:01C51E61] 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, 01 Mar 2005 15:20:37 +0200 Date: Tue, 01 Mar 2005 15:20:37 +0200 Content-Transfer-Encoding: 7bit Done. Gonzalo Henderson, Thomas R wrote: > Gonzalo, > i) it would seem to make sense to keep the discussion on HIP-MM draft > together-- suggest moving my presentation on hip-mm to just before > Christian's slot > > ii) likewise, the draft on generalizing HIP pertains to the base spec > and could be moved up to the third slot. > > Tom > > >>-----Original Message----- >>From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>Sent: Monday, February 28, 2005 6:18 AM >>To: HIP >>Cc: David Ward >>Subject: [Hipsec] Agenda IETF 62 >> >>Folks, >> >>this is the preliminary agenda for the Minneapolis meeting: >> >>http://hip.piuha.net/meetings/ietf62/agenda.html >> >>Note that every speaker has gotten more time than he requested. >> >>Regards, >> >>Gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 2 12:28:38 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06919 for ; Wed, 2 Mar 2005 12:28:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 28EDC7317; Wed, 2 Mar 2005 12:28:02 -0500 (EST) 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 78C837316 for ; Wed, 2 Mar 2005 12:27:07 -0500 (EST) 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 JAA02547; Wed, 2 Mar 2005 09:26:47 -0800 (PST) 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 j22HQxI25168; Wed, 2 Mar 2005 09:26:59 -0800 (PST) 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, 2 Mar 2005 09:26:58 -0800 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] Draft: ESP usage in HIP?? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060A73@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Draft: ESP usage in HIP?? Thread-Index: AcUeSB+SOIb8dEIXShalHIdRjeP+hgBA741g From: "Henderson, Thomas R" To: "Murugaraj" , "Petri Jokela" , X-OriginalArrivalTime: 02 Mar 2005 17:26:58.0645 (UTC) FILETIME=[09C00850:01C51F4D] 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, 2 Mar 2005 09:26:58 -0800 Date: Wed, 2 Mar 2005 09:26:58 -0800 Content-Transfer-Encoding: quoted-printable Raj, You can find the discussion of this at the following mailing list thread: http://honor.trusecure.com/pipermail/hipsec/2004-November/001132.html =20 You are correct that ESP for HIP is mandatory, although I have a recent draft suggesting that it should be not a "MUST". http://www.ietf.org/internet-drafts/draft-henderson-hip-generalize-00.tx t =20 Tom ________________________________ From: Murugaraj [mailto:muru_lak2001@yahoo.com]=20 Sent: Tuesday, March 01, 2005 2:19 AM To: Petri Jokela; hipsec@honor.trusecure.com Subject: [Hipsec] Draft: ESP usage in HIP?? =09 =09 Hi , =20 I am really confused about the splitting of ESP usage from the base draft.=20 =20 Does it mean that the HIP hosts "optionally" carry ESP stuff=20 or=20 is it just to address seperately for simplictiy? =20 I feel that the HIP still suggests the "mandatory" usage of ESP for the data traffic. am i right? Because in the HIP-base-02 dratft, it is quoted that HIP must implement the ESP transport format. =20 ciao, Raj. ________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. = =20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sat Mar 5 22:15:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10060 for ; Sat, 5 Mar 2005 22:15:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C177F731B; Sat, 5 Mar 2005 22:15:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 1255E7304 for ; Sat, 5 Mar 2005 22:14:16 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id E96FD212E19; Sun, 6 Mar 2005 05:14:05 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Pekka Nikander Subject: Re: [Hipsec] FW: I-D ACTION:draft-henderson-hip-generalize-00.txt To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) 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, 5 Mar 2005 12:44:05 -0600 Date: Sat, 5 Mar 2005 12:44:05 -0600 Content-Transfer-Encoding: 7bit [Limiting the discussion to the WG ML.] I like the general direction and ideas of this draft a lot. The only bigger thing that I am concerned about is allowing HITs/ULIDs of any length. My feeling is that such a change would be detrimental, and create potential problems in the early packet handling code. For example, the code needed for finding the right existing context would probably become much more complex. Additionally, the code needed to determine if the Responder HIT/ULID in an I1 is one that belongs to the host may also become rather hairy. Therefore I would suggest that if we want to allow HITs/ULIDs of different lengths, we would limit those lengths only to a few choices, like 128 bits or 256 bits. Alternatively, I'm willing to consider a situation where the HIT/ULID type field implicitly defines the length. That's probably fine for end hosts; if you don't know an ULID type, you just reply with an appropriate ICMP. However, that seems bad for middle boxes; they would have more problems in deciding what to do with packets that carry ULIDs whose lengths they do not know. I've send some editorial and other minor notes separately. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Sun Mar 6 16:41:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29356 for ; Sun, 6 Mar 2005 16:41:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D73EB7307; Sun, 6 Mar 2005 16:41:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 22A0772E6 for ; Sun, 6 Mar 2005 16:40:42 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 216F6212E19 for ; Sun, 6 Mar 2005 23:40:39 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <52fae3df6c284f5e7a468ab11a95e5d0@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@honor.trusecure.com From: Pekka Nikander X-Mailer: Apple Mail (2.619.2) Subject: [Hipsec] Looking for a volunteer to run the hipsec ML 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, 6 Mar 2005 15:41:15 -0600 Date: Sun, 6 Mar 2005 15:41:15 -0600 Content-Transfer-Encoding: 7bit I have been running the hipsec ML for quite long now, meaning that I've been doing spam filtering pretty much manually. With new responsibilities and increased amount of spam I can't do it any more. Hence, I am looking for someone to help either to set up automatic spam filtering for the list or to take over the ML management. (Manual management requires maybe 2 hours per week, but I don't have that right now.) Anyone? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 8 15:38:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17148 for ; Tue, 8 Mar 2005 15:38:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 012737312; Tue, 8 Mar 2005 15:38:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id DDA21730F for ; Tue, 8 Mar 2005 15:37:09 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id C0D7C212E19; Tue, 8 Mar 2005 22:36:58 +0200 (EET) In-Reply-To: <073b01c51928$36411bb0$ef01a996@gmp> References: <42133673.5040907@piuha.net> <073b01c51928$36411bb0$ef01a996@gmp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] SHA1 broken? To: "Greg Perkins" X-Mailer: Apple Mail (2.619.2) 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, 8 Mar 2005 14:37:36 -0600 Date: Tue, 8 Mar 2005 14:37:36 -0600 Content-Transfer-Encoding: 7bit > The HIT needs two properties: > > 1) probably unique > 2) a identifier for the HI > > SHA1 will still supply property 1). > > As for property 2), I thought HIP was using a non-keyed SHA1 hash for > HI=>HIT computation? Basically, HIP is using SHA1's "randomness" > property > to meet property 1), yes? In this case, there is nothing to break and > property 2) holds as well. As for using keyed SHA1 for say, signing a > packet or whatnot, then yes, looks like SHA256 will have to be used > soon. Well, there is more in this. The HIT essentially works as a channel binding, giving assurance to the application that when it does connect(HIT) it actually gets a (secured) connection to the identified host. From that point of view, if SHA-1 has a weakness so that it becomes feasible to generate another (perhaps very short) public key that hashes to the same HIT, we do have a problem. My crypto understanding is too weak to be able to say for sure, but my understanding is that it has became easier to do that. I'm putting this up on the base spec slides for tomorrow. My personal opinion is to move to HMAC and SHA-256. I don't know if we want to change the HIT length in the HIP header at the same time or not. Maybe, just for the sake. We could then use the uppermost 128 bits of the HIT at the API, with the current 01/10 restriction. The LSI would then probably use 24 top most bits from the HIT instead of the 24 low bits, as now, but we are moving LSIs away from the base spec probably anyway. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 8 16:08:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19647 for ; Tue, 8 Mar 2005 16:08:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 22B1A7315; Tue, 8 Mar 2005 16:08:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by honor.icsalabs.com (Postfix) with ESMTP id ACF8F730F for ; Tue, 8 Mar 2005 16:07:29 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28L7gA07529; Tue, 8 Mar 2005 23:07:43 +0200 (EET) X-Scanned: Tue, 8 Mar 2005 23:06:24 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j28L6OYg009496; Tue, 8 Mar 2005 23:06:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 004sfhZb; Tue, 08 Mar 2005 23:06:22 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j28L6MU16555; Tue, 8 Mar 2005 23:06:22 +0200 (EET) Received: from [172.19.11.218] ([172.19.11.218]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Mar 2005 23:06:21 +0200 Subject: Re: [Hipsec] SHA1 broken? From: Yogesh Prem Swami To: ext Pekka Nikander Cc: Greg Perkins , hipsec@honor.trusecure.com In-Reply-To: <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> References: <42133673.5040907@piuha.net> <073b01c51928$36411bb0$ef01a996@gmp> <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> Content-Type: text/plain Organization: Nokia Research Center, Dallas Message-Id: <1110316095.15384.36.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2005 21:06:21.0347 (UTC) FILETIME=[ADCF7730:01C52422] 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, 08 Mar 2005 15:08:15 -0600 Date: Tue, 08 Mar 2005 15:08:15 -0600 Content-Transfer-Encoding: 7bit [Getting back on this mailing list after a long time :-) ] As far as SHA1 is concerned, I guess HITs (and HIP KE) are still quite secure. The reason is that HITs are generated from the public keys, so an attacker can potentially generate a string that will result in the same HITs, however for the attacker to be able to make use of this string she must must also be able to generate the private keys corresponding to that string. This is non trivial under standard crypto assumptions. For example, let say, I have [Priv, Pub] as my private and public keys, and an attacker generate Pub2 string such SHA1(Pub) == SHA1(Pub2). For the attacker to be able to use Pub2 during key exchange, she must sign her messages with the private key corresponding to Pub2. This is clearly not possible. Hash Collisions get so much attention because it makes certificates untrustworthy. HIP, on the other hand is quite secure in spite of the collisions. Thanks Yogesh On Tue, 2005-03-08 at 14:37, ext Pekka Nikander wrote: > > The HIT needs two properties: > > > > 1) probably unique > > 2) a identifier for the HI > > > > SHA1 will still supply property 1). > > > > As for property 2), I thought HIP was using a non-keyed SHA1 hash for > > HI=>HIT computation? Basically, HIP is using SHA1's "randomness" > > property > > to meet property 1), yes? In this case, there is nothing to break and > > property 2) holds as well. As for using keyed SHA1 for say, signing a > > packet or whatnot, then yes, looks like SHA256 will have to be used > > soon. > > Well, there is more in this. The HIT essentially works as a > channel binding, giving assurance to the application that when > it does connect(HIT) it actually gets a (secured) connection to > the identified host. From that point of view, if SHA-1 has a > weakness so that it becomes feasible to generate another (perhaps > very short) public key that hashes to the same HIT, we do have a > problem. My crypto understanding is too weak to be able to say > for sure, but my understanding is that it has became easier to > do that. > > I'm putting this up on the base spec slides for tomorrow. My > personal opinion is to move to HMAC and SHA-256. I don't know > if we want to change the HIT length in the HIP header at the > same time or not. Maybe, just for the sake. We could then use > the uppermost 128 bits of the HIT at the API, with the current > 01/10 restriction. The LSI would then probably use 24 top most > bits from the HIT instead of the 24 low bits, as now, but we are > moving LSIs away from the base spec probably anyway. > > --Pekka > > _______________________________________________ > 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 Mar 8 17:01:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24784 for ; Tue, 8 Mar 2005 17:01:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B224F731F; Tue, 8 Mar 2005 17:01:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id EE37B730F for ; Tue, 8 Mar 2005 17:00:55 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 50039212FE6; Wed, 9 Mar 2005 00:00:49 +0200 (EET) In-Reply-To: <1110316095.15384.36.camel@atcp01.americas.nokia.com> References: <42133673.5040907@piuha.net> <073b01c51928$36411bb0$ef01a996@gmp> <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> <1110316095.15384.36.camel@atcp01.americas.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Greg Perkins , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] SHA1 broken? To: Yogesh Prem Swami X-Mailer: Apple Mail (2.619.2) 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, 8 Mar 2005 16:01:29 -0600 Date: Tue, 8 Mar 2005 16:01:29 -0600 Content-Transfer-Encoding: 7bit > As far as SHA1 is concerned, I guess HITs (and HIP KE) are still quite > secure. The reason is that HITs are generated from the public keys, so > an attacker can potentially generate a string that will result in the > same HITs, however for the attacker to be able to make use of this > string she must must also be able to generate the private keys > corresponding to that string. Well, a potential problem is that HIP allows you to use very short keys as your public identifier. Hence, presumably, an attacker could just keep developing new short public key pairs until it finds one that matches with the colliding string. Alternatively, if the attacker can generate a large number of colliding strings, the effort of generating a matching key pair may be reduced from what it was assumed to be. So, to me it looks like that attacking HIP may indeed have become slightly easier than before. Apparently replacing the currently used simple hash with a HMAC is sufficient to plug the potential leak. Hence, if people are unwilling to move to SHA-256 or 256-bit HITs at this time, I don't see any need. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 8 17:28:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26436 for ; Tue, 8 Mar 2005 17:28:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1CD197315; Tue, 8 Mar 2005 17:28:03 -0500 (EST) 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 368967312 for ; Tue, 8 Mar 2005 17:27:44 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1D8nAp-0000w9-00; Tue, 08 Mar 2005 17:27:31 -0500 From: Tim Shepard To: Pekka Nikander Cc: Yogesh Prem Swami , Greg Perkins , hipsec@honor.trusecure.com Subject: Re: [Hipsec] SHA1 broken? In-reply-to: Your message of Tue, 08 Mar 2005 16:01:29 -0600. 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: Tue, 08 Mar 2005 17:27:31 -0500 Date: Tue, 08 Mar 2005 17:27:31 -0500 If I understand correctly the newly reported weaknesses in various hash functions, we have not yet seen a demonstration of a weakness that would allow an attacker to create a key pair that hashes to a HIT that you are using. MD5 weaknesses -------------- Collisions in md5 have been demonstrated, and more such pairs of md5 inputs that produce collisions can be easily generated. Furthermore, it has been shown is that you could generate a pair of RSA key pairs where the two public keys (of differing lengths if you like) both hash to the same md5 value. This can also be done (such a pair of key pairs can be found) if there is known (constant) prefix that will be prepended to the two keys before they are hashed. A constant suffix can also be appended to both, for once the hash function colides, it continues to colide as you append a constant suffix. The weaknesses in md5 that allow these attacks do not apply to SHA-1 (as far as I know as of today). SHA-1 weakness -------------- Brute-forcing SHA-1 was believed to have a 2^80 work factor, but now appears to have a 2^69 work factor. As was recently mentioned on an IETF mailing list, this is a situation where we can "walk" to a solution. (No panic and running around is needed at this time.) While this is considered a significant new development, the practical security of systems using SHA-1 are not immediately compromised. However the long-term suitability of SHA-1 is now in doubt. (And such doubt, by itself, is enough reason to deprecate the use of cryptographic algorithms.) Implications for HIP -------------------- For HIP I think we need to be able to handle longer HITs, and I think we need a way of encoding in the HIT itself (in an unambiguous way) what hash function it is that is supposed to demonstrate the binding of the HIT to a public key. (Otherwise, a weakness in one hash function might allow you to create a public key which can be "demonstrated" to be bound to a HIT that was created with a different hash function.) -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 Tue Mar 8 17:54:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28217 for ; Tue, 8 Mar 2005 17:54:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 893B67316; Tue, 8 Mar 2005 17:54:01 -0500 (EST) 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 424497315 for ; Tue, 8 Mar 2005 17:53:29 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j28MrUhl004793 for ; Tue, 8 Mar 2005 15:53:31 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ID200LXW29653@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Tue, 08 Mar 2005 15:53:30 -0700 (MST) Received: from [130.129.134.236] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ID20003629487@mail.sun.net> for hipsec@honor.trusecure.com; Tue, 08 Mar 2005 15:53:30 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] SHA1 broken? In-reply-to: To: hipsec@honor.trusecure.com Cc: Tim Shepard , Pekka Nikander , Yogesh Prem Swami , Greg Perkins Message-id: <200503082356.53783.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: Tue, 08 Mar 2005 23:56:53 +0100 Date: Tue, 08 Mar 2005 23:56:53 +0100 Content-Transfer-Encoding: 7BIT On Tuesday 08 March 2005 23:27, Tim Shepard wrote: > Implications for HIP > -------------------- > > For HIP I think we need to be able to handle longer HITs, and I > think we need a way of encoding in the HIT itself (in an > unambiguous way) what hash function it is that is supposed to > demonstrate the binding of the HIT to a public key. (Otherwise, a > weakness in one hash function might allow you to create a public > key which can be "demonstrated" to be bound to a HIT that was > created with a different hash function.) I concur with this. BTW if you looks at the HIPHI DNS RR format, it already encodes both the HIT algorithm and size. Also, I am wondering to what extent we might also want to include in the HI itself the algorithm used to verify it (e.g. RSA), like Tim's proposal for HITs, instead of just signalling this algorithm in the HOST_ID TLV. Or perhaps just say that the HI is the whole HOST_ID TLV... What does the WG think? --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 12:15:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27552 for ; Wed, 9 Mar 2005 12:15:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 2AA56732B; Wed, 9 Mar 2005 12:15:02 -0500 (EST) 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 B1B467305 for ; Wed, 9 Mar 2005 12:14:27 -0500 (EST) 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 JAA29228 for ; Wed, 9 Mar 2005 09:14:26 -0800 (PST) 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 j29HEQI17996 for ; Wed, 9 Mar 2005 09:14:26 -0800 (PST) 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); Wed, 9 Mar 2005 09:14:25 -0800 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 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> Thread-Topic: WG Review: Better-Than-Nothing Security (btns) Thread-Index: AcUkHXPeGGJ45jgtQcStDlwy2ck3OwArGozA From: "Ahrenholz, Jeffrey M" To: X-OriginalArrivalTime: 09 Mar 2005 17:14:25.0356 (UTC) FILETIME=[71A580C0:01C524CB] Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) 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, 9 Mar 2005 09:14:24 -0800 Date: Wed, 9 Mar 2005 09:14:24 -0800 Content-Transfer-Encoding: quoted-printable I wonder if opportunistic HIP could help out here. Originally, I think that Bob positioned HIP as a lightweight complement to IKE (draft-moskowitz-hip-00 section 3). -----Original Message----- From: IESG Secretary [mailto:iesg-secretary-reply@ietf.org]=20 Sent: Tuesday, March 08, 2005 11:15 AM To: IETF Announcement list Subject: WG Review: Better-Than-Nothing Security (btns)=20 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following=20 description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by=20 March 16.=20 +++ Better-Than-Nothing Security (btns) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group DESCRIPTION: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous keying for IPsec between two parties who do not have credentials suitable for the current profile of IKE. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to or profiles of IKE to enable this mode of IPsec. The goal of this relaxed varient of IPsec is to enable and encourage the use of network security where it has been difficult to deploy - notably, to enable simpler, more rapid deployment. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially otherc working groups to perform anonymous authentication at the IPsec layer and later cryptographically bind the IPsec association to application authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interact with application authentication protocols are out of scope for this working group. However, the interactions between this cryptographic channel binding and the IPsec PAD will be similar to those for the anonymous mode with no binding. This working group needs to consider the channel bindings use case when developing extensions to the PAD and SPD. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. AS such we need to consider what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing anonymous keing for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals over three IETF meetings: a) develop a framework document to describe the motivation and goals of these infrastructure-free variants of security protocols in general, and IPsec and IKE in specific b) develop an applicability statement, characterizing a reasonable set of threat models with relaxed assumptions suitable for infrastructure-free use, and describing the limits and conditions of appropriate use of infrastructure-free variants c) develop standards-track IKE extensions and/or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support anonymous keying for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document giving advice to IPsec implementers and higher-level protocol designers on the use of IPsec in securing higher-level protocols _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 15:36:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18085 for ; Wed, 9 Mar 2005 15:36:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6067A732D; Wed, 9 Mar 2005 15:36:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 2DCFF7314 for ; Wed, 9 Mar 2005 15:35:39 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF366212CB7; Wed, 9 Mar 2005 22:35:31 +0200 (EET) In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8e4686f7143576ff768097da222c1452@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) To: "Ahrenholz, Jeffrey M" X-Mailer: Apple Mail (2.619.2) 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, 9 Mar 2005 14:36:10 -0600 Date: Wed, 9 Mar 2005 14:36:10 -0600 Content-Transfer-Encoding: 7bit > I wonder if opportunistic HIP could help out here. Originally, I think > that Bob positioned HIP as a lightweight complement to IKE > (draft-moskowitz-hip-00 section 3). As a quick response: yes, from a functional point of view. However, many of the security folks do not want to consider HIP, they want to use IKEv2. I think the attitude is very rational from their point of view. In general, people are much more confident that IKEv2 is secure vs. whether HIP is secure or not. --Pekka > > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary-reply@ietf.org] > Sent: Tuesday, March 08, 2005 11:15 AM > To: IETF Announcement list > Subject: WG Review: Better-Than-Nothing Security (btns) > > > A new IETF working group has been proposed in the Security Area. > The IESG has not made any determination as yet. The following > description was submitted, and is provided for informational purposes > only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > March 16. > > +++ > > Better-Than-Nothing Security (btns) > =================================== > > Current Status: Proposed Working Group > > DESCRIPTION: > > Current Internet Protocol security protocol (IPsec) and Internet Key > Exchange protocol (IKE) present somewhat of an all-or-nothing > alternative; these protocols provide protection from a wide array of > possible threats, but are sometimes not deployed because of the need > for pre-existing credentials. There is significant interest in > providing > anonymous keying for IPsec > between two parties who do not have credentials suitable for the > current profile of IKE. This mode would protect against passive > attacks but would be vulnerable to active attacks. > The primary purpose of this working group is to specify > extensions to or profiles of IKE to enable this mode of IPsec. > The goal of this relaxed varient of IPsec is to enable and encourage > the > use of > network > security where it has been difficult to deploy - notably, to enable > simpler, more rapid deployment. > > Two related problems emerged during the discussion of this problem. > First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially > otherc > working groups to perform anonymous authentication at the IPsec layer > and later cryptographically bind the IPsec association to application > authentication. The specification of how this binding is performed > for IPsec and the specification of how the binding interact with > application authentication protocols are out of scope for this working > group. However, the interactions between this cryptographic channel > binding and the IPsec PAD will be similar to those for the anonymous > mode with no binding. This working group needs to consider the > channel bindings use case when developing extensions to the PAD and > SPD. > > Secondly, BTNS and the channel bindings work both encourage IPsec to > be used to secure higher layer protocols. AS such we need to consider > what information these higher layer protocols need from IPsec. > > Two proposals are under discussion for providing anonymous keing for > IPsec: bare RSA keys transported by IKE and self-signed certificates > transported by IKE. > > The WG has the following specific goals over three IETF meetings: > > a) develop a framework document to describe the motivation and > goals of these infrastructure-free variants of security protocols > in general, and IPsec and IKE in specific > > b) develop an applicability statement, characterizing a reasonable > set of threat models with relaxed assumptions suitable for > infrastructure-free use, and describing the limits and conditions > of appropriate use of infrastructure-free variants > > c) develop standards-track IKE extensions and/or profiles that > support one or both of the bare RSA keys or self-signed certificates > > d) Specify standards-track extensions to the SPD and PAD to > support anonymous keying for IPsec and cryptographic channel bindings > for IPsec > > e) Develop an informational document giving advice to IPsec > implementers and higher-level protocol designers on the use of > IPsec in securing higher-level protocols > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > 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 Mar 9 17:08:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25657 for ; Wed, 9 Mar 2005 17:08:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B0A897317; Wed, 9 Mar 2005 17:08:01 -0500 (EST) 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 545297314 for ; Wed, 9 Mar 2005 17:07:26 -0500 (EST) Received: from [130.129.134.37] (wireless-130-129-134-37.ietf62.ietf.org [130.129.134.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j29M6x614076; Wed, 9 Mar 2005 14:06:59 -0800 (PST) Message-ID: <422F737D.2010003@isi.edu> From: Yushun Wang User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> In-Reply-To: <8e4686f7143576ff768097da222c1452@nomadiclab.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020406020508090401010309" X-ISI-4-39-6-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, 09 Mar 2005 14:06:53 -0800 Date: Wed, 09 Mar 2005 14:06:53 -0800 This is a cryptographically signed message in MIME format. --------------ms020406020508090401010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> I wonder if opportunistic HIP could help out here. Originally, I think >> that Bob positioned HIP as a lightweight complement to IKE >> (draft-moskowitz-hip-00 section 3). > As a quick response: yes, from a functional point of view. > > However, many of the security folks do not want to consider HIP, > they want to use IKEv2. I think the attitude is very rational > from their point of view. In general, people are much more > confident that IKEv2 is secure vs. whether HIP is secure or not. My view is slightly different. To me the question is whether the concept of btns or anonsec applies to HIP or not, and whether HIP protocol specs _prevent_ the use of anonymous mode or other "less secure" modes. I am sure most would agree the answer is "yes" for the first question, though I am not familiar with HIP enough to offer definitive answers. As for IKE vs. HIP, the current focus of wg-to-be's effort is on IPsec, but it is entirely possible to have a doc on how to provide similar services in HIP. Of course I could only speak for myself on this matter. IMO this is another example to Tom's generalization draft. Apologize if I misunderstood Tom's draft, should've read it first. :-) I would really like to support Tom's effort to going through the HIP arch/spec and maybe relaxes certain MUSTs or MUST-NOTs in a manner that would not cause huge pain for inter-op tests for implementers, but would open the possibilities to support wider range of arch/services/ apps/etc. yushun >> -----Original Message----- >> From: IESG Secretary [mailto:iesg-secretary-reply@ietf.org] >> Sent: Tuesday, March 08, 2005 11:15 AM >> To: IETF Announcement list >> Subject: WG Review: Better-Than-Nothing Security (btns) >> >> >> A new IETF working group has been proposed in the Security Area. >> The IESG has not made any determination as yet. The following >> description was submitted, and is provided for informational purposes >> only. >> Please send your comments to the IESG mailing list (iesg@ietf.org) by >> March 16. >> >> +++ >> >> Better-Than-Nothing Security (btns) >> =================================== >> >> Current Status: Proposed Working Group >> >> DESCRIPTION: >> >> Current Internet Protocol security protocol (IPsec) and Internet Key >> Exchange protocol (IKE) present somewhat of an all-or-nothing >> alternative; these protocols provide protection from a wide array of >> possible threats, but are sometimes not deployed because of the need >> for pre-existing credentials. There is significant interest in providing >> anonymous keying for IPsec >> between two parties who do not have credentials suitable for the >> current profile of IKE. This mode would protect against passive >> attacks but would be vulnerable to active attacks. >> The primary purpose of this working group is to specify >> extensions to or profiles of IKE to enable this mode of IPsec. >> The goal of this relaxed varient of IPsec is to enable and encourage the >> use of >> network >> security where it has been difficult to deploy - notably, to enable >> simpler, more rapid deployment. >> >> Two related problems emerged during the discussion of this problem. >> First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially >> otherc >> working groups to perform anonymous authentication at the IPsec layer >> and later cryptographically bind the IPsec association to application >> authentication. The specification of how this binding is performed >> for IPsec and the specification of how the binding interact with >> application authentication protocols are out of scope for this working >> group. However, the interactions between this cryptographic channel >> binding and the IPsec PAD will be similar to those for the anonymous >> mode with no binding. This working group needs to consider the >> channel bindings use case when developing extensions to the PAD and >> SPD. >> >> Secondly, BTNS and the channel bindings work both encourage IPsec to >> be used to secure higher layer protocols. AS such we need to consider >> what information these higher layer protocols need from IPsec. >> >> Two proposals are under discussion for providing anonymous keing for >> IPsec: bare RSA keys transported by IKE and self-signed certificates >> transported by IKE. >> >> The WG has the following specific goals over three IETF meetings: >> >> a) develop a framework document to describe the motivation and >> goals of these infrastructure-free variants of security protocols >> in general, and IPsec and IKE in specific >> >> b) develop an applicability statement, characterizing a reasonable >> set of threat models with relaxed assumptions suitable for >> infrastructure-free use, and describing the limits and conditions >> of appropriate use of infrastructure-free variants >> >> c) develop standards-track IKE extensions and/or profiles that >> support one or both of the bare RSA keys or self-signed certificates >> >> d) Specify standards-track extensions to the SPD and PAD to >> support anonymous keying for IPsec and cryptographic channel bindings >> for IPsec >> >> e) Develop an informational document giving advice to IPsec >> implementers and higher-level protocol designers on the use of >> IPsec in securing higher-level protocols --------------ms020406020508090401010309 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 AxcwggKAoAMCAQICAw4K/TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTn ssgn3J00Mbb7NiBsaUnnnXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y 6JKoTOHDdLmgWbHy9L5EGUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuU D3yolypb0TKrUFWo8RUz2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421 dOlKsAmlA6gL1NmXw0bC8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY 6m1KAnGJzCz406bbDCxkRuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC 7vomxYXs2NfhoDt/cgado9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxR nPRYY+m+rU4n9bma6bdovN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAxcwggKAoAMCAQICAw4K /TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTnssgn3J00Mbb7NiBsaUnn nXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y6JKoTOHDdLmgWbHy9L5E GUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuUD3yolypb0TKrUFWo8RUz 2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421dOlKsAmlA6gL1NmXw0bC 8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY6m1KAnGJzCz406bbDCxk RuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC7vomxYXs2NfhoDt/cgad o9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxRnPRYY+m+rU4n9bma6bdo vN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 Dgr9MAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MDMwOTIyMDY1NFowIwYJKoZIhvcNAQkEMRYEFHSWVGBxZrUNpDMKE3AWbbDG vzndMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOCv0wegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDDgr9MA0GCSqGSIb3DQEBAQUABIIBAFIB+BBnwaRzYJq6vNIfbE2l1Eqcw83H9TBp 2yvwxtmwFkEvdwQhZsg2+FqDUiQ74N5Wb4DOOCaZDAC7hNO1cvO6cv7YE53GkdXSHY0haTcm Uv+WgtLLwygGBTu4C/ie104jYdodT7N39RBrSqBowpTFX+f2WY1HRik8U4PwQ/+6CfBJ9zJD O4y5nrM58u5o09UplyrRv/szGbPjKQ9Lbtw41MI70OegxVBKpqBAw/wBaLAz/dW/Xk1OSf+a 9NsYErtJhmh1/g980BPaI4GS19HqXhWsK6ZZrw1HA97n7urpRDS/zwXZ60rAteU9mjsjWxkG KqrISvCh+p6cqfK1ACwAAAAAAAA= --------------ms020406020508090401010309-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 17:28:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27179 for ; Wed, 9 Mar 2005 17:28:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1C7657317; Wed, 9 Mar 2005 17:28:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 2DF4E7314 for ; Wed, 9 Mar 2005 17:27:25 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4A189212CB7; Thu, 10 Mar 2005 00:27:23 +0200 (EET) In-Reply-To: <422F737D.2010003@isi.edu> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> <422F737D.2010003@isi.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) To: Yushun Wang X-Mailer: Apple Mail (2.619.2) 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, 9 Mar 2005 16:27:59 -0600 Date: Wed, 9 Mar 2005 16:27:59 -0600 Content-Transfer-Encoding: 7bit > My view is slightly different. To me the question is > whether the concept of btns or anonsec applies to > HIP or not, and whether HIP protocol specs _prevent_ > the use of anonymous mode or other "less secure" > modes. Well, as far as I can see, HIP-as-is does not specify anything else but a btns-like mode. HIP does have the CER packet type for carrying certificates, but how to use certificates is out of scope. Hence, base HIP only defines a protocol that provides the application assurance that the peer has access to the private key corresponding to the host identity, i.e., the public key. How the application gets the public key (or the corresponding HIT) is out of scope. So, I can't see how the HIP specs would prevent one from using "anonymous" or "less secure" mode. It even allows you to use very short public and Diffie-Hellman keys. > As for IKE vs. HIP, the current focus of wg-to-be's effort > is on IPsec, but it is entirely possible to have a doc on > how to provide similar services in HIP. Of course I could > only speak for myself on this matter. Well, what I am hoping from the anonsec effort is to get a standard interface to the SPD and PAD that would allow the KMP to push a hash of a public key down the stack and associate that with an SA. That would most probably make any HIP implementation easier, perhaps to the point that one could implement HIP on the "top" of existing IPsec without requiring any changes to the kernel. If that happens, we don't need any document on how to provide similar services with HIP, as they *are* already there. Taking two steps back, I really think that we should gradually inch ourselves towards a model where the application level identifiers have build-in channel bindings. HIP, when used with a HIT-based API, provides that. I think it would be good if IPsec supported that, too. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 18:06:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00345 for ; Wed, 9 Mar 2005 18:06:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id E11517317; Wed, 9 Mar 2005 18:06:01 -0500 (EST) 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 C86147314 for ; Wed, 9 Mar 2005 18:05:25 -0500 (EST) Received: from [130.129.134.37] (wireless-130-129-134-37.ietf62.ietf.org [130.129.134.37]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j29N50629869; Wed, 9 Mar 2005 15:05:00 -0800 (PST) Message-ID: <422F810F.9080806@isi.edu> From: Yushun Wang User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander , hipsec@honor.trusecure.com Subject: Re: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> <422F737D.2010003@isi.edu> <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> In-Reply-To: <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090801050908010008000808" X-ISI-4-39-6-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, 09 Mar 2005 15:04:47 -0800 Date: Wed, 09 Mar 2005 15:04:47 -0800 This is a cryptographically signed message in MIME format. --------------ms090801050908010008000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> My view is slightly different. To me the question is >> whether the concept of btns or anonsec applies to >> HIP or not, and whether HIP protocol specs _prevent_ >> the use of anonymous mode or other "less secure" >> modes. > Well, as far as I can see, HIP-as-is does not specify > anything else but a btns-like mode. HIP does have the > CER packet type for carrying certificates, but how to > use certificates is out of scope. Hence, base HIP only > defines a protocol that provides the application assurance > that the peer has access to the private key corresponding > to the host identity, i.e., the public key. How the > application gets the public key (or the corresponding HIT) > is out of scope. > > So, I can't see how the HIP specs would prevent one from > using "anonymous" or "less secure" mode. It even allows > you to use very short public and Diffie-Hellman keys. Thanks for the authoritative answers. :-) I stand corrected. >> As for IKE vs. HIP, the current focus of wg-to-be's effort >> is on IPsec, but it is entirely possible to have a doc on >> how to provide similar services in HIP. Of course I could >> only speak for myself on this matter. > Well, what I am hoping from the anonsec effort is to get > a standard interface to the SPD and PAD that would allow > the KMP to push a hash of a public key down the stack and > associate that with an SA. That would most probably make > any HIP implementation easier, perhaps to the point that > one could implement HIP on the "top" of existing IPsec > without requiring any changes to the kernel. If that happens, > we don't need any document on how to provide similar services > with HIP, as they *are* already there. Agree on this. Let's keep our fingers crossed... yushun > Taking two steps back, I really think that we should gradually > inch ourselves towards a model where the application level > identifiers have build-in channel bindings. HIP, when used > with a HIT-based API, provides that. I think it would be good > if IPsec supported that, too. --------------ms090801050908010008000808 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 AxcwggKAoAMCAQICAw4K/TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTn ssgn3J00Mbb7NiBsaUnnnXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y 6JKoTOHDdLmgWbHy9L5EGUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuU D3yolypb0TKrUFWo8RUz2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421 dOlKsAmlA6gL1NmXw0bC8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY 6m1KAnGJzCz406bbDCxkRuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC 7vomxYXs2NfhoDt/cgado9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxR nPRYY+m+rU4n9bma6bdovN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAxcwggKAoAMCAQICAw4K /TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDUwMjE1MjIyMDQ0WhcNMDYwMjE1MjIyMDQ0WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpbzTnssgn3J00Mbb7NiBsaUnn nXeJKrXZM5bDChNw3BZcmZKQwKQA1EZqc10z0AOhg6azfLhKJK2Y6JKoTOHDdLmgWbHy9L5E GUi2+hWh39nXPqlnk+MMWH+nmWBW2mr5E5n+vHrCS7kp6mr2QGuUD3yolypb0TKrUFWo8RUz 2N+0GRz3MXquyLLm2twIn4pAgxbI8gnkba9LLWfA+fKkpyAx2421dOlKsAmlA6gL1NmXw0bC 8o3tNvxxlvJK9Y3G61/wpo4bbHRtVUDbk3evv+NHwNOHb8MZzIEY6m1KAnGJzCz406bbDCxk RuKJkX5a0Srx8gyQNfmpmbLShHJtAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQCe4GN9Ke0+xslYMGSeJWrLNujx4ecZ48emfbWgnEfdAP77HKQC7vomxYXs2NfhoDt/cgad o9v7sgRqPen/lUYCwneXM0O9dcsWqfCGBH3iEcDQsr1eX+PhQbxRnPRYY+m+rU4n9bma6bdo vN4CA1VAg7cI8lrp4sDuRU8frC7bDjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw 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 Dgr9MAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA1MDMwOTIzMDQ0N1owIwYJKoZIhvcNAQkEMRYEFHHjGHY1MubHywLyM/0YQaLu MbynMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOCv0wegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDDgr9MA0GCSqGSIb3DQEBAQUABIIBAHt2eCbMmtvUViR+aFVIb+x/fdUZqKQORZe9 NckCntKsIugLVai5dlXjQLBYyEwSaL4PrajkYUKCqLacIYMJ/BpQkPEHdx817q0WZtf3Rr87 CYd+LB/KbBe4TnNcgY9qWuHB2czwsD85a2BerqrfLswfyHgcLA7ADW5k1+OAHpceXsdT+oAA 4KpejXsamu4kloYdk136N3Hq3KvgBLkbpcpczueeroRflEbbCE/CU1/FE/p8ofG6eSapFUxH g3MmaBvhFZYBrZ6X/NB3h8AO3EwU13Cxq5kkQmI0usEJ2Gy9EBgOdQa6Er9u8ZBDn3HGvSpo 53xqKvscVgmKbjh33bIAAAAAAAA= --------------ms090801050908010008000808-- _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 18:21:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02554 for ; Wed, 9 Mar 2005 18:21:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5951A7317; Wed, 9 Mar 2005 18:21:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by honor.icsalabs.com (Postfix) with ESMTP id 8EF7F7314 for ; Wed, 9 Mar 2005 18:20:28 -0500 (EST) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id j29NKNbj009043; Wed, 9 Mar 2005 17:20:23 -0600 (CST) Received: from [138.85.4.84] (EFO9N000L5C7100 [138.85.4.84]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GFFNSBAX; Wed, 9 Mar 2005 17:20:23 -0600 Message-ID: <422F84B5.8050209@ericsson.com> X-Sybari-Trust: f9f82225 b8ec86c7 df03d347 00000139 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HIP Cc: David Ward Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Null IPsec 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, 10 Mar 2005 01:20:21 +0200 Date: Thu, 10 Mar 2005 01:20:21 +0200 Content-Transfer-Encoding: 7bit Folks, during today's meeting, the chairs got an action point to talk to the security ADs about the possibility of having a MUST implement IPsec with null encryption and/or null integrity protection. I talked to Russ, and his gut reaction was that null encryption with integrity may be fine, but he would need to see the use case people have in mind before accepting null encryption and null integrity. Gonzalo _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 19:07:31 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06516 for ; Wed, 9 Mar 2005 19:07:31 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 97CF37332; Wed, 9 Mar 2005 19:07:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from pollux.ietf62.ietf.org (smtp.ietf62.ietf.org [130.129.16.13]) by honor.icsalabs.com (Postfix) with ESMTP id 46AC27317 for ; Wed, 9 Mar 2005 19:06:51 -0500 (EST) Received: from [127.0.0.1] (wired-130-129-66-215.ietf62.ietf.org [130.129.66.215]) by pollux.ietf62.ietf.org (Postfix) with ESMTP id 8B07D3C; Wed, 9 Mar 2005 16:06:45 -0800 (PST) Message-ID: <422F8F87.6080007@tm.uka.de> From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com, Julien.Laganier@Sun.COM Cc: tm-ro2@tm.uka.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Time Window Instead of CBA? 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, 09 Mar 2005 18:06:31 -0600 Date: Wed, 09 Mar 2005 18:06:31 -0600 Content-Transfer-Encoding: 7bit Hi Julien, hi all. Julien came to the microphone after my presentation today, but we didn't have enough time to go into his comment to the extent due. The question was whether we could not just allow a correspondent node to send packets to an unverified locator for a certain time window instead of using Credit-Based Authorization. Intuitively, one would say that this time window should be one RTT, which is what a reachability verification takes. However, since the RTT for a new locator may be completely different than a previously computed RTT, one would probably end up using a higher, constant value. (Besides, it is not clear where to get the RTT from at the IP layer. Transport-layer protocols may compute the RTT, but usually do not reset this value upon a handover.) Anyway, no matter what lifetime we pick for an unverified locator, the question is: What would prevent an attacker to re-register an unverified locator again and again? One may argue that the correspondent node could require a successful reachability verification before allowing a mobile node to register a new unverified locator. But that might cause DoS against an upright mobile node that moves quickly enough such that a new locator becomes stale before it can be verified. Without getting too much into this, I hope this makes clear that finding a feasible heuristic for the correspondent node is not easy. There is also some text (section 5.8) in draft-irtf-mobopts-ro-enhancements-00.txt. And I had a slide on this in my presentation which I had to skip in the interest of time. (The slides are posted.) I guess that, in summary, it's feasible to say that heuristics quickly become more complex than Credit-Based Authorization. After all, CBA is really not much from an implementation perspective: It's just some byte counting when a packet is received, and checking the current credit balance when a packet is to be sent to an unverified locator. Note that one does not need a timer to realize credit aging. Maybe, other folks have a comment on this as well. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 20:46:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14592 for ; Wed, 9 Mar 2005 20:46:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 66D7A733A; Wed, 9 Mar 2005 20:46:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by honor.icsalabs.com (Postfix) with ESMTP id 898C4732B for ; Wed, 9 Mar 2005 20:45:39 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D12A289853; Thu, 10 Mar 2005 03:45:36 +0200 (EET) Message-ID: <422FA6D0.6080609@piuha.net> From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Cc: hipsec@honor.trusecure.com, Julien.Laganier@Sun.COM, tm-ro2@tm.uka.de Subject: Re: [Hipsec] Time Window Instead of CBA? References: <422F8F87.6080007@tm.uka.de> In-Reply-To: <422F8F87.6080007@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-15; 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, 10 Mar 2005 03:45:52 +0200 Date: Thu, 10 Mar 2005 03:45:52 +0200 Content-Transfer-Encoding: 7bit Christian Vogt wrote: > Without getting too much into this, I hope this makes clear that > finding a feasible heuristic for the correspondent node is not easy. > There is also some text (section 5.8) in > draft-irtf-mobopts-ro-enhancements-00.txt. And I had a slide on this > in my presentation which I had to skip in the interest of time. (The > slides are posted.) > > I guess that, in summary, it's feasible to say that heuristics quickly > become more complex than Credit-Based Authorization. After all, CBA > is really not much from an implementation perspective: It's just some > byte counting when a packet is received, and checking the current > credit balance when a packet is to be sent to an unverified locator. > Note that one does not need a timer to realize credit aging. I agree. --Jari _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 9 22:19:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23687 for ; Wed, 9 Mar 2005 22:19:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 75BF77330; Wed, 9 Mar 2005 22:19:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from pollux.ietf62.ietf.org (pollux.ietf62.ietf.org [130.129.16.13]) by honor.icsalabs.com (Postfix) with ESMTP id 5A03D732D for ; Wed, 9 Mar 2005 22:18:18 -0500 (EST) Received: from [127.0.0.1] (wireless-130-129-131-96.ietf62.ietf.org [130.129.131.96]) by pollux.ietf62.ietf.org (Postfix) with ESMTP id CB18742 for ; Wed, 9 Mar 2005 19:18:17 -0800 (PST) Message-ID: <422FBC76.4060800@tm.uka.de> From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] CBA Presentation Slides 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, 09 Mar 2005 21:18:14 -0600 Date: Wed, 09 Mar 2005 21:18:14 -0600 Content-Transfer-Encoding: 7bit Hi all, Gonzalo just posted a PDF of my presentation slides. I serialized the animations in it, making it more readable. http://hip.piuha.net/meetings/ietf62/agenda.html - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 10 10:47:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27337 for ; Thu, 10 Mar 2005 10:47:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6CD8F7324; Thu, 10 Mar 2005 10:47:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by honor.icsalabs.com (Postfix) with SMTP id B93DC7323 for ; Thu, 10 Mar 2005 10:46:49 -0500 (EST) Received: from port3490-new.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Thu, 10 Mar 2005 10:46:47 -0500 Message-Id: <6.2.1.2.2.20050310103704.0512ea18@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: HIP From: Robert Moskowitz In-Reply-To: <422F84B5.8050209@ericsson.com> References: <422F84B5.8050209@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rcpt-To: Subject: [Hipsec] Weighing in on hash truncation 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, 10 Mar 2005 10:46:32 -0600 Date: Thu, 10 Mar 2005 10:46:32 -0600 Content-Transfer-Encoding: quoted-printable Most of the work on hash truncation came from Hugo's work back in '95. So= =20 I went to the source. I am asking him about the pre-image attack (find (x,y) where H9x) =3D H(y)). But I am not sure the security risk of the pre-image attack. The only case= =20 I can see is Malice got hired to create a HI for a public server. But=20 Malice creates a HI with a collision and walks off with the collision and=20 sets up his own version of this server. Date: Thu, 10 Mar 2005 01:26:16 +0200 (IST) From: Hugo Krawczyk To: Robert Moskowitz Subject: Re: Truncating Hashes in this new world weakened hashes In-Reply-To: <6.2.1.2.2.20050309141335.038a1b40@localhost> Message-ID:=20 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=3DUS-ASCII I am not familiar with HIP. If the application uses the one-way (or second pre-image) property of SHA-1 (namely, given a pair (x,H(x)) find y such that H(x)=3DH(y)), then SHA-1 is still secure for all we know even if you truncate the output moderately (say to 96 or more bits). In particular this is the case if in the application the attacker does not have control of the public key (but rather needs to find another public key that hashes to the same value). Assuming that indeed the issue in your application is one-wayness and not collisions then I do not see a reason to move immediately to SHA-256. It would be better to see how well the available techniques can be stretched to work against the one-wayness of SHA-1. Indeed, breaking one-wayness is a much harder problem with more safety margins since the basic brute force attack takes 2^160 rather than 2^80 (even if you truncate to 128 bits the brute force attack takes 2^128) and therefore a new attack will have to be about 2^50 times faster to be of any practical value. Hugo On Wed, 9 Mar 2005, Robert Moskowitz wrote: > Hugo, > > I greatly need some supporting information on the strengths of truncated > hashes. > > This question is coming for the work in HIP > > www.ietf.org/internet-drafts/draft-ietf-hip-arch-02.txt > www.ietf.org/internet-drafts/draft-ietf-hip-base-02.txt > > The Host Identity is a Public Key, (RSA or DSA) > > But you don't want to use a variable length field in the ways needed in > HIP, thus we truncate a hash of the public key at 126 bits.Currently > SHA-1 is used for the hashing.And there is concern about the long term > use of SHA-1 here. > > But since this is a truncation of a hash, some wonder if going to SHA-256 > will actually be more secure. > > It seems to me that the attacks are to create hash collisions, not > truncated hash collisions.Thus it is not a matter of the length of the > truncation (within reason) as it is the collisions with the hash itself. > > Can you point me to any information on this? > > Robert Moskowitz "Perfection is achieved not when there is nothing more to add, but rather, when there is nothing left to take away" Antoine de Saint-Exup=E9ry (1900-1944) _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 10 12:38:33 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10045 for ; Thu, 10 Mar 2005 12:38:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 752357323; Thu, 10 Mar 2005 12:38:02 -0500 (EST) 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 7FF157314 for ; Thu, 10 Mar 2005 12:37:45 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2AHbeX8010182 for ; Thu, 10 Mar 2005 10:37:40 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ID500819CYR9O@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 10 Mar 2005 10:37:40 -0700 (MST) Received: from [130.129.134.236] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ID5000Y6CYR8A@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 10 Mar 2005 10:37:39 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] Time Window Instead of CBA? In-reply-to: <422FA6D0.6080609@piuha.net> To: Jari Arkko Cc: Christian Vogt , hipsec@honor.trusecure.com, tm-ro2@tm.uka.de Message-id: <200503101841.10575.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.7 References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@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: Thu, 10 Mar 2005 18:41:10 +0100 Date: Thu, 10 Mar 2005 18:41:10 +0100 Content-Transfer-Encoding: 7BIT On Thursday 10 March 2005 02:45, Jari Arkko wrote: > Christian Vogt wrote: > > > > I guess that, in summary, it's feasible to say that heuristics > > quickly become more complex than Credit-Based Authorization. > > After all, CBA is really not much from an implementation > > perspective: It's just some byte counting when a packet is > > received, and checking the current credit balance when a packet > > is to be sent to an unverified locator. Note that one does not > > need a timer to realize credit aging. > > I agree. Right. After discussing more with Christian I now agree too. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 10 14:17:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20531 for ; Thu, 10 Mar 2005 14:17:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EF5E2732A; Thu, 10 Mar 2005 14:17:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 5522D7329 for ; Thu, 10 Mar 2005 14:16:44 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7F56A212CB7; Thu, 10 Mar 2005 21:16:41 +0200 (EET) In-Reply-To: <422FA6D0.6080609@piuha.net> References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@piuha.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Christian Vogt , tm-ro2@tm.uka.de From: Pekka Nikander Subject: Re: [Hipsec] Time Window Instead of CBA? To: hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619.2) 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, 10 Mar 2005 13:16:40 -0600 Date: Thu, 10 Mar 2005 13:16:40 -0600 Content-Transfer-Encoding: 7bit >> It's just some byte counting when a packet is received, and checking >> the current credit balance when a packet is to be sent to an >> unverified locator. Note that in the case of HIP most of the required machinery is already there, as the ESP SAs keep a count on bytes anyway. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 10 14:33:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22337 for ; Thu, 10 Mar 2005 14:33:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 52DEA732A; Thu, 10 Mar 2005 14:33:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from pollux.ietf62.ietf.org (pollux.ietf62.ietf.org [130.129.16.13]) by honor.icsalabs.com (Postfix) with ESMTP id 01F447329 for ; Thu, 10 Mar 2005 14:32:43 -0500 (EST) Received: from [127.0.0.1] (wireless-130-129-131-96.ietf62.ietf.org [130.129.131.96]) by pollux.ietf62.ietf.org (Postfix) with ESMTP id 365583C; Thu, 10 Mar 2005 11:32:42 -0800 (PST) Message-ID: <4230A0D6.80005@tm.uka.de> From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: hipsec@honor.trusecure.com, tm-ro2@tm.uka.de Subject: Re: [Hipsec] Time Window Instead of CBA? References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@piuha.net> In-Reply-To: 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: Thu, 10 Mar 2005 13:32:38 -0600 Date: Thu, 10 Mar 2005 13:32:38 -0600 Content-Transfer-Encoding: 7bit Yes, you can re-use code that exists anyway. Likewise, in our CBA implementation for Mobile IPv6, we use a correspondent node's Binding Cache to store the IP-address state (verified, unverified) and a byte counter for each registered mobile node. You can do similar things for HIP mobility as well. - Christian Pekka Nikander wrote: >>> It's just some byte counting when a packet is received, and checking >>> the current credit balance when a packet is to be sent to an >>> unverified locator. > > > Note that in the case of HIP most of the required machinery is already > there, as the ESP SAs keep a count on bytes anyway. > > --Pekka -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 11 10:28:43 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03951 for ; Fri, 11 Mar 2005 10:28:43 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C47A7733F; Fri, 11 Mar 2005 10:28:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 85AA3732E; Fri, 11 Mar 2005 10:27:25 -0500 (EST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id CC651212CBC; Fri, 11 Mar 2005 17:27:12 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4727b872bed44442a7644919dc8007ab@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Aaron Falk From: Pekka Nikander To: hipsec-rg@honor.trusecure.com, hipsec@honor.trusecure.com X-Mailer: Apple Mail (2.619.2) Subject: [Hipsec] HIP RG today starts at 1230, not 1300 as listed in Agenda 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, 11 Mar 2005 09:27:10 -0600 Date: Fri, 11 Mar 2005 09:27:10 -0600 Content-Transfer-Encoding: 7bit The agenda lists the HIP RG to start at 1300, and lists last meeting's agenda. However, we *are* starting already at 1230, not 1300 as listed. See the archive for the proposed agenda: http://honor.trusecure.com/pipermail/hipsec-rg/2005-February/000146.html Tom is back home so I will be chairing. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 11 16:50:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10838 for ; Fri, 11 Mar 2005 16:50:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B47CF730C; Fri, 11 Mar 2005 16:50:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from mx2.grc.nasa.gov (mx2.grc.nasa.gov [128.156.11.69]) by honor.icsalabs.com (Postfix) with ESMTP id BB36172F4 for ; Fri, 11 Mar 2005 16:49:01 -0500 (EST) Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 0B215C220 for ; Fri, 11 Mar 2005 16:49:05 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j2BLn4Rs014325 for ; Fri, 11 Mar 2005 16:49:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j2BLn4QY004949 for ; Fri, 11 Mar 2005 16:49:04 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 27237-26 for ;Fri, 11 Mar 2005 16:49:04 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j2BLn2I 7004934for ; Fri, 11 Mar 2005 16:49:02 -0500 (E ST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 6BD8F33800F; Fri, 11 Mar 2005 16:49:02 -0500 (EST) Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [6 8.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTP id C0B3033800Dfo r ; Fri, 11 Mar 2005 16:49:01 -0500 (EST) Message-ID: <42321250.7030609@grc.nasa.gov> From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hip Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.nasa.gov Subject: [Hipsec] NAT traversal and cellular network administrative filtering 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, 11 Mar 2005 16:49:04 -0500 Date: Fri, 11 Mar 2005 16:49:04 -0500 Content-Transfer-Encoding: 8bit Please excuse the cross-post. This week I sat in 4 IETF sessions that all where discussing very similar, if not the same, problem of NAT traversal. HIP, MIP6 and NEMO where generally discussing 6 to 4 tunneling issues and the need to address NATs. MIP4 was not concerned with 6 to 4 tunneling, just NAT traversal in general. I have used Cisco’s mobile networking MIP4 code with NAT traversal and Cisco’s (draft-thubert-nemo-ipv4-traversal-01 - expired) Doors 6 to 4 UDP-base tunneling NAT traversal code. Both work, but here is something to be aware of. About 18 months ago we noticed T-Mobile began administratively filtering traffic. The end result is that traffic that does not originate from the T-Mobile network gets blocked. They appear to be using ports to map the traffic. Thus, and IP-in-IP tunnel gets blocked even though the initial traffic came from within T-Mobile’s network (no ports to map to for IP-in-IP tunnels). UDP tunnels operate over this. That is why we used T-Mobile’s links for an mobile-ipv6 demonstration. The Doors implementation could handle this. (See: http://roland.grc.nasa.gov/~ivancic/ICNS2004_Demo/ICNS2004_Demo.htm) Sprint and Verizon may have recently started administratively filtering data – similar result as NATing even though you have unchanged public address space. One way to cope with this is UDP-in-IP tunneling, the same as with NAT traversal code. NOTE: Depending on the implementation, you may have to force UDP tunneling, because the address is not changing (CoA and actual address). Thus, there is no easy way to auto-sense that you are getting administratively filtered. I suspect this will break a lot of implementations for NAT traversal – as this really isn’t NAT traversal, but “weak” firewall traversal. I spoke to T-Mobile when this first started happening (actually found the right person). They said that the filtering was put into place to eliminate worms probing the networks. The filtering was done no so much for security as to protect the valuable RF bandwidth. T-Mobile is GPRS and you really get somewhere around 30 kbps in practice. Sprint and Verizon are 1xRTT and get around 40 to 60 kbps in practice. Thus, worms were starting to effect the usable bandwidth and QoS – or at least that was the fear. Thus, I agree with their security implementations as the reasoning appears valid. See this URL for the T-Mobile problem: http://roland.grc.nasa.gov/~ivancic/t-mobile http://roland.grc.nasa.gov/~ivancic/t-mobile/Letter_Customer_Service.pdf http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pdf NATs breaks a lot of things. Security breaks the rest! J Will Ivancic _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Mar 14 11:52:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22142 for ; Mon, 14 Mar 2005 11:52:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 42AEF7303; Mon, 14 Mar 2005 11:52:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by honor.icsalabs.com (Postfix) with ESMTP id 6EDA872EA for ; Mon, 14 Mar 2005 11:51:51 -0500 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j2EGpmPY006188 for ; Mon, 14 Mar 2005 11:51:48 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id AADC83C8179 for ; Mon, 14 Mar 2005 11:49:17 -0500 (EST) Received: from gmp (dhcp239.Research.Panasonic.COM [150.169.1.239])by redwood.research.panasonic.com (Postfix) with SMTP id A03833C816Bfor ; Mon, 14 Mar 2005 11:49:17 -0500 (EST) Message-ID: <00fb01c528b8$488de740$ef01a996@gmp> From: "Greg Perkins" To: References: <200503082356.53783.julien.laganier@sun.com> Subject: Re: [Hipsec] SHA1 broken? MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:12 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) 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, 14 Mar 2005 12:07:20 -0500 Date: Mon, 14 Mar 2005 12:07:20 -0500 Content-Transfer-Encoding: 7bit If you add a check that the RSA public key (the HI) must be of at least a certain length then this attack stays very difficult because key generation is a O(n^4) operation. I have yet to get the details on this new SHA1 attack but can elaborate on this further when I do. I do agree that the encoding should include a few semantic bits, like Pekka discussed at the meeting. I'd like these to include not only the hash algorithm and bit length, but also the ability to define alternative identifiers. For instance, if we goto a 256 identifier I can reasonably argue that using ECC would be a pretty good idea since the public keys are currently 160 bits and thus no need to have a 'middle-man' HIT identifier (ECC usage has IPR implications, which is typically why it is shunned, as discussed earlier. Just using it as an example and maybe if we asked Certicom nicely they'd let HIP use their ECC method for free. I can think of a few business reasons why they might do that). Another alternative is to use symmetric cyphers (AES, ect.). Basically, one can use a random value as a 'hip session identifier' and then encrypt it using the current session key. This new step would be part of the protocol but has pretty drastic implications for LSI use. This is probably the only way to minimize the bits used by an identifier while maintaining strong security (hmmm, since both values, the random identifier and a session key are unknown to an attacker, one should be able to just use a XOR mask, thus 96 bits get you 2^96 security - but there is no persistence across sessions, like an HIT has). I imagine this idea was discussed before and that hashed HIs to generate HITs was decided to be better (always seemed better to me, but if you really want to minimize packet headers, seems we would need to use something like this). I have to think on this. Maybe it would be better to leave the IP source addr to it's typically usage and add a 64 or 96 bit session identifier field to HIP headers that is masked by a random session key? Greg ----- Original Message ----- From: "Julien Laganier" To: Cc: "Tim Shepard" ; "Pekka Nikander" ; "Yogesh Prem Swami" ; "Greg Perkins" Sent: Tuesday, March 08, 2005 5:56 PM Subject: Re: [Hipsec] SHA1 broken? > On Tuesday 08 March 2005 23:27, Tim Shepard wrote: > > > > > Implications for HIP > > -------------------- > > > > For HIP I think we need to be able to handle longer HITs, and I > > think we need a way of encoding in the HIT itself (in an > > unambiguous way) what hash function it is that is supposed to > > demonstrate the binding of the HIT to a public key. (Otherwise, a > > weakness in one hash function might allow you to create a public > > key which can be "demonstrated" to be bound to a HIT that was > > created with a different hash function.) > > I concur with this. BTW if you looks at the HIPHI DNS RR format, it > already encodes both the HIT algorithm and size. > > Also, I am wondering to what extent we might also want to include in > the HI itself the algorithm used to verify it (e.g. RSA), like Tim's > proposal for HITs, instead of just signalling this algorithm in the > HOST_ID TLV. > > Or perhaps just say that the HI is the whole HOST_ID TLV... > > What does the WG think? > > --julien > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 15 03:12:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14676 for ; Tue, 15 Mar 2005 03:12:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 39E44730B; Tue, 15 Mar 2005 03:12:02 -0500 (EST) 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 C75AA7303 for ; Tue, 15 Mar 2005 03:11:43 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7E1FA2DD4; Tue, 15 Mar 2005 10:11:44 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DD5DC2D40 for ; Tue, 15 Mar 2005 10:11:43 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2F8Bh014442; Tue, 15 Mar 2005 10:11:43 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-niksula20040914 Subject: [Hipsec] about interops and the use of asymmetric 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: Tue, 15 Mar 2005 10:11:43 +0200 (EET) Date: Tue, 15 Mar 2005 10:11:43 +0200 (EET) We organized interops during IETF62 at Minneapolis with InfraHIP, Boeing and Ericsson implementations. We tested some "new" features, like RSA and AES support in the base exchange. We also tested the UPDATE procotol. The base exchange interop tests were successful and UPDATE interops were less successful (due to the excessive number of the ways the UPDATE can be used). We have communicated some implementation related nits directly to Petri, and hope that they will be applied if seem fit. There was one interesting thing that perhaps is worth mentioning on the mailing list. We successfully interoperated a base exchange where one end was using DSA and the other was using RSA. It works if both ends are careful in the selection of the source host id to be used for outgoing packets. Basically, the I1 packet fixes the initiator and responder host ids to be used in the rest of the communication in the non-opportunistic mode. Doing otherwise resulted in problems in the interops. I suggest mentioning this explicitly in the draft. Also, I suggest a small addition in section 6.2.17 (NOTIFY) for future extensions that define new host id algorithms. There should be a specific NOTIFY message type for signalling that a specific host id algorithm is not supported for a host. Or perhaps the AUTHENTICATION_FAILED suffices for this? -- 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 Mar 17 11:24:39 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20325 for ; Thu, 17 Mar 2005 11:24:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 1BEFD72F5; Thu, 17 Mar 2005 11:24:02 -0500 (EST) 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 4EE4E72E0 for ; Thu, 17 Mar 2005 11:23:37 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1DBxmW-0006pb-00 for ; Thu, 17 Mar 2005 11:23:32 -0500 From: Tim Shepard To: hipsec@honor.trusecure.com Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) 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, 17 Mar 2005 11:23:32 -0500 Date: Thu, 17 Mar 2005 11:23:32 -0500 I said and have been been quoted as saying: > > > Implications for HIP > > > -------------------- > > > > > > For HIP I think we need to be able to handle longer HITs, and I > > > think we need a way of encoding in the HIT itself (in an > > > unambiguous way) what hash function it is that is supposed to > > > demonstrate the binding of the HIT to a public key. (Otherwise, a > > > weakness in one hash function might allow you to create a public > > > key which can be "demonstrated" to be bound to a HIT that was > > > created with a different hash function.) After discussing this with a number of people at IETF62 who are more of a cryptographer than I am, I am now not certain that we need to make HITs any longer than they are now. It may be reasonable to have only around 120 bits of hash function output incorporated into the HIT. If that is secure enough, there may be significant advantages to keeping HITs at a fixed length of 128 bits. My understanding now is that 80 bits of good hash function output is sufficient today, and with a simpleminded extrapolation of needing another bit every 18 months (for Moore's law), 120-bits of good hash function output should be good until around the year 2065. So perhaps we can save extending the HIT to be greater than 128 bits for some future rev of the relevant protocols. (Or are we trying to design protocols that will last for a 100 years or more?) I do however still believe that we need an unambiguous tag in the HIT that tells you how it was generated (which hash function was used, and perhaps how it was used). IMHO we need at least four bits of such a tag, and preferably a few more than that. And there's also the desire some have to squeeze HITs into the IPv6 unicast address space somewhere so that they can be passed across IPv6 related APIs, so that may burn a few top bits of the HIT. -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 Thu Mar 17 13:55:32 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06499 for ; Thu, 17 Mar 2005 13:55:31 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id ED5FD7302; Thu, 17 Mar 2005 13:55:01 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by honor.icsalabs.com (Postfix) with ESMTP id 2E96172F5 for ; Thu, 17 Mar 2005 13:54:57 -0500 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j2HIsr3j011143 for ; Thu, 17 Mar 2005 13:54:53 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 1D4133C8168 for ; Thu, 17 Mar 2005 13:52:21 -0500 (EST) Received: from gmp (dhcp239.Research.Panasonic.COM [150.169.1.239])by redwood.research.panasonic.com (Postfix) with SMTP id 13B2B3C8157for ; Thu, 17 Mar 2005 13:52:21 -0500 (EST) Message-ID: <01c501c52b24$ff6f52f0$ef01a996@gmp> From: "Greg Perkins" To: References: Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) 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, 17 Mar 2005 14:10:35 -0500 Date: Thu, 17 Mar 2005 14:10:35 -0500 Content-Transfer-Encoding: 7bit I mostly agree with this but there may be an issue with long-term HI/HIT use. I like the idea of having a long-term HI, one I can hand-out because it will last years. In such a use-case it would be a pain if someone managed to duplicate my HIT and thus I'd be forced to make a new HI/HIT and hand it out all over again. I don't consider this critical but it would be nice if a HI could last for a long period of time IMO. Also, I have started to consider whether or not it is a good idea to use an HIT in the HIP exchange/control packets. The use of a random HIP session identifier (around 64-96 bits in length) might work out better. During the base exchange you'd have to send your HI in the I2 packet. The R2 packet would contain a session key to be used to mask your HIP session identifier. The SPI index is then used to decrypt the encrypted HIP session indentifier, that is included in every HIP packet header. The HIP session identifier (HSI) can then be used as the pointer to the HI and also as an index for applications. I am still mulling this over, and am really just being a devil's advocate atm because I like HITs because of their cryptographic link to the HI. But, a HSI has the following benefits: - an HSI is a temporary value so even if an attacker attains one he can only do harm to the current HIP session - fewer bits needed for identifier. 64 bits would be more than enough because the value is session oriented and thus discarded after use. Therefore, we could use 64 bits of the IPv6 source address space for an HSI and use the other 64 bits for other uses like LSIs. - using an XOR mask is a cheap yet strong method for protecting the HSI. - for legacy applications you could probably make the HSI an IP address, though I don't know how HIP could be signaled so that it does this in an appropriate way (security gets thrown away of course) In this scenario a HIT is used mainly for lookup at the DNS (or wherever) and thus can use 128 or 256 bit hash as needed. I now await a counter-argument in support of HITs. The crypto-graphic link to an HI is the strong-point IMO but with hashes under heavy attack, such a link may not be all that secure. Thus, we either need more bits, live with less security or maybe use a different identifier. Greg ----- Original Message ----- From: "Tim Shepard" To: Sent: Thursday, March 17, 2005 11:23 AM Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) > > I said and have been been quoted as saying: > > > > > Implications for HIP > > > > -------------------- > > > > > > > > For HIP I think we need to be able to handle longer HITs, and I > > > > think we need a way of encoding in the HIT itself (in an > > > > unambiguous way) what hash function it is that is supposed to > > > > demonstrate the binding of the HIT to a public key. (Otherwise, a > > > > weakness in one hash function might allow you to create a public > > > > key which can be "demonstrated" to be bound to a HIT that was > > > > created with a different hash function.) > > After discussing this with a number of people at IETF62 who are > more of a cryptographer than I am, I am now not certain that we > need to make HITs any longer than they are now. It may be > reasonable to have only around 120 bits of hash function output > incorporated into the HIT. > > If that is secure enough, there may be significant advantages to > keeping HITs at a fixed length of 128 bits. > > My understanding now is that 80 bits of good hash function output is > sufficient today, and with a simpleminded extrapolation of needing > another bit every 18 months (for Moore's law), 120-bits of good hash > function output should be good until around the year 2065. So > perhaps we can save extending the HIT to be greater than 128 bits > for some future rev of the relevant protocols. (Or are we trying to > design protocols that will last for a 100 years or more?) > > I do however still believe that we need an unambiguous tag in the > HIT that tells you how it was generated (which hash function was > used, and perhaps how it was used). IMHO we need at least four > bits of such a tag, and preferably a few more than that. > > And there's also the desire some have to squeeze HITs into the > IPv6 unicast address space somewhere so that they can be passed > across IPv6 related APIs, so that may burn a few top bits of > the HIT. > > -Tim Shepard > shep@alum.mit.edu > _______________________________________________ > 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 Mar 17 16:46:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24070 for ; Thu, 17 Mar 2005 16:46:36 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D2B6E730D; Thu, 17 Mar 2005 16:46:03 -0500 (EST) 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 E7C9372E6 for ; Thu, 17 Mar 2005 16:45:53 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 403332E22; Thu, 17 Mar 2005 23:45:56 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A34852E00; Thu, 17 Mar 2005 23:45:55 +0200 (EET) Received: (from tkoponen@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2HLjsQ10701; Thu, 17 Mar 2005 23:45:54 +0200 (EET) X-Authentication-Warning: kekkonen.cs.hut.fi: tkoponen set sender to tkoponen@iki.fi using -f From: Teemu Koponen To: Greg Perkins Cc: hipsec@honor.trusecure.com Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <20050317214550.GA4303@iki.fi> References: <01c501c52b24$ff6f52f0$ef01a996@gmp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c501c52b24$ff6f52f0$ef01a996@gmp> User-Agent: Mutt/1.4.2i X-GPG-Fingerprint: 98D9 FD4D 7E63 11A4 074A 0D51 FFAA 007D C8D4 BD4C X-GPG-Key: http://www.iki.fi/tkoponen/pgp.asc X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-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, 17 Mar 2005 23:45:54 +0200 Date: Thu, 17 Mar 2005 23:45:54 +0200 On Thu, Mar 17, 2005 at 02:10:35PM -0500, Greg Perkins wrote: > that is included in every HIP packet header. The HIP session > identifier (HSI) can then be used as the pointer to the HI and also > as an index for applications. I am still mulling this over, and am > really just being a devil's advocate atm because I like HITs because > of their cryptographic link to the HI. But, a HSI has the following > benefits: If I understood correctly, session identifiers, and their connection to host identities, were known to peers only in your model. However, there might be (HIP-aware) middle-boxes in the path that could use an index to host identities too. For them peer-only HI pointers create challenges. Teemu -- tkoponen@iki.fi # PGP, X.509v3: http://www.iki.fi/tkoponen/px.html PGP fingerprint: 98D9 FD4D 7E63 11A4 074A 0D51 FFAA 007D C8D4 BD4C X.509v3 : D854 0273 366F 53D1 BB35 C2B1 F534 8EC8 91B6 A9AD _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 18 05:23:38 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17009 for ; Fri, 18 Mar 2005 05:23:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id C859C732D; Fri, 18 Mar 2005 05:23:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 2E6AE7326 for ; Fri, 18 Mar 2005 05:22:40 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 72F24212D26; Fri, 18 Mar 2005 12:22:40 +0200 (EET) In-Reply-To: <00fb01c528b8$488de740$ef01a996@gmp> References: <200503082356.53783.julien.laganier@sun.com> <00fb01c528b8$488de740$ef01a996@gmp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: From: Pekka Nikander Subject: Re: [Hipsec] SHA1 broken? To: "Greg Perkins" X-Mailer: Apple Mail (2.619.2) 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, 17 Mar 2005 15:52:09 -0500 Date: Thu, 17 Mar 2005 15:52:09 -0500 Content-Transfer-Encoding: 7bit Greg, > If you add a check that the RSA public key (the HI) must be of at > least a > certain length then this attack stays very difficult because key > generation > is a O(n^4) operation. It is desirable to allow short host identity public keys for various reasons. Hence, IMHO we can't rely (much) on the fact that public key generation is a hard operation. Additionally, it may well happen that some HITs in the future would be hashes of something else but just a public key; e.g., consider HITs that are hashes over self signed certificates. > I do agree that the encoding should include a few semantic bits, like > Pekka > discussed at the meeting. I'd like these to include not only the hash > algorithm and bit length, but also the ability to define alternative > identifiers. Well, I disagree. IMHO we should keep the HITs themselves as semantic-free as possible. The hash algorithm we have to encode there, but IMHO we should not encode the type. We've gone through this type-encoding discussion before (I'm off-line so I can't check the archive), and then the conclusion was to move from type-tagged identifiers into pure hashes. I don't remember the details of that discussion any more, though. What I remember is the following: - Any information in the HIT is a potential privacy issue. The HITs, even temporary ones, will often be visible to external parties. They should be able to learn as little as possible from the HIT alone. - Many people at the November 2004 Washington DC workshop argued that the HITs should have even less semantic information; i.e., it should be possible to have HITs that are not considered to be hashes of public keys. Unfortunately, that collides with the implicit channel bindings property of HITs. Other than that, I think that your ideas about ECC and symmetric keys are interesting and warrant more study. However, while doing so, it is good to keep in mind the current design constrains and competing requirements. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 18 05:23:51 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17058 for ; Fri, 18 Mar 2005 05:23:51 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6CBA4733F; Fri, 18 Mar 2005 05:23:05 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 6AB7E7326 for ; Fri, 18 Mar 2005 05:22:41 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6EEBB212D27; Fri, 18 Mar 2005 12:22:43 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0dc7934f2b58058408cf6673a8167487@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: Tim Shepard X-Mailer: Apple Mail (2.619.2) 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, 17 Mar 2005 15:40:14 -0500 Date: Thu, 17 Mar 2005 15:40:14 -0500 Content-Transfer-Encoding: 7bit On Mar 17, 2005, at 11:23, Tim Shepard wrote: >>>> For HIP I think we need to be able to handle longer HITs, and I >>>> think we need a way of encoding in the HIT itself (in an >>>> unambiguous way) what hash function it is that is supposed to >>>> demonstrate the binding of the HIT to a public key. > > After discussing this with a number of people at IETF62 who are > more of a cryptographer than I am, I am now not certain that we > need to make HITs any longer than they are now. It may be > reasonable to have only around 120 bits of hash function output > incorporated into the HIT. > > If that is secure enough, there may be significant advantages to > keeping HITs at a fixed length of 128 bits. I agree. Tom may have a different opinion, though. Let me try to put some of my thoughts in more concrete form: 1. It is far easier to handle fixed length entities in hardware than variable length ones. AFAIK, that is one of the main reasons why IP has fixed length addresses. As I can imagine one possible future where there is a considerable number of SPI-NAT like middle boxes in the network, I consider it highly desirable to optimise the HIP header to be suitable for hardware-based fast demultiplexing. 2. A software implementation that deals with a fixed length length entities is likely to have less bugs and likely to be faster than one that is optimised for handling variable length entities. 3. It is always possible to embded *shorter* identifiers into longer ones, if such need arises. 4. The identifiers must be long enough so that the probability of collisions is low enough. From this point of view 64 bits would definitely be too short, and while 128 bits looks likely to be long enough, we don't know how many networked devices there will be in the future, may be up to 10^15 or 10^16. Considering that 2^120 \approx 10^36, there would still be about 10^20 identifiers per device. As long as we impose no structure on the identifiers, that should be ok. However, the margin is not that large any more, due to the birthday paradox. Unless my math is completely flawed (which it may well be), we might expect to get problems with about 107..108-bits long identifiers, leaving us with a margin of about 12 bits. In other words, if my upper bound approximation of the number of devices (10^16) is off by more than two orders of magnitude, we may start having problems. 5. The computational complexity of forging an identifier is a different concern, separate from statistical uniqueness. Tim described it well: > My understanding now is that 80 bits of good hash function output is > sufficient today, and with a simpleminded extrapolation of needing > another bit every 18 months (for Moore's law), 120-bits of good hash > function output should be good until around the year 2065. So > perhaps we can save extending the HIT to be greater than 128 bits > for some future rev of the relevant protocols. So, due to the reasons above, I think that it looks like a good idea to stick with fixed length identifiers and at least 120-bit hashes for now. That we can fairly easily fit into 128-bit identifiers. However, I would prefer to keep more bits for the hash, just to decrease the probability of us getting later in trouble due to a considerable number devices starting to have the same HIT by chance. > (Or are we trying to design protocols that will last for a > 100 years or more?) I would say that we should design our protocols so that they are likely to remain usable for at least 50 years, and preferably longer. Hence, we should engineer in a way to extend the length due to increased computing power in the future. However, that can well be a protocol version bump, IMHO. > I do however still believe that we need an unambiguous tag in the > HIT that tells you how it was generated (which hash function was > used, and perhaps how it was used). IMHO we need at least four > bits of such a tag, and preferably a few more than that. I fully agree with the need for a tag. It must also be understood that the tag is a fundamental part of the identifier and cannot be removed or changed without making the identifier a different one. What comes to the tag length, we have here two competing forces: - Flexibility offered by a longer tag length - Smaller probability of collisions due to a longer hash length > And there's also the desire some have to squeeze HITs into the > IPv6 unicast address space somewhere so that they can be passed > across IPv6 related APIs, so that may burn a few top bits of > the HIT. With careful co-ordination we can most probably take care of both the tag and the IPv6 value space considerations, at least initially. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Mar 21 00:12:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00930 for ; Mon, 21 Mar 2005 00:12:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 5696B732C; Mon, 21 Mar 2005 00:12:02 -0500 (EST) 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 BC26F72F3 for ; Mon, 21 Mar 2005 00:11:38 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1DDFCO-00015d-00; Mon, 21 Mar 2005 00:11:32 -0500 From: Tim Shepard To: Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-reply-to: Your message of Thu, 17 Mar 2005 15:40:14 -0500. <0dc7934f2b58058408cf6673a8167487@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: Mon, 21 Mar 2005 00:11:32 -0500 Date: Mon, 21 Mar 2005 00:11:32 -0500 > > I do however still believe that we need an unambiguous tag in the > > HIT that tells you how it was generated (which hash function was > > used, and perhaps how it was used). IMHO we need at least four > > bits of such a tag, and preferably a few more than that. > > I fully agree with the need for a tag. It must also be understood > that the tag is a fundamental part of the identifier and cannot > be removed or changed without making the identifier a different one. > > What comes to the tag length, we have here two competing forces: > > - Flexibility offered by a longer tag length > - Smaller probability of collisions due to a longer hash length The difference between 120 bits of hash and 124 bits of hash value seems barely significant. The difference between 4 bits of tag and 8 bits of tag seems very significant. So it seems to me that the 128-bit format for a HIT should be 8 bits of tag, followed by 120 bits of hash value. (Perhaps we could use (or reserve) one bit in the tag byte to indicate whether the HIT is 128 bits or 256 bits long. Or have the code-points in the tag byte gain an implied length of the HIT when the code points are assigned.) -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 Mon Mar 21 05:29:39 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13901 for ; Mon, 21 Mar 2005 05:29:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id EEC8B732C; Mon, 21 Mar 2005 05:29:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 5401A7305 for ; Mon, 21 Mar 2005 05:28:13 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 40781212D29; Mon, 21 Mar 2005 12:28:08 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) 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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: Tim Shepard X-Mailer: Apple Mail (2.619.2) 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, 21 Mar 2005 12:28:09 +0200 Date: Mon, 21 Mar 2005 12:28:09 +0200 Content-Transfer-Encoding: 7bit >>> I do however still believe that we need an unambiguous tag in the >>> HIT that tells you how it was generated (which hash function was >>> used, and perhaps how it was used). IMHO we need at least four >>> bits of such a tag, and preferably a few more than that. >> >> I fully agree with the need for a tag. It must also be understood >> that the tag is a fundamental part of the identifier and cannot >> be removed or changed without making the identifier a different one. >> >> What comes to the tag length, we have here two competing forces: >> >> - Flexibility offered by a longer tag length >> - Smaller probability of collisions due to a longer hash length > > The difference between 120 bits of hash and 124 bits of hash value > seems barely significant. > > The difference between 4 bits of tag and 8 bits of tag seems very > significant. I still have my doubts whether this is good for the architecture. I have the strong feeling that 8 bits is too much for encoding the hash function; in fact, something like 3 bits should do very well. On the other hand, I can live with having 3 or 4 bits for the tag, 5 or 4 bits reserved, and 120 bits for the hash value. Hence, I would suggest the following: 0 5 7 127 +------+----+------------------------------------------------+ | Prfx | HA | Hash | +------+----+------------------------------------------------+ Prfx (5 bits) - Fixed prefix, TBD. All other values reserved. Suggested prefix for testing: 01000 HA (3 bits) - Hash algorithm. 000 - SHA-1 (as currently defined) All other values reserved. Hash (120 bits) - Hash (as specified by HA) of the public key. Comments? --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Mar 21 08:26:39 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03183 for ; Mon, 21 Mar 2005 08:26:38 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 6AD247341; Mon, 21 Mar 2005 08:26:04 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 0EDEA7334; Mon, 21 Mar 2005 08:25:55 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 57C54212D2B; Mon, 21 Mar 2005 15:25:56 +0200 (EET) In-Reply-To: <01c501c52b24$ff6f52f0$ef01a996@gmp> References: <01c501c52b24$ff6f52f0$ef01a996@gmp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <338a8312a5298b0b8a4a27a61f7d3fb8@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec-rg@honor.trusecure.com, "" Reply-To: hipsec-rg@honor.trusecure.com From: Pekka Nikander To: "Greg Perkins" X-Mailer: Apple Mail (2.619.2) Subject: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs) 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, 21 Mar 2005 15:25:56 +0200 Date: Mon, 21 Mar 2005 15:25:56 +0200 Content-Transfer-Encoding: 7bit Greg, The ideas you have sound interesting and worth investigating, but I'm afraid they fall beyond the current WG charter. Hence, maybe this discussion should be moved to the RG side? In general, I think it would be a good idea if people worked out on alternatives to the current HIP protocol. The questions about Service and Session identifiers are important, and IMHO not well enough thought out in the current HIP architecture. --Pekka On Mar 17, 2005, at 21:10, Greg Perkins wrote: > I mostly agree with this but there may be an issue with long-term > HI/HIT > use. I like the idea of having a long-term HI, one I can hand-out > because > it will last years. In such a use-case it would be a pain if someone > managed to duplicate my HIT and thus I'd be forced to make a new > HI/HIT and > hand it out all over again. I don't consider this critical but it > would be > nice if a HI could last for a long period of time IMO. > > Also, I have started to consider whether or not it is a good idea to > use an > HIT in the HIP exchange/control packets. The use of a random HIP > session > identifier (around 64-96 bits in length) might work out better. > During the > base exchange you'd have to send your HI in the I2 packet. The R2 > packet > would contain a session key to be used to mask your HIP session > identifier. > The SPI index is then used to decrypt the encrypted HIP session > indentifier, > that is included in every HIP packet header. The HIP session > identifier > (HSI) can then be used as the pointer to the HI and also as an index > for > applications. I am still mulling this over, and am really just being a > devil's advocate atm because I like HITs because of their > cryptographic link > to the HI. But, a HSI has the following benefits: > > - an HSI is a temporary value so even if an attacker attains one he > can only > do harm to the current HIP session > - fewer bits needed for identifier. 64 bits would be more than enough > because the value is session oriented and thus discarded after use. > Therefore, we could use 64 bits of the IPv6 source address space for > an HSI > and use the other 64 bits for other uses like LSIs. > - using an XOR mask is a cheap yet strong method for protecting the > HSI. > - for legacy applications you could probably make the HSI an IP > address, > though I don't know how HIP could be signaled so that it does this in > an > appropriate way (security gets thrown away of course) > > In this scenario a HIT is used mainly for lookup at the DNS (or > wherever) > and thus can use 128 or 256 bit hash as needed. > > I now await a counter-argument in support of HITs. The crypto-graphic > link > to an HI is the strong-point IMO but with hashes under heavy attack, > such a > link may not be all that secure. Thus, we either need more bits, live > with > less security or maybe use a different identifier. > > Greg > > ----- Original Message ----- > From: "Tim Shepard" > To: > Sent: Thursday, March 17, 2005 11:23 AM > Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) > > >> >> I said and have been been quoted as saying: >> >>>>> Implications for HIP >>>>> -------------------- >>>>> >>>>> For HIP I think we need to be able to handle longer HITs, and I >>>>> think we need a way of encoding in the HIT itself (in an >>>>> unambiguous way) what hash function it is that is supposed to >>>>> demonstrate the binding of the HIT to a public key. (Otherwise, a >>>>> weakness in one hash function might allow you to create a public >>>>> key which can be "demonstrated" to be bound to a HIT that was >>>>> created with a different hash function.) >> >> After discussing this with a number of people at IETF62 who are >> more of a cryptographer than I am, I am now not certain that we >> need to make HITs any longer than they are now. It may be >> reasonable to have only around 120 bits of hash function output >> incorporated into the HIT. >> >> If that is secure enough, there may be significant advantages to >> keeping HITs at a fixed length of 128 bits. >> >> My understanding now is that 80 bits of good hash function output is >> sufficient today, and with a simpleminded extrapolation of needing >> another bit every 18 months (for Moore's law), 120-bits of good hash >> function output should be good until around the year 2065. So >> perhaps we can save extending the HIT to be greater than 128 bits >> for some future rev of the relevant protocols. (Or are we trying to >> design protocols that will last for a 100 years or more?) >> >> I do however still believe that we need an unambiguous tag in the >> HIT that tells you how it was generated (which hash function was >> used, and perhaps how it was used). IMHO we need at least four >> bits of such a tag, and preferably a few more than that. >> >> And there's also the desire some have to squeeze HITs into the >> IPv6 unicast address space somewhere so that they can be passed >> across IPv6 related APIs, so that may burn a few top bits of >> the HIT. >> >> -Tim Shepard >> shep@alum.mit.edu >> _______________________________________________ >> 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 Mar 21 13:21:41 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02853 for ; Mon, 21 Mar 2005 13:21:41 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 24F257328; Mon, 21 Mar 2005 13:21:05 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by honor.icsalabs.com (Postfix) with ESMTP id 2E6B87305; Mon, 21 Mar 2005 13:20:26 -0500 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j2LIKOn6030780; Mon, 21 Mar 2005 13:20:24 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 7C7703C8187; Mon, 21 Mar 2005 13:17:51 -0500 (EST) Received: from gmp (dhcp239.Research.Panasonic.COM [150.169.1.239])by redwood.research.panasonic.com (Postfix) with SMTP id 715EB3C8176;Mon, 21 Mar 2005 13:17:51 -0500 (EST) Message-ID: <025201c52e44$e02f0980$ef01a996@gmp> From: "Greg Perkins" To: Cc: References: <01c501c52b24$ff6f52f0$ef01a996@gmp> <338a8312a5298b0b8a4a27a61f7d3fb8@nomadiclab.com> Subject: Re: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:7 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) 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, 21 Mar 2005 13:36:20 -0500 Date: Mon, 21 Mar 2005 13:36:20 -0500 Content-Transfer-Encoding: 7bit Pekka, You are correct. These belong on HIP-RG. I'll continue any email discusion on this there. Greg ----- Original Message ----- From: "Pekka Nikander" To: "Greg Perkins" Cc: ; Sent: Monday, March 21, 2005 8:25 AM Subject: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs) > Greg, > > The ideas you have sound interesting and worth investigating, > but I'm afraid they fall beyond the current WG charter. Hence, > maybe this discussion should be moved to the RG side? > > In general, I think it would be a good idea if people worked > out on alternatives to the current HIP protocol. The questions > about Service and Session identifiers are important, and IMHO > not well enough thought out in the current HIP architecture. > > --Pekka > > On Mar 17, 2005, at 21:10, Greg Perkins wrote: > > > I mostly agree with this but there may be an issue with long-term > > HI/HIT > > use. I like the idea of having a long-term HI, one I can hand-out > > because > > it will last years. In such a use-case it would be a pain if someone > > managed to duplicate my HIT and thus I'd be forced to make a new > > HI/HIT and > > hand it out all over again. I don't consider this critical but it > > would be > > nice if a HI could last for a long period of time IMO. > > > > Also, I have started to consider whether or not it is a good idea to > > use an > > HIT in the HIP exchange/control packets. The use of a random HIP > > session > > identifier (around 64-96 bits in length) might work out better. > > During the > > base exchange you'd have to send your HI in the I2 packet. The R2 > > packet > > would contain a session key to be used to mask your HIP session > > identifier. > > The SPI index is then used to decrypt the encrypted HIP session > > indentifier, > > that is included in every HIP packet header. The HIP session > > identifier > > (HSI) can then be used as the pointer to the HI and also as an index > > for > > applications. I am still mulling this over, and am really just being a > > devil's advocate atm because I like HITs because of their > > cryptographic link > > to the HI. But, a HSI has the following benefits: > > > > - an HSI is a temporary value so even if an attacker attains one he > > can only > > do harm to the current HIP session > > - fewer bits needed for identifier. 64 bits would be more than enough > > because the value is session oriented and thus discarded after use. > > Therefore, we could use 64 bits of the IPv6 source address space for > > an HSI > > and use the other 64 bits for other uses like LSIs. > > - using an XOR mask is a cheap yet strong method for protecting the > > HSI. > > - for legacy applications you could probably make the HSI an IP > > address, > > though I don't know how HIP could be signaled so that it does this in > > an > > appropriate way (security gets thrown away of course) > > > > In this scenario a HIT is used mainly for lookup at the DNS (or > > wherever) > > and thus can use 128 or 256 bit hash as needed. > > > > I now await a counter-argument in support of HITs. The crypto-graphic > > link > > to an HI is the strong-point IMO but with hashes under heavy attack, > > such a > > link may not be all that secure. Thus, we either need more bits, live > > with > > less security or maybe use a different identifier. > > > > Greg > > > > ----- Original Message ----- > > From: "Tim Shepard" > > To: > > Sent: Thursday, March 17, 2005 11:23 AM > > Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) > > > > > >> > >> I said and have been been quoted as saying: > >> > >>>>> Implications for HIP > >>>>> -------------------- > >>>>> > >>>>> For HIP I think we need to be able to handle longer HITs, and I > >>>>> think we need a way of encoding in the HIT itself (in an > >>>>> unambiguous way) what hash function it is that is supposed to > >>>>> demonstrate the binding of the HIT to a public key. (Otherwise, a > >>>>> weakness in one hash function might allow you to create a public > >>>>> key which can be "demonstrated" to be bound to a HIT that was > >>>>> created with a different hash function.) > >> > >> After discussing this with a number of people at IETF62 who are > >> more of a cryptographer than I am, I am now not certain that we > >> need to make HITs any longer than they are now. It may be > >> reasonable to have only around 120 bits of hash function output > >> incorporated into the HIT. > >> > >> If that is secure enough, there may be significant advantages to > >> keeping HITs at a fixed length of 128 bits. > >> > >> My understanding now is that 80 bits of good hash function output is > >> sufficient today, and with a simpleminded extrapolation of needing > >> another bit every 18 months (for Moore's law), 120-bits of good hash > >> function output should be good until around the year 2065. So > >> perhaps we can save extending the HIT to be greater than 128 bits > >> for some future rev of the relevant protocols. (Or are we trying to > >> design protocols that will last for a 100 years or more?) > >> > >> I do however still believe that we need an unambiguous tag in the > >> HIT that tells you how it was generated (which hash function was > >> used, and perhaps how it was used). IMHO we need at least four > >> bits of such a tag, and preferably a few more than that. > >> > >> And there's also the desire some have to squeeze HITs into the > >> IPv6 unicast address space somewhere so that they can be passed > >> across IPv6 related APIs, so that may burn a few top bits of > >> the HIT. > >> > >> -Tim Shepard > >> shep@alum.mit.edu > >> _______________________________________________ > >> 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 > _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 22 10:35:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25401 for ; Tue, 22 Mar 2005 10:35:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 56343733D; Tue, 22 Mar 2005 10:35:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by honor.icsalabs.com (Postfix) with ESMTP id F42297334 for ; Tue, 22 Mar 2005 10:34:59 -0500 (EST) Received: from [128.214.113.216] (guest216.hiit.fi [128.214.113.216]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 22 Mar 2005 17:34:56 +0200 id 00070F13.42403B20.00002909 Message-ID: <42403B02.2070001@cs.helsinki.fi> From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] legacy NAT traversal 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, 22 Mar 2005 17:34:26 +0200 Date: Tue, 22 Mar 2005 17:34:26 +0200 Content-Transfer-Encoding: 7bit Hi, Is anyone currently working on an implementation of legacy NAT traversal for HIP using UDP or TCP? It seems to be a high priority issue, and I'm wondering whether someone in InfraHIP project should do this in case no one is doing it already. Andrei _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Tue Mar 22 19:40:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29038 for ; Tue, 22 Mar 2005 19:40:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 697EB72EA; Tue, 22 Mar 2005 19:40:02 -0500 (EST) 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 A6A6B72E0 for ; Tue, 22 Mar 2005 19:39:37 -0500 (EST) 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 QAA18736; Tue, 22 Mar 2005 16:39:26 -0800 (PST) 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 j2N0dP722784; Tue, 22 Mar 2005 18:39:25 -0600 (CST) 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, 22 Mar 2005 16:39:25 -0800 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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> Thread-Topic: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcUuANT+0ev0sTx0SgSvMjlLz4bGPgBPx9PQ From: "Henderson, Thomas R" To: "Pekka Nikander" , "Tim Shepard" Cc: X-OriginalArrivalTime: 23 Mar 2005 00:39:25.0232 (UTC) FILETIME=[C3620300:01C52F40] 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, 22 Mar 2005 16:39:24 -0800 Date: Tue, 22 Mar 2005 16:39:24 -0800 Content-Transfer-Encoding: quoted-printable =20 > 0 5 7 127 > +------+----+------------------------------------------------+ > | Prfx | HA | Hash | > +------+----+------------------------------------------------+ >=20 > Prfx (5 bits) - Fixed prefix, TBD. All other values reserved. >=20 > Suggested prefix for testing: 01000 >=20 > HA (3 bits) - Hash algorithm. >=20 > 000 - SHA-1 (as currently defined) > All other values reserved. >=20 > Hash (120 bits) - Hash (as specified by HA) of the public key. >=20 > Comments? >=20 Actually, that is mostly consistent with what I was arguing for. I appreciate the reasons for not having arbitrary lengths-- my main motiviation for suggesting non-128 bit HITs was in case we wanted to use larger structures like i3 triggers (256 bits) as ULIDs-- but I think it is fine to leave that possibility for future research. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 23 07:42:38 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08325 for ; Wed, 23 Mar 2005 07:42:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 8E8E072EA; Wed, 23 Mar 2005 07:42:02 -0500 (EST) 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 DCAAA72E6 for ; Wed, 23 Mar 2005 07:41:25 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2NCfNRr026335 for ; Wed, 23 Mar 2005 05:41:24 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IDT00MQP1WZ9D@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 23 Mar 2005 05:41:23 -0700 (MST) Received: from [10.0.0.163] ([83.145.97.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IDT006R51WX44@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 23 Mar 2005 05:41:23 -0700 (MST) From: Julien Laganier To: hipsec@honor.trusecure.com Message-id: <200503231341.18902.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] Rendezvous and tunneling 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, 23 Mar 2005 13:41:18 +0100 Date: Wed, 23 Mar 2005 13:41:18 +0100 Content-Transfer-Encoding: 7BIT Hi folks, At the HIP session during the last IETF, I asked wether or not we wanted to keep tunneling as an option in the _simple_ Rendezvous Extensions. I was proposing to keep only the header rewriting features of the RVS, and let the PATH/NAT traversal document handle the case of UDP tunneling. Furthermore, IMHO ESP tunneling is useless because it requires preservation of the source address (with a FROM) anyway, so there's no added functionallity/value compared to header rewriting, it is just more complex. Furthermore, now that we splitted-out ESP from the base spec, it seems consistent to do the same thing w.r.t. simple RVS extensions. The few people who expressed an opinion at the HIP session seems to agree with that proposal. So I have now three questions before I begin another pass of edition: 1) Should we get rid of I1_TUNNELING mode? 2) Should we get rid of BIDIRECTIONAL mode? If not, what is the usage scenario you have in mind? 3) Should we specify that the RVS relays I1 _and_ UPDATES? This is required to support double-movement in mobility scenarios. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 23 16:43:42 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15199 for ; Wed, 23 Mar 2005 16:43:42 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id A90927307; Wed, 23 Mar 2005 16:43:02 -0500 (EST) 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 D29337302 for ; Wed, 23 Mar 2005 16:42:52 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 471342E3B; Wed, 23 Mar 2005 23:42:55 +0200 (EET) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9A0EC2E15; Wed, 23 Mar 2005 23:42:54 +0200 (EET) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2NLgr504555; Wed, 23 Mar 2005 23:42:53 +0200 (EET) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Julien Laganier Cc: hipsec@honor.trusecure.com Subject: Re: [Hipsec] Rendezvous and tunneling In-Reply-To: <200503231341.18902.julien.laganier@sun.com> Message-ID: References: <200503231341.18902.julien.laganier@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-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: Wed, 23 Mar 2005 23:42:53 +0200 (EET) Date: Wed, 23 Mar 2005 23:42:53 +0200 (EET) On Wed, 23 Mar 2005, Julien Laganier wrote: > So I have now three questions before I begin another pass of edition: > > 1) Should we get rid of I1_TUNNELING mode? To further simplify the rendezvous, I'd say yes. Unless someone has a good use case for this. > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is the usage > scenario you have in mind? Seems of little use... > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This is > required to support double-movement in mobility scenarios. Yes. -- 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 Mar 24 00:36:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09850 for ; Thu, 24 Mar 2005 00:36:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 25EEF7307; Thu, 24 Mar 2005 00:36:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 0578672E8 for ; Thu, 24 Mar 2005 00:35:24 -0500 (EST) Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 07AB2212FAA; Thu, 24 Mar 2005 07:35:22 +0200 (EET) Message-ID: <42425199.9030005@nomadiclab.com> From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" Cc: Pekka Nikander , Tim Shepard , hipsec@honor.trusecure.com Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) References: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> 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: Thu, 24 Mar 2005 07:35:21 +0200 Date: Thu, 24 Mar 2005 07:35:21 +0200 Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: > > >> 0 5 7 127 >> +------+----+------------------------------------------------+ >> | Prfx | HA | Hash | >> +------+----+------------------------------------------------+ >> >> Prfx (5 bits) - Fixed prefix, TBD. All other values reserved. >> >> Suggested prefix for testing: 01000 >> >> HA (3 bits) - Hash algorithm. >> >> 000 - SHA-1 (as currently defined) >> All other values reserved. >> >> Hash (120 bits) - Hash (as specified by HA) of the public key. >> >>Comments? >> > > > Actually, that is mostly consistent with what I was arguing for. I > appreciate the reasons for not having arbitrary lengths-- my main > motiviation for suggesting non-128 bit HITs was in case we wanted to use > larger structures like i3 triggers (256 bits) as ULIDs-- but I think it > is fine to leave that possibility for future research. If there are no objections, I will put this kind of a HIT in the next version of the base draft. A minor change, proposed earlier by Tom: Shall we replace the name "HIT" with "ULID" to make the identifier more generic or stick with the "HIT"? I would like to stay with the "HIT" and use the "ULID" in the future versions of HIP. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 24 04:41:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20367 for ; Thu, 24 Mar 2005 04:41:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 9DEA07309; Thu, 24 Mar 2005 04:41:02 -0500 (EST) 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 8DAD372E8 for ; Thu, 24 Mar 2005 04:40:07 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2O9e9Rr006835 for ; Thu, 24 Mar 2005 02:40:10 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IDU007I6O6XGR@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Thu, 24 Mar 2005 02:40:09 -0700 (MST) Received: from [192.168.1.50] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IDU005GNO6UUK@mail.sun.net> for hipsec@honor.trusecure.com; Thu, 24 Mar 2005 02:40:09 -0700 (MST) From: Julien Laganier Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-reply-to: <42425199.9030005@nomadiclab.com> To: hipsec@honor.trusecure.com Cc: Petri Jokela , "Henderson, Thomas R" , Pekka Nikander , Tim Shepard Message-id: <200503241040.07029.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: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> <42425199.9030005@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, 24 Mar 2005 10:40:06 +0100 Date: Thu, 24 Mar 2005 10:40:06 +0100 Content-Transfer-Encoding: 7BIT On Thursday 24 March 2005 06:35, Petri Jokela wrote: > >> 0 5 7 127 > >> +------+----+------------------------------------------------+ > >> > >> | Prfx | HA | Hash | > >> > >> +------+----+------------------------------------------------+ > >> (...) > If there are no objections, I will put this kind of a HIT in the > next version of the base draft. I'm fine with the new HIT format. > A minor change, proposed earlier by Tom: Shall we replace the name > "HIT" with "ULID" to make the identifier more generic or stick with > the "HIT"? I would like to stay with the "HIT" and use the "ULID" > in the future versions of HIP. Well, my understanding is that although a HIT is a kind of ULID, it encompasses a far more broader scope than a typical ULID. For example it has a channel binding property (w.r.t. the associated HI), it is mostly derived from a flat/unstructured bitstring (at least for Type 1 HITs, and in the sense that they are not routable). Hence, I would rather suggest that we add some text explaining that a HIT is a kind of ULID, along with some other (rather nice) properties. Thoughts? --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 24 09:53:36 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18292 for ; Thu, 24 Mar 2005 09:53:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 58D6E7307; Thu, 24 Mar 2005 09:53:02 -0500 (EST) 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 F10BC72E8 for ; Thu, 24 Mar 2005 09:52:23 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1DETgz-0004AJ-00; Thu, 24 Mar 2005 09:52:13 -0500 From: Tim Shepard To: Pekka Nikander Cc: hipsec@honor.trusecure.com Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-reply-to: Your message of Mon, 21 Mar 2005 12:28:09 +0200. 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, 24 Mar 2005 09:52:13 -0500 Date: Thu, 24 Mar 2005 09:52:13 -0500 Pekka said: > I still have my doubts whether this is good for the architecture. > I have the strong feeling that 8 bits is too much for encoding > the hash function; in fact, something like 3 bits should do very > well. On the other hand, I can live with having 3 or 4 bits for the > tag, 5 or 4 bits reserved, and 120 bits for the hash value. > > Hence, I would suggest the following: > > 0 5 7 127 > +------+----+------------------------------------------------+ > | Prfx | HA | Hash | > +------+----+------------------------------------------------+ > > Prfx (5 bits) - Fixed prefix, TBD. All other values reserved. > > Suggested prefix for testing: 01000 > > HA (3 bits) - Hash algorithm. > > 000 - SHA-1 (as currently defined) > All other values reserved. > > Hash (120 bits) - Hash (as specified by HA) of the public key. > > Comments? Do you intend to use the same set of assignments for HA if you are using a different Prfx? I would guess not. It seems to me any software written will want to dispatch on the value of the top 8 bits taken as a single field. So I think it would be better (yet equivalent in effect for now) to explain this as the top byte being reserved to identify the type of HIT (the hash algorithm used to produce the bottom 120 bits). Simply: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Htype | | +-+-+-+-+-+-+-+-+ + | Hash (120 bits) | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then, we can allocate one or two code points for Htype (holding all others in reserve) and you can perform whatever hacks you what to embed this someplace in IPv6 unicast address space (to allow these to be passed across IPv6 APIs. Htype (8 bits): 01000000 - SHA-1 (as currently defined) All other values reserved. So I'm agreeing on the pattern of bits for the one code point you've assigned (and probably the next one too), just suggesting a better (IMHO) way to document it. The IANA considerations would then be (if we want to be able to pass these across IPv6 interfaces) that each Htype allocated takes a /8 chunk out of IPv6 address space. That may seem to be a lot to ask for (such a large block out of IPv6 address space). However, I'm not sure such /8 allocations would need to be allocated to HIP exclusively. Rather, it would be a handle that can be passed to refer to that-which-hashes-to-this-value(-using-the-indicated-hash-algorithm). (I'm thinking of that SIGCOMM'04 paper here.) So having IANA set aside a /3 or so out of IPv6 address space for this sort of thing seems reasonable. (e.g. 4000::/3 , within which it could make up to 32 such /8 allocations. And if it ever exhausts this /3, it could use the next one.) I realize I'm touching areas that are research here, but I think what I've proposed that we do now would be OK and will allow us to get this right (via some avenue of bit hackery) when we are smarter later. -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 Thu Mar 24 20:21:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29161 for ; Thu, 24 Mar 2005 20:21:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 429B7730F; Thu, 24 Mar 2005 20:21:03 -0500 (EST) 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 91DE0730C for ; Thu, 24 Mar 2005 20:20:03 -0500 (EST) 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 TAA03370; Thu, 24 Mar 2005 19:19:56 -0600 (CST) Received: from xch-nwbh-01.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 j2P1Jtv03006; Thu, 24 Mar 2005 17:19:55 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Mar 2005 17:19:55 -0800 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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> Thread-Topic: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcUwgTOvMstItTkfTuaBPst3/lgVbAAU3Oww From: "Henderson, Thomas R" To: "Tim Shepard" , "Pekka Nikander" Cc: X-OriginalArrivalTime: 25 Mar 2005 01:19:55.0159 (UTC) FILETIME=[C08EF270:01C530D8] 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, 24 Mar 2005 17:19:54 -0800 Date: Thu, 24 Mar 2005 17:19:54 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Tim Shepard [mailto:shep@alum.mit.edu]=20 > Sent: Thursday, March 24, 2005 6:52 AM > To: Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20 > SHA1 broken? )=20 > > Hence, I would suggest the following: > >=20 > > 0 5 7 127 > > +------+----+------------------------------------------------+ > > | Prfx | HA | Hash | > > +------+----+------------------------------------------------+ > >=20 > > Prfx (5 bits) - Fixed prefix, TBD. All other values reserved. > >=20 > > Suggested prefix for testing: 01000 > >=20 > > HA (3 bits) - Hash algorithm. > >=20 > > 000 - SHA-1 (as currently defined) > > All other values reserved. > >=20 > > Hash (120 bits) - Hash (as specified by HA) of the public key. >=20 > So I think it would be better (yet equivalent in effect for=20 > now) to explain this as the top byte being reserved to=20 > identify the type of HIT (the hash algorithm used to produce=20 > the bottom 120 bits). Simply: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Htype | | > +-+-+-+-+-+-+-+-+ + I would slightly prefer to use Prefix/Htype, if only for keeping the door open in the future for non-hash identifiers. =20 I'd also like to see that the prefix type defines further the semantics of the rest of this first byte. Specifically, if prefix =3D 001, 110, = or 111, then the HIT may (in some future use) correspond to an IP address, and there may be no hash algorithm applied. However, we would not specify the use of such prefixes in the base spec-- only that they are reserved. So maybe, as a slight variant to Pekka's proposal: 0 3 8 127 +------+----+------------------------------------------------+ | Prfx | HA | Hash | +------+----+------------------------------------------------+ Prfx (3 bits) - Fixed prefix, TBD. All other values reserved and do not necessarily imply that the subsequent 125 bits correspond to Hash Algorithm and Hash subfields. Suggested prefix for testing: 010 =20 HA (5 bits) - Hash Algorithm. 00000 - SHA-1 (as currently defined) All other values reserved. Hash (120 bits) - Hash (as specified by HA) of the public key. > The IANA considerations would then be (if we want to be able=20 > to pass these across IPv6 interfaces) that each Htype=20 > allocated takes a /8 chunk out of IPv6 address space. >=20 Do we need IANA to allocate out of the IPv6 space? These are not IP addresses. Or does the fact that we are coding them to distinguish them from IP addresses make them implicitly IP addresses? This has always been murky to me. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Thu Mar 24 20:28:32 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00021 for ; Thu, 24 Mar 2005 20:28:32 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B922B730F; Thu, 24 Mar 2005 20:28:01 -0500 (EST) 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 114E6730C for ; Thu, 24 Mar 2005 20:27:00 -0500 (EST) 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 RAA14352; Thu, 24 Mar 2005 17:26:56 -0800 (PST) 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 j2P1Quv07984; Thu, 24 Mar 2005 17:26:56 -0800 (PST) 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, 24 Mar 2005 17:26:55 -0800 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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> Thread-Topic: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcUwVXm8m9AJPwsHRYaBh/BtXm3WBQAg8FCw From: "Henderson, Thomas R" To: "Julien Laganier" , Cc: "Petri Jokela" , "Pekka Nikander" , "Tim Shepard" X-OriginalArrivalTime: 25 Mar 2005 01:26:55.0777 (UTC) FILETIME=[BB442910:01C530D9] 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, 24 Mar 2005 17:26:55 -0800 Date: Thu, 24 Mar 2005 17:26:55 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM]=20 > Sent: Thursday, March 24, 2005 1:40 AM > To: hipsec@honor.trusecure.com > Cc: Petri Jokela; Henderson, Thomas R; Pekka Nikander; Tim Shepard > Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20 > SHA1 broken? ) >=20 > On Thursday 24 March 2005 06:35, Petri Jokela wrote: > > >> 0 5 7 127 > > >> +------+----+------------------------------------------------+ > > >> > > >> | Prfx | HA | Hash | > > >> > > >> +------+----+------------------------------------------------+ > > >> >=20 > (...) >=20 > > If there are no objections, I will put this kind of a HIT=20 > in the next=20 > > version of the base draft. >=20 > I'm fine with the new HIT format. >=20 > > A minor change, proposed earlier by Tom: Shall we replace the name=20 > > "HIT" with "ULID" to make the identifier more generic or stick with=20 > > the "HIT"? I would like to stay with the "HIT" and use the "ULID" > > in the future versions of HIP. >=20 > Well, my understanding is that although a HIT is a kind of=20 > ULID, it encompasses a far more broader scope than a typical=20 > ULID. For example it has a channel binding property (w.r.t.=20 > the associated HI), it is mostly derived from a=20 > flat/unstructured bitstring (at least for Type > 1 HITs, and in the sense that they are not routable). >=20 > Hence, I would rather suggest that we add some text=20 > explaining that a HIT is a kind of ULID, along with some=20 > other (rather nice) properties. >=20 I would support having some language about the inherent binding properties of the HIT (perhaps in section 3.1). =20 Regarding whether we should use HIT vs ULID as the term for the HIP header, I would support keeping with "HIT" term so long as we keep the design space a little bit open in the future for non-hash-based HITs (previous email). Tom =20 _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 25 02:07:37 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06314 for ; Fri, 25 Mar 2005 02:07:37 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 713387313; Fri, 25 Mar 2005 02:07:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 2A0E6730C for ; Fri, 25 Mar 2005 02:06:30 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id B04BD212E18; Fri, 25 Mar 2005 09:06:24 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6f0e0d3087413bac3366590d45fd0d94@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Petri Jokela" , "Tim Shepard" , "Julien Laganier" , From: Pekka Nikander Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) 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, 25 Mar 2005 09:06:28 +0200 Date: Fri, 25 Mar 2005 09:06:28 +0200 Content-Transfer-Encoding: 7bit >>> A minor change, proposed earlier by Tom: Shall we replace the name >>> "HIT" with "ULID" to make the identifier more generic or stick with >>> the "HIT"? I would like to stay with the "HIT" and use the "ULID" >>> in the future versions of HIP. >> >> Well, my understanding is that although a HIT is a kind of >> ULID, it encompasses a far more broader scope than a typical >> ULID. For example it has a channel binding property (w.r.t. >> the associated HI), it is mostly derived from a >> flat/unstructured bitstring (at least for Type >> 1 HITs, and in the sense that they are not routable). >> >> Hence, I would rather suggest that we add some text >> explaining that a HIT is a kind of ULID, along with some >> other (rather nice) properties. >> > > I would support having some language about the inherent binding > properties of the HIT (perhaps in section 3.1). > > Regarding whether we should use HIT vs ULID as the term for the HIP > header, I would support keeping with "HIT" term so long as we keep the > design space a little bit open in the future for non-hash-based HITs > (previous email). Sounds good to me. Basically, I would like to keep the WG work confined within the charter and the 2003 architecture (as defined in the architecture draft), only doing minor modifications for sake of added flexibility in the future. Past track record at the IETF shows that it has been fairly hard to anticipate when flexibility would be useful and when detrimental. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 25 02:23:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20976 for ; Fri, 25 Mar 2005 02:23:34 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 137767313; Fri, 25 Mar 2005 02:23:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 08440730C for ; Fri, 25 Mar 2005 02:22:26 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 12F85212E18; Fri, 25 Mar 2005 09:22:26 +0200 (EET) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36ea1f7d7e9bc19349ce7f41478fc6ae@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Tim Shepard" , From: Pekka Nikander Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.619.2) 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, 25 Mar 2005 09:22:28 +0200 Date: Fri, 25 Mar 2005 09:22:28 +0200 Content-Transfer-Encoding: 7bit >>> Hence, I would suggest the following: >>> >>> 0 5 7 127 >>> +------+----+------------------------------------------------+ >>> | Prfx | HA | Hash | >>> +------+----+------------------------------------------------+ >>> >> >> So I think it would be better (yet equivalent in effect for >> now) to explain this as the top byte being reserved to >> identify the type of HIT (the hash algorithm used to produce >> the bottom 120 bits). > > I would slightly prefer to use Prefix/Htype, if only for keeping the > door open in the future for non-hash identifiers. My base rationale for keeping prefix and hash algorithm separate are the following: 1. If we end up with more than 2-3 hash algorithms in use, we are likely to end up in an interoperability nightmare. 2. Having an explicit prefix may make it easier to progress into standards track and live peacefully with IPv6 in the IPv6 legacy API. > I'd also like to see that the prefix type defines further the semantics > of the rest of this first byte. Specifically, if prefix = 001, 110, or > 111, then the HIT may (in some future use) correspond to an IP address, > and there may be no hash algorithm applied. However, we would not > specify the use of such prefixes in the base spec-- only that they are > reserved. I agree with this approach. Keep the option open, but not define it now. > So maybe, as a slight variant to Pekka's proposal: Given the rationale above, I can't see any benefit form having the hash algorithm field longer than three bits. In fact, I would make it only two bits (as it was originally), but four choices may be too little over time; even if we should aim using only one or at most 2-3 algorithms at any given time, we may need to go from one to another. When 8 choices run out, maybe in 30 years or so, we can bump the protocol number. On the other hand, I do see benefit from having a longer prefix, even if a few bits from the prefix later would end up in being used for some other purpose. The benefit is, obviously, the more potentially more peaceful co-existence with native IPv6. > Do we need IANA to allocate out of the IPv6 space? These are not IP > addresses. Or does the fact that we are coding them to distinguish > them > from IP addresses make them implicitly IP addresses? This has always > been murky to me. They are *not* IPv6 addresses, even though we have certainly played with the ideas of making them (overlay) routable. However, having them live with IPv6 addresses at the IPv6 API is likely to be a benefit. --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Fri Mar 25 13:02:34 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24726 for ; Fri, 25 Mar 2005 13:02:33 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 293BC72F9; Fri, 25 Mar 2005 13:02:03 -0500 (EST) 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 AC08772E8 for ; Fri, 25 Mar 2005 13:01:14 -0500 (EST) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1DEt7J-0004vn-00; Fri, 25 Mar 2005 13:01:05 -0500 From: Tim Shepard To: Pekka Nikander Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-reply-to: Your message of Fri, 25 Mar 2005 09:22:28 +0200. <36ea1f7d7e9bc19349ce7f41478fc6ae@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, 25 Mar 2005 13:01:05 -0500 Date: Fri, 25 Mar 2005 13:01:05 -0500 > > I'd also like to see that the prefix type defines further the semantics > > of the rest of this first byte. Specifically, if prefix = 001, 110, or > > 111, then the HIT may (in some future use) correspond to an IP address, > > and there may be no hash algorithm applied. However, we would not > > specify the use of such prefixes in the base spec-- only that they are > > reserved. > > I agree with this approach. Keep the option open, but not define it > now. > That describes the essential bit of what I was trying to get at by proposing we just have a byte with one or two assigned code points. In Pekka's original proposal, it looked like he was defining two knobs, which would allow future settings independently. So if we say this: If the prefix is 01000, then the next 3 bits are the HA. If the prefix is something other than 01000, then the syntax and semantics of the following bits (however many there may be) are to be defined by future documents. that makes me happy. But I see no real point in nailing down the boundry between the first five bits and the last three bits of this first byte when all we're going to do is assign one or two of the 256 possible values of this byte for now and hold all of the rest in reserve. Any implementation that encounters an unrecognized value in the first byte is not going to be able to do anything meaningful with it, whether or not we make a distinction between the first 5 bits and the last 3 bits. (If I'm wrong in the last sentence, please enlighten me.) > 1. If we end up with more than 2-3 hash algorithms in use, we > are likely to end up in an interoperability nightmare. > I agree with that, but if we're going to have that problem, your not going to be able to stop it by bitfield engineering. (Engineers who would make that mistake would have no trouble finding the extra bits on the other side of the artificial boundry between your two fields.) > When 8 choices run out, maybe in 30 years or so, we can bump the > protocol number. These HITs may have a life independent of being carried in the header of any particular protocol. They may be stored. So if there's a protocol number to be bumped, it's going to have to be inside the HIT itself. > > Do we need IANA to allocate out of the IPv6 space? These are not IP > > addresses. Or does the fact that we are coding them to distinguish > > them > > from IP addresses make them implicitly IP addresses? This has always > > been murky to me. > > They are *not* IPv6 addresses, even though we have certainly played > with the ideas of making them (overlay) routable. However, having > them live with IPv6 addresses at the IPv6 API is likely to be a > benefit. They are certainly not Global Unicast IPv6 addresses. But are they any less of an address than some of the other odd things that are currently allocated out of 0000::/4 and f000::/4 ? IMHO it would be reasonable to argue that HITs are as much of an IPv6 address as say a multicast address, a link local unicast address, or a loopback address (none of which are real addresses). -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 Mon Mar 28 14:13:41 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00799 for ; Mon, 28 Mar 2005 14:13:40 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id D76327323; Mon, 28 Mar 2005 14:13:02 -0500 (EST) Delivered-To: hipsec@honor.trusecure.com Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by honor.icsalabs.com (Postfix) with ESMTP id 8DE0C7322 for ; Mon, 28 Mar 2005 14:12:40 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4EB6A212E18; Mon, 28 Mar 2005 22:12:38 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c6fb0512de042632562a70ca3f366d9@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , hipsec@honor.trusecure.com From: Pekka Nikander Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) To: Tim Shepard X-Mailer: Apple Mail (2.619.2) 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, 28 Mar 2005 22:12:42 +0300 Date: Mon, 28 Mar 2005 22:12:42 +0300 Content-Transfer-Encoding: 7bit >>> I'd also like to see that the prefix type defines further the >>> semantics >>> of the rest of this first byte. Specifically, if prefix = 001, 110, >>> or >>> 111, then the HIT may (in some future use) correspond to an IP >>> address, >>> and there may be no hash algorithm applied. However, we would not >>> specify the use of such prefixes in the base spec-- only that they >>> are >>> reserved. >> >> I agree with this approach. Keep the option open, but not define it >> now. > > That describes the essential bit of what I was trying to get at by > proposing we just have a byte with one or two assigned code points. > In Pekka's original proposal, it looked like he was defining two > knobs, which would allow future settings independently. > > So if we say this: > > If the prefix is 01000, > > then the next 3 bits are the HA. > > If the prefix is something other than 01000, then the syntax and > semantics of the following bits (however many there may be) > are to be defined by future documents. > > that makes me happy. I'm happy with that, too. > But I see no real point in nailing down the boundry between the first > five bits and the last three bits of this first byte when all we're > going to do is assign one or two of the 256 possible values of this > byte for now and hold all of the rest in reserve. Any implementation > that encounters an unrecognized value in the first byte is not going > to be able to do anything meaningful with it, whether or not we make a > distinction between the first 5 bits and the last 3 bits. (If I'm > wrong in the last sentence, please enlighten me.) If you don't know how to verify the crypto binding between a HIT and a HI, all you loose is channel bindings. Operationally, you can still create the HIP connection etc. Hence, if you know the first 5 bits and you know that the next 3 bits encode a hash function that you have no idea about, you can still use the HIT, just with (much) lower security level. The second reason for making them separate is to make it easier to define a new hash algorithm. That would only require a WG action while a new code point at the IPv6 address space may require a much heavier process. >> 1. If we end up with more than 2-3 hash algorithms in use, we >> are likely to end up in an interoperability nightmare. > >> When 8 choices run out, maybe in 30 years or so, we can bump the >> protocol number. > > These HITs may have a life independent of being carried in the header > of any particular protocol. They may be stored. So if there's a > protocol number to be bumped, it's going to have to be inside the HIT > itself. Hmm. So we want HITs that are usable over 30 years, once their channel bindings property has become obsolete? Maybe, yes, maybe. But as an alternative we can certainly define another 5-bit prefix, if needed. Again, this is all about the right balance. As of now I think we don't see what the right balance is. Maybe someone should collect all the arguments in a longish e-mail or short draft? (Don't have time / wits for it right now.) >> They are *not* IPv6 addresses, even though we have certainly played >> with the ideas of making them (overlay) routable. However, having >> them live with IPv6 addresses at the IPv6 API is likely to be a >> benefit. > > They are certainly not Global Unicast IPv6 addresses. But are they > any less of an address than some of the other odd things that are > currently allocated out of 0000::/4 and f000::/4 ? I can't say for f000::/4, but for 0000::/4, yes, some of those are as little IPv6 addresses as HITs are... --Pekka _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Mon Mar 28 21:53:35 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10988 for ; Mon, 28 Mar 2005 21:53:35 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 4FDD47323; Mon, 28 Mar 2005 21:53:03 -0500 (EST) 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 5B4817322 for ; Mon, 28 Mar 2005 21:52:34 -0500 (EST) 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 SAA21577; Mon, 28 Mar 2005 18:52:22 -0800 (PST) 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 j2T2qL705647; Mon, 28 Mar 2005 20:52:22 -0600 (CST) 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); Mon, 28 Mar 2005 18:52:21 -0800 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: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> Thread-Topic: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcUzyh3VjTiFdQyYSqmatw0iPvE0VAAPmBgQ From: "Henderson, Thomas R" To: "Pekka Nikander" , "Tim Shepard" Cc: X-OriginalArrivalTime: 29 Mar 2005 02:52:21.0774 (UTC) FILETIME=[54403AE0:01C5340A] 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, 28 Mar 2005 18:52:21 -0800 Date: Mon, 28 Mar 2005 18:52:21 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Monday, March 28, 2005 11:13 AM > To: Tim Shepard > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec]=20 > SHA1 broken? )=20 >=20 > >>> I'd also like to see that the prefix type defines further the=20 > >>> semantics of the rest of this first byte. Specifically,=20 > if prefix =3D=20 > >>> 001, 110, or 111, then the HIT may (in some future use)=20 > correspond=20 > >>> to an IP address, and there may be no hash algorithm applied. =20 > >>> However, we would not specify the use of such prefixes in=20 > the base=20 > >>> spec-- only that they are reserved. > >> > >> I agree with this approach. Keep the option open, but not=20 > define it=20 > >> now. > > > > That describes the essential bit of what I was trying to get at by=20 > > proposing we just have a byte with one or two assigned code points. > > In Pekka's original proposal, it looked like he was defining two=20 > > knobs, which would allow future settings independently. > > > > So if we say this: > > > > If the prefix is 01000, > > > > then the next 3 bits are the HA. > > > > If the prefix is something other than 01000, then the syntax and > > semantics of the following bits (however many there may be) > > are to be defined by future documents. > > > > that makes me happy. >=20 > I'm happy with that, too. Can we make it 010, with five bits HA? That would then allow us to block out the global unicast space (001) without having to wildcard the last two bits. Or is this a concern that this becomes a 1/8 instead of 1/32 IANA allocation (if IANA is involved)? > >> They are *not* IPv6 addresses, even though we have=20 > certainly played=20 > >> with the ideas of making them (overlay) routable. However, having=20 > >> them live with IPv6 addresses at the IPv6 API is likely to be a=20 > >> benefit. > > > > They are certainly not Global Unicast IPv6 addresses. But are they=20 > > any less of an address than some of the other odd things that are=20 > > currently allocated out of 0000::/4 and f000::/4 ? >=20 > I can't say for f000::/4, but for 0000::/4, yes, some of=20 > those are as little IPv6 addresses as HITs are... >=20 I still question whether we need to have IANA make an allocation out of the v6 space, at least at this stage of deployment. But I admittedly don't have much understanding of the IANA requirements. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 30 03:44:40 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01847 for ; Wed, 30 Mar 2005 03:44:39 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 92EAF72F2; Wed, 30 Mar 2005 03:44:03 -0500 (EST) 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 1382172EA for ; Wed, 30 Mar 2005 03:43:24 -0500 (EST) Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 18F982E4B; Wed, 30 Mar 2005 11:43:27 +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 559882EA9 for ; Wed, 30 Mar 2005 11:43:23 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j2U8hMM14780; Wed, 30 Mar 2005 11:43:22 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@honor.trusecure.com Subject: Re: [Hipsec] SHA1 broken? In-Reply-To: <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> Message-ID: References: <200503082356.53783.julien.laganier@sun.com> <00fb01c528b8$488de740$ef01a996@gmp> <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.2-niksula20040914 (2004-11-16) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2-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: Wed, 30 Mar 2005 11:43:22 +0300 (EEST) Date: Wed, 30 Mar 2005 11:43:22 +0300 (EEST) FYI, Title : Attacks on Cryptographic Hashes in Internet Protocols Author(s) : P. Hoffman, B. Schneier Filename : draft-hoffman-hash-attacks-00.txt Pages : 11 Date : 2005-3-28 Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many IETF protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-hash-attacks-00.txt -- 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 Wed Mar 30 13:02:40 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24264 for ; Wed, 30 Mar 2005 13:02:40 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id B066B730F; Wed, 30 Mar 2005 13:02:02 -0500 (EST) 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 292F6730D for ; Wed, 30 Mar 2005 13:01:17 -0500 (EST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2UI1KX8025737 for ; Wed, 30 Mar 2005 11:01:20 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IE600EOAFE7T5@edgemail1.Central.Sun.COM> for hipsec@honor.trusecure.com; Wed, 30 Mar 2005 11:01:20 -0700 (MST) Received: from [192.168.1.50] ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IE6003QAFE4S2@mail.sun.net> for hipsec@honor.trusecure.com; Wed, 30 Mar 2005 11:01:19 -0700 (MST) From: Julien Laganier Subject: Re: [Hipsec] Rendezvous and tunneling In-reply-to: <200503231341.18902.julien.laganier@sun.com> To: hipsec@honor.trusecure.com Message-id: <200503302001.07602.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: <200503231341.18902.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: Wed, 30 Mar 2005 20:01:07 +0200 Date: Wed, 30 Mar 2005 20:01:07 +0200 Content-Transfer-Encoding: 7BIT Folks, On Wednesday 23 March 2005 13:41, Julien Laganier wrote: (...) > So I have now three questions before I begin another pass of > edition: > > 1) Should we get rid of I1_TUNNELING mode? > > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is the > usage scenario you have in mind? > > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This is > required to support double-movement in mobility scenarios. So far I only get one answer (from Miika) to the questions above. Hence, if nobody objects, I will modify the hip-rvs draft accordingly and send it to the list for feedback. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From hipsec-admin@honor.trusecure.com Wed Mar 30 14:09:43 2005 Received: from honor.icsalabs.com (honor.trusecure.com [63.170.221.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29689 for ; Wed, 30 Mar 2005 14:09:43 -0500 (EST) Received: from honor.trusecure.com (localhost.localdomain [127.0.0.1]) by honor.icsalabs.com (Postfix) with ESMTP id 504D7730D; Wed, 30 Mar 2005 14:09:02 -0500 (EST) 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 8D42572F2 for ; Wed, 30 Mar 2005 14:08:04 -0500 (EST) 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 LAA15754; Wed, 30 Mar 2005 11:08:05 -0800 (PST) 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 j2UJ84721898; Wed, 30 Mar 2005 13:08:04 -0600 (CST) 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, 30 Mar 2005 11:08:03 -0800 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] Rendezvous and tunneling Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Rendezvous and tunneling Thread-Index: AcU1VPr2fsLNyWIfQiG5ncsLpt9QvAABjTmQ From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 30 Mar 2005 19:08:03.0959 (UTC) FILETIME=[CC868070:01C5355B] 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, 30 Mar 2005 11:08:03 -0800 Date: Wed, 30 Mar 2005 11:08:03 -0800 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Julien Laganier [mailto:Julien.Laganier@Sun.COM]=20 > Sent: Wednesday, March 30, 2005 10:01 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Rendezvous and tunneling >=20 > Folks, >=20 > On Wednesday 23 March 2005 13:41, Julien Laganier wrote: >=20 > (...) >=20 > > So I have now three questions before I begin another pass of > > edition: > > > > 1) Should we get rid of I1_TUNNELING mode? > > > > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is=20 > the usage=20 > > scenario you have in mind? > > > > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This is=20 > > required to support double-movement in mobility scenarios. I am fine with 1 and 2. As for 3, note that the current mobility draft does not address the double-jump problem from the client side. Therefore, if UPDATE inclusion gets hairy (i.e., has DoS issues), then I would not delay the RVS draft on account of that. On the other hand, if it is a simple extension, then it will probably be used by future mobility drafts. Tom _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec