From muru_lak2001@yahoo.com Tue Mar 1 05:19:03 2005 From: muru_lak2001@yahoo.com (Murugaraj) Date: Tue Mar 1 05:19:03 2005 Subject: [Hipsec] Draft: ESP usage in HIP?? In-Reply-To: <42020300.5040302@nomadiclab.com> Message-ID: <20050301101842.75932.qmail@web14306.mail.yahoo.com> --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-- From Gonzalo.Camarillo@ericsson.com Tue Mar 1 08:21:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Tue Mar 1 08:21:01 2005 Subject: [Hipsec] Agenda IETF 62 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648F5F@xch-nw-27.nw.nos.boeing.com> Message-ID: <42246C25.6010501@ericsson.com> 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 From thomas.r.henderson@boeing.com Wed Mar 2 12:28:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Mar 2 12:28:01 2005 Subject: [Hipsec] Draft: ESP usage in HIP?? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060A73@xch-nw-27.nw.nos.boeing.com> 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 From pekka.nikander@nomadiclab.com Sat Mar 5 22:15:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Mar 5 22:15:00 2005 Subject: [Hipsec] FW: I-D ACTION:draft-henderson-hip-generalize-00.txt In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C06648EE6@xch-nw-27.nw.nos.boeing.com> Message-ID: [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 From pekka.nikander@nomadiclab.com Sun Mar 6 16:41:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sun Mar 6 16:41:00 2005 Subject: [Hipsec] Looking for a volunteer to run the hipsec ML Message-ID: <52fae3df6c284f5e7a468ab11a95e5d0@nomadiclab.com> 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 From pekka.nikander@nomadiclab.com Tue Mar 8 15:38:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Mar 8 15:38:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: <073b01c51928$36411bb0$ef01a996@gmp> References: <42133673.5040907@piuha.net> <073b01c51928$36411bb0$ef01a996@gmp> Message-ID: <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> > 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 From yogesh.swami@nokia.com Tue Mar 8 16:08:01 2005 From: yogesh.swami@nokia.com (Yogesh Prem Swami) Date: Tue Mar 8 16:08:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> References: <42133673.5040907@piuha.net> <073b01c51928$36411bb0$ef01a996@gmp> <7274ca59e1cbadd7fdc4905ada0c14d0@nomadiclab.com> Message-ID: <1110316095.15384.36.camel@atcp01.americas.nokia.com> [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 From pekka.nikander@nomadiclab.com Tue Mar 8 17:01:03 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Mar 8 17:01:03 2005 Subject: [Hipsec] SHA1 broken? 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> Message-ID: > 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 From shep@alum.mit.edu Tue Mar 8 17:28:02 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Tue Mar 8 17:28:02 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: Your message of Tue, 08 Mar 2005 16:01:29 -0600. Message-ID: 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 From Julien.Laganier@Sun.COM Tue Mar 8 17:54:00 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Mar 8 17:54:00 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: References: Message-ID: <200503082356.53783.julien.laganier@sun.com> 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 From jeffrey.m.ahrenholz@boeing.com Wed Mar 9 12:15:00 2005 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Wed Mar 9 12:15:00 2005 Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> 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 From pekka.nikander@nomadiclab.com Wed Mar 9 15:36:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Mar 9 15:36:01 2005 Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> Message-ID: <8e4686f7143576ff768097da222c1452@nomadiclab.com> > 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 > From yushunwa@ISI.EDU Wed Mar 9 17:08:00 2005 From: yushunwa@ISI.EDU (Yushun Wang) Date: Wed Mar 9 17:08:00 2005 Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) In-Reply-To: <8e4686f7143576ff768097da222c1452@nomadiclab.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> Message-ID: <422F737D.2010003@isi.edu> 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-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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-- From pekka.nikander@nomadiclab.com Wed Mar 9 17:28:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Mar 9 17:28:01 2005 Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) In-Reply-To: <422F737D.2010003@isi.edu> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> <422F737D.2010003@isi.edu> Message-ID: <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> > 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 From yushunwa@ISI.EDU Wed Mar 9 18:06:01 2005 From: yushunwa@ISI.EDU (Yushun Wang) Date: Wed Mar 9 18:06:01 2005 Subject: [Hipsec] FW: WG Review: Better-Than-Nothing Security (btns) In-Reply-To: <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361F6D@xch-nw-09.nw.nos.boeing.com> <8e4686f7143576ff768097da222c1452@nomadiclab.com> <422F737D.2010003@isi.edu> <87613825f91ff7da18aa42ae06265aa0@nomadiclab.com> Message-ID: <422F810F.9080806@isi.edu> 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-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature 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-- From Gonzalo.Camarillo@ericsson.com Wed Mar 9 18:21:01 2005 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Wed Mar 9 18:21:01 2005 Subject: [Hipsec] Null IPsec Message-ID: <422F84B5.8050209@ericsson.com> 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 From chvogt@tm.uka.de Wed Mar 9 19:07:01 2005 From: chvogt@tm.uka.de (Christian Vogt) Date: Wed Mar 9 19:07:01 2005 Subject: [Hipsec] Time Window Instead of CBA? Message-ID: <422F8F87.6080007@tm.uka.de> 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/ From jari.arkko@piuha.net Wed Mar 9 20:46:01 2005 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Mar 9 20:46:01 2005 Subject: [Hipsec] Time Window Instead of CBA? In-Reply-To: <422F8F87.6080007@tm.uka.de> References: <422F8F87.6080007@tm.uka.de> Message-ID: <422FA6D0.6080609@piuha.net> 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 From chvogt@tm.uka.de Wed Mar 9 22:19:01 2005 From: chvogt@tm.uka.de (Christian Vogt) Date: Wed Mar 9 22:19:01 2005 Subject: [Hipsec] CBA Presentation Slides Message-ID: <422FBC76.4060800@tm.uka.de> 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/ From rgm@htt-consult.com Thu Mar 10 10:47:01 2005 From: rgm@htt-consult.com (Robert Moskowitz) Date: Thu Mar 10 10:47:01 2005 Subject: [Hipsec] Weighing in on hash truncation In-Reply-To: <422F84B5.8050209@ericsson.com> References: <422F84B5.8050209@ericsson.com> Message-ID: <6.2.1.2.2.20050310103704.0512ea18@localhost> 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) From Julien.Laganier@Sun.COM Thu Mar 10 12:38:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Mar 10 12:38:01 2005 Subject: [Hipsec] Time Window Instead of CBA? In-Reply-To: <422FA6D0.6080609@piuha.net> References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@piuha.net> Message-ID: <200503101841.10575.julien.laganier@sun.com> 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 From pekka.nikander@nomadiclab.com Thu Mar 10 14:17:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Mar 10 14:17:00 2005 Subject: [Hipsec] Time Window Instead of CBA? In-Reply-To: <422FA6D0.6080609@piuha.net> References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@piuha.net> Message-ID: >> 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 From chvogt@tm.uka.de Thu Mar 10 14:33:01 2005 From: chvogt@tm.uka.de (Christian Vogt) Date: Thu Mar 10 14:33:01 2005 Subject: [Hipsec] Time Window Instead of CBA? In-Reply-To: References: <422F8F87.6080007@tm.uka.de> <422FA6D0.6080609@piuha.net> Message-ID: <4230A0D6.80005@tm.uka.de> 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/ From pekka.nikander@nomadiclab.com Fri Mar 11 10:28:03 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 11 10:28:03 2005 Subject: [Hipsec] HIP RG today starts at 1230, not 1300 as listed in Agenda Message-ID: <4727b872bed44442a7644919dc8007ab@nomadiclab.com> 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 From wivancic@grc.nasa.gov Fri Mar 11 16:50:00 2005 From: wivancic@grc.nasa.gov (ivancic) Date: Fri Mar 11 16:50:00 2005 Subject: [Hipsec] NAT traversal and cellular network administrative filtering Message-ID: <42321250.7030609@grc.nasa.gov> 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 From gmp@research.panasonic.com Mon Mar 14 11:52:00 2005 From: gmp@research.panasonic.com (Greg Perkins) Date: Mon Mar 14 11:52:00 2005 Subject: [Hipsec] SHA1 broken? References: <200503082356.53783.julien.laganier@sun.com> Message-ID: <00fb01c528b8$488de740$ef01a996@gmp> 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 > From miika@iki.fi Tue Mar 15 03:12:00 2005 From: miika@iki.fi (Miika Komu) Date: Tue Mar 15 03:12:00 2005 Subject: [Hipsec] about interops and the use of asymmetric algorithms Message-ID: 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/ From shep@alum.mit.edu Thu Mar 17 11:24:00 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Thu Mar 17 11:24:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: 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 From gmp@research.panasonic.com Thu Mar 17 13:55:00 2005 From: gmp@research.panasonic.com (Greg Perkins) Date: Thu Mar 17 13:55:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) References: Message-ID: <01c501c52b24$ff6f52f0$ef01a996@gmp> 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 > From tkoponen@iki.fi Thu Mar 17 16:46:02 2005 From: tkoponen@iki.fi (Teemu Koponen) Date: Thu Mar 17 16:46:02 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <01c501c52b24$ff6f52f0$ef01a996@gmp> References: <01c501c52b24$ff6f52f0$ef01a996@gmp> Message-ID: <20050317214550.GA4303@iki.fi> 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 From pekka.nikander@nomadiclab.com Fri Mar 18 05:23:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 18 05:23:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: <00fb01c528b8$488de740$ef01a996@gmp> References: <200503082356.53783.julien.laganier@sun.com> <00fb01c528b8$488de740$ef01a996@gmp> Message-ID: <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> 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 From pekka.nikander@nomadiclab.com Fri Mar 18 05:23:04 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 18 05:23:04 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: References: Message-ID: <0dc7934f2b58058408cf6673a8167487@nomadiclab.com> 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 From shep@alum.mit.edu Mon Mar 21 00:12:01 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Mon Mar 21 00:12:01 2005 Subject: 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: > > 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 From pekka.nikander@nomadiclab.com Mon Mar 21 05:29:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 21 05:29:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: References: Message-ID: >>> 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 From hipsec-rg@honor.trusecure.com Mon Mar 21 08:26:03 2005 From: hipsec-rg@honor.trusecure.com (Pekka Nikander) Date: Mon Mar 21 08:26:03 2005 Subject: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs) In-Reply-To: <01c501c52b24$ff6f52f0$ef01a996@gmp> References: <01c501c52b24$ff6f52f0$ef01a996@gmp> Message-ID: <338a8312a5298b0b8a4a27a61f7d3fb8@nomadiclab.com> 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 > From gmp@research.panasonic.com Mon Mar 21 13:21:03 2005 From: gmp@research.panasonic.com (Greg Perkins) Date: Mon Mar 21 13:21:03 2005 Subject: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs) References: <01c501c52b24$ff6f52f0$ef01a996@gmp> <338a8312a5298b0b8a4a27a61f7d3fb8@nomadiclab.com> Message-ID: <025201c52e44$e02f0980$ef01a996@gmp> 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 > From gurtov@cs.helsinki.fi Tue Mar 22 10:35:01 2005 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Tue Mar 22 10:35:01 2005 Subject: [Hipsec] legacy NAT traversal Message-ID: <42403B02.2070001@cs.helsinki.fi> 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 From thomas.r.henderson@boeing.com Tue Mar 22 19:40:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Mar 22 19:40:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> =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 From Julien.Laganier@Sun.COM Wed Mar 23 07:42:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Mar 23 07:42:01 2005 Subject: [Hipsec] Rendezvous and tunneling Message-ID: <200503231341.18902.julien.laganier@sun.com> 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 From miika@iki.fi Wed Mar 23 16:43:01 2005 From: miika@iki.fi (Miika Komu) Date: Wed Mar 23 16:43:01 2005 Subject: [Hipsec] Rendezvous and tunneling In-Reply-To: <200503231341.18902.julien.laganier@sun.com> References: <200503231341.18902.julien.laganier@sun.com> Message-ID: 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/ From petri.jokela@nomadiclab.com Thu Mar 24 00:36:00 2005 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Mar 24 00:36:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> Message-ID: <42425199.9030005@nomadiclab.com> 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 From Julien.Laganier@Sun.COM Thu Mar 24 04:41:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Mar 24 04:41:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <42425199.9030005@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060AB0@xch-nw-27.nw.nos.boeing.com> <42425199.9030005@nomadiclab.com> Message-ID: <200503241040.07029.julien.laganier@sun.com> 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 From shep@alum.mit.edu Thu Mar 24 09:53:00 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Thu Mar 24 09:53:00 2005 Subject: 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: 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 From thomas.r.henderson@boeing.com Thu Mar 24 20:21:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Mar 24 20:21:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> =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 From thomas.r.henderson@boeing.com Thu Mar 24 20:28:00 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Mar 24 20:28:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> =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 From pekka.nikander@nomadiclab.com Fri Mar 25 02:07:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 25 02:07:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0664907B@xch-nw-27.nw.nos.boeing.com> Message-ID: <6f0e0d3087413bac3366590d45fd0d94@nomadiclab.com> >>> 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 From pekka.nikander@nomadiclab.com Fri Mar 25 02:23:00 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Mar 25 02:23:00 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060AC4@xch-nw-27.nw.nos.boeing.com> Message-ID: <36ea1f7d7e9bc19349ce7f41478fc6ae@nomadiclab.com> >>> 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 From shep@alum.mit.edu Fri Mar 25 13:02:01 2005 From: shep@alum.mit.edu (Tim Shepard) Date: Fri Mar 25 13:02:01 2005 Subject: 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: > > 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 From pekka.nikander@nomadiclab.com Mon Mar 28 14:13:01 2005 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Mar 28 14:13:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) In-Reply-To: References: Message-ID: <5c6fb0512de042632562a70ca3f366d9@nomadiclab.com> >>> 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 From thomas.r.henderson@boeing.com Mon Mar 28 21:53:01 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Mar 28 21:53:01 2005 Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060ACA@xch-nw-27.nw.nos.boeing.com> =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 From miika@iki.fi Wed Mar 30 03:44:01 2005 From: miika@iki.fi (Miika Komu) Date: Wed Mar 30 03:44:01 2005 Subject: [Hipsec] SHA1 broken? In-Reply-To: <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> References: <200503082356.53783.julien.laganier@sun.com> <00fb01c528b8$488de740$ef01a996@gmp> <2a13381e827c10e9a1e6d7d855331e5a@nomadiclab.com> Message-ID: 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/ From Julien.Laganier@Sun.COM Wed Mar 30 13:02:01 2005 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Mar 30 13:02:01 2005 Subject: [Hipsec] Rendezvous and tunneling In-Reply-To: <200503231341.18902.julien.laganier@sun.com> References: <200503231341.18902.julien.laganier@sun.com> Message-ID: <200503302001.07602.julien.laganier@sun.com> 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 From thomas.r.henderson@boeing.com Wed Mar 30 14:09:00 2005 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Mar 30 14:09:00 2005 Subject: [Hipsec] Rendezvous and tunneling Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066490B2@xch-nw-27.nw.nos.boeing.com> =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