From joseph-so@gmx.net Thu Sep 2 03:56:01 2004 From: joseph-so@gmx.net (Joseph) Date: Thu Sep 2 02:56:01 2004 Subject: [Hipsec] Question about IPv4 and IPv6 in HIP In-Reply-To: <58B69D8C-FCAB-11D8-BFE0-000D9331AFB0@nomadiclab.com> Message-ID: <20040902065531.3490B7308@honor.icsalabs.com> Dear All, I am a new guy in HIP area. I am trying to understand about HIP. I have a very basic question related to HIP , IPv4 and IPv6. As I know that in HIP, TCP/UDP will be run on HIP and HIP can run on IPv4 and IPv6. However, if someone send a package from a IPv4 network to IPv6 network like this: Source<--- (IPv4 Network) ---> Router A<-- (IPv6 Network) ---> Destination How can the package arrive the Destination without the tunneling? Is that the router A will convert the package? How's the interworking? Thanks a lot. Yours faithfully, Joseph From pekka.nikander@nomadiclab.com Mon Sep 6 14:06:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 6 13:06:01 2004 Subject: [Hipsec] multi6 summary In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607F2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607F2@xch-nw-27.nw.nos.boeing.com> Message-ID: <32CE4237-0030-11D9-A093-00306571BE62@nomadiclab.com> Thanks for a good report, Tom. > This leaves problem v)-- the referrals problem for legacy applications > and stacks. The two main alternatives are to use IP addresses > (locators) as upper-layer identifiers, or to use HITs as transport > layer identifiers, and translate them to IP addresses for legacy > applications and APIs. Architecturally, the latter alternative > is cleaner, but the former one may have advantage if the HIP > exchange is delayed past the initial exchange... > > So in summary, it is my opinion (also expressed at the WG meeting) > that nothing needs to be done to the base spec now to accommodate > the multi6 problem. I agree. > One possible enhancement would be to suggest > that implementations use IP addresses as application layer identifiers > for legacy applications and sockets API. There is some discussion > of this problem in Appendix A of the base spec. Maybe new base spec > text is needed for that topic. I think such an mode of operation would be very useful, and it would be a good idea to have some more text in the base spec. I have some initial ideas how to support such a feature in our HIP implementation, but I don't know if we will implement it now. --Pekka From pekka.nikander@nomadiclab.com Mon Sep 6 14:10:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 6 13:10:01 2004 Subject: [Hipsec] Moving the base spec forward Message-ID: Dear HIP Chairs & Editors, We are long past our Base spec milestone. As I don't see any specific reason why the base spec couldn't move forward, I urge you to take whatever action is needed to get the base spec to LC and then to IESG. --Pekka Nikander From Gonzalo.Camarillo@ericsson.com Mon Sep 6 17:20:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Sep 6 16:20:01 2004 Subject: [Hipsec] Re: Moving the base spec forward In-Reply-To: References: Message-ID: <413CD555.3010506@ericsson.com> Pekka, we had a meeting with the editors in San Diego regarding this issue. After that meeting, David and I met our ADs, and the conclusion was that we will not add new stuff to the base spec at this time (e.g., for making it more multi6 friendly), but we will wait a little before WGLCing it to get some implementation experience which may be useful to fix potential bugs in the current spec. According to the editors, a realistic timeframe for sending the base spec to the IESG would be spring 05. We intend to update our miletone dates shortly. Thanks, Gonzalo Pekka Nikander wrote: > Dear HIP Chairs & Editors, > > We are long past our Base spec milestone. As I don't see any > specific reason why the base spec couldn't move forward, I urge > you to take whatever action is needed to get the base spec to > LC and then to IESG. > > --Pekka Nikander From pekka.nikander@nomadiclab.com Tue Sep 7 12:05:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 7 11:05:02 2004 Subject: [Hipsec] Looking for volunteers to help in Mac OS X version of HIP Message-ID: <51E4B597-00E8-11D9-BC14-000D9331AFB0@nomadiclab.com> Folks, During the last month I have ported the Ericsson FreeBSD HIP implementation to Mac OS X. It is organised as two kernel extensions (BEET and HIP), a user mode daemon (hipd) and a couple of utilities (hip-keygen and hipctrl). The main difference between this version and the original FreeBSD version is the following: - In the FreeBSD version, the BEET changes are integrated into the IPsec and PF_KEY code, thereby requiring you to run a custom kernel. - In this version, the BEET changes are implemented as an add-on kernel extension on the top of the existing IPsec and PF_KEY code, thereby allowing you to run the code with the standard kernel. Our plan is to continue with the integrated BEET approach for FreeBSD 5. However, right now the Mac OS X and FreeBSD code are slightly out of synch. We will clear this and synchronise the code bases during the next few weeks. Our current plan is to release all the user level code under GPL and the kernel code under the BSD license, but we are pending the final decision on the exact licensing terms. (The user level code was earlier and still is released under an OSS-compatible but not formally OSS-endorsed license, specific to Ericsson Finland.) I am now at the stage where basically all the code has been written but some minor ESP integration that still missing in the BEET module. I am able to run the HIP base exchange successfully, but shortly afterwards the kernel crashes due to something going wrong with mbufs. Unfortunately I cannot continue this work with the intensity that I've been doing it for the last month. Hence, I am looking for volunteers to help with the work. At this point I am only looking for people who preferably have two Mac OS X machines (or one Mac OS X and one Linux/FreeBSD machine) so that they can use the Apple remote GDB functionality, and who have some familiarity with BSD kernels. Also people that are interested in back-porting the code to FreeBSD 4 or other versions of BSD are welcome to start. The code is available through an anonymous pserver read-only / authenticated ssh read-write cvs repository. Once the licensing terms have been cleared, I will publicly announce the repository. Before that, we will also feed the integrated BEET code, for FreeBSD 5, to the repository. However, I am more than happy to give the login info to those willing to work actively already now. Please contact me directly if you are interested. --Pekka From mkousa@cc.hut.fi Wed Sep 8 19:38:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Sep 8 18:38:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 Message-ID: Assume that hosts A and B, both supporting mm-02 specification, have set up SAs. This is the situation after the base exchange (as in Figure 1 in mm-02). Then host A adds a new interface, so A creates a new SA for it and performs the things written in section 5.2 Host multihoming. Now B wants to rekey using the UPDATE mechanism as defined in the base specification (only NES and SEQ parameters). Selection of values what to put into the NES is trivial, because B has only one SA to update. When A receives the B's UPDATE, it has to reply to the UPDATE packet. The problem is now that what SPI value A has to put into the NES's field Old SPI ? The one from the SA which was set up during the base exchange or the one from the SA which was set up later ? Is the selection a matter of some policy, eg. update the SA we have used last when sending data to the peer ? Or are we just undeterministic: just update any SA so the update process finishes smoothly according to the specifications. Is the described issue a design error or just my own misunderstanding ? From jeffrey.m.ahrenholz@boeing.com Wed Sep 8 20:18:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Wed Sep 8 19:18:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361ECE@xch-nw-09.nw.nos.boeing.com> Could host A choose the SPI of the SA associated with the interface that = the UPDATE was received on? The destination address of the received = UPDATE may help in choosing the SPI to respond with -- although the = draft says "a basic property of HIP SAs is that the inbound IP address = is not used as a selector for the SA." (sect. 4.1) If B wants to rekey, = it seems that both SAs/SPIs will be affected. -Jeff -----Original Message----- From: Mika Kousa [mailto:mkousa@cc.hut.fi] Sent: Wed 9/8/2004 4:42 PM To: hipsec@honor.trusecure.com Cc:=09 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 Assume that hosts A and B, both supporting mm-02 specification, have set = up SAs. This is the situation after the base exchange (as in Figure 1 in = mm-02). Then host A adds a new interface, so A creates a new SA for it and=20 performs the things written in section 5.2 Host multihoming. Now B wants to rekey using the UPDATE mechanism as defined in the base=20 specification (only NES and SEQ parameters). Selection of values what to = put into the NES is trivial, because B has only one SA to update. When A = receives the B's UPDATE, it has to reply to the UPDATE packet. The = problem=20 is now that what SPI value A has to put into the NES's field Old SPI ? = The=20 one from the SA which was set up during the base exchange or the one = from=20 the SA which was set up later ? Is the selection a matter of some policy, eg. update the SA we have used = last when sending data to the peer ? Or are we just undeterministic: = just=20 update any SA so the update process finishes smoothly according to the=20 specifications. Is the described issue a design error or just my own=20 misunderstanding ? _______________________________________________ Hipsec mailing list Hipsec@honor.trusecure.com http://honor.trusecure.com/mailman/listinfo/hipsec From Jan.Melen@nomadiclab.com Thu Sep 9 02:44:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Thu Sep 9 01:44:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: References: Message-ID: <200409090948.18423.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Thursday 09 September 2004 02:42, Mika Kousa wrote: > Assume that hosts A and B, both supporting mm-02 specification, have set > up SAs. This is the situation after the base exchange (as in Figure 1 in > mm-02). > > Then host A adds a new interface, so A creates a new SA for it and > performs the things written in section 5.2 Host multihoming. > > Now B wants to rekey using the UPDATE mechanism as defined in the base > specification (only NES and SEQ parameters). Selection of values what to > put into the NES is trivial, because B has only one SA to update. When A > receives the B's UPDATE, it has to reply to the UPDATE packet.=20 How has your implementation gotten out from the rekeying state if it has no= t=20 sent a NES parameter that would create a new SA? Atleast base spec says tha= t=20 the update must be ACKed and a NES parameter received before you can move=20 back to the established state. This would mean that you'll probably have tw= o=20 pairs of SAs on both ends. Not one pair and a half as you are suggesting if= I=20 have understood you correctly. > The problem=20 > is now that what SPI value A has to put into the NES's field Old SPI ? The > one from the SA which was set up during the base exchange or the one from > the SA which was set up later ? You'll anyway have to pair these SAs in order to know which SA is associate= d=20 to which interface otherwise you will be asking for trouble. From this=20 pairing you know that if you'll receive with old SPI X value then the=20 corresponding old SPI Y value is the one to put in to the NES.=20 Next question probably is that the B has only one interface well then the B= =20 has to do some sort of "virtual" interface for itself because B still has t= wo=20 different routes to A as A has said that I'll have two different interfaces= =2E=20 Now If the B also creates a new interface then this gets interesting and th= e=20 number of created SAs is a policy matter IMHO. Regards, Jan =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBP/yup4iklvjQtTgRAo2lAKCuWwM8c5sHnXRfGS5Khp/xgUbF2wCcCbw0 cSTAgVdUWNdUZNHU9IyyfPg=3D =3D51+z =2D----END PGP SIGNATURE----- From mkousa@cc.hut.fi Thu Sep 9 08:14:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Sep 9 07:14:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: <200409090948.18423.Jan.Melen@nomadiclab.com> References: <200409090948.18423.Jan.Melen@nomadiclab.com> Message-ID: On Thu, 9 Sep 2004, Jan Mikael Melen wrote: -> On Thursday 09 September 2004 02:42, Mika Kousa wrote: -> > Assume that hosts A and B, both supporting mm-02 specification, have set -> > up SAs. This is the situation after the base exchange (as in Figure 1 in -> > mm-02). -> > -> > Then host A adds a new interface, so A creates a new SA for it and -> > performs the things written in section 5.2 Host multihoming. -> > -> > Now B wants to rekey using the UPDATE mechanism as defined in the base -> > specification (only NES and SEQ parameters). Selection of values what to -> > put into the NES is trivial, because B has only one SA to update. When A -> > receives the B's UPDATE, it has to reply to the UPDATE packet. -> -> How has your implementation gotten out from the rekeying state if it has not -> sent a NES parameter that would create a new SA? Atleast base spec says that -> the update must be ACKed and a NES parameter received before you can move -> back to the established state. This would mean that you'll probably have two -> pairs of SAs on both ends. Not one pair and a half as you are suggesting if I -> have understood you correctly. Maybe you misunderstood a little bit, I guess. I try to clarify a bit (assuming that I read the specification correctly): After the base exchange: --SPI_AtoB_1--> A B <--SPI_BtoA_1-- A adds a new interface which has SPI=SPI_BtoA_2. According to section "5.2 Host multihoming": A sends UPDATE(NES(Old SPI=SPI_BtoA_2, New SPI=SPI_BtoA_2), SEQ) B sends UPDATE(NES(Old SPI=SPI_AtoB_1, New SPI=SPI_AtoB1'), SEQ, ACK) A sends UPDATE(ACK) (SPI_AtoB1' indicates that it replaces the old SPI SPI_AtoB1.) Now A and B are back in established state, and B sees that it can select from two possible SPIs of A: --SPI_AtoB_1'--> A B <--SPI_BtoA_1-- <--SPI_BtoA_2-- See, no two pairs of SAs. I have understood that a host can have 1..n active SAs at the same time, so SAs need not to be "paired" somehow. Or they even can not be paired: how to pair SAs if A has 3 SAs and B has 4 SAs ? Then host B wants to rekey: B sends UPDATE(NES(Old SPI=SPI_AtoB_1', New SPI=Old SPI=SPI_AtoB_1''), SEQ) A sends UPDATE(NES(Old SPI= X ..) This is the issue I was just thinking: how to select the SPI X. "Is it SPI_BtoA_1 or SPI_BtoA_2 or what ? And why ?" -> You'll anyway have to pair these SAs in order to know which SA is associated -> to which interface otherwise you will be asking for trouble. From this -> pairing you know that if you'll receive with old SPI X value then the -> corresponding old SPI Y value is the one to put in to the NES. I'll have to think about this issue a little bit more. Especially what this pairing of SAs mean from an implementation point of view. -> Next question probably is that the B has only one interface well then the B -> has to do some sort of "virtual" interface for itself because B still has two -> different routes to A as A has said that I'll have two different interfaces. These virtual intefaces add complexity to the implementation. -> Now If the B also creates a new interface then this gets interesting and the -> number of created SAs is a policy matter IMHO. Currently I'm trying to implement some level of support for mm-02. It has been a while since a read the mm-02, so I can not yet say if there are any flaws in the mm-02 regarding the handling of multiple SA handling. From mkousa@cc.hut.fi Thu Sep 9 08:24:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Sep 9 07:24:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361ECE@xch-nw-09.nw.nos.boeing.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361ECE@xch-nw-09.nw.nos.boeing.com> Message-ID: On Wed, 8 Sep 2004, Ahrenholz, Jeffrey M wrote: -> Could host A choose the SPI of the SA associated with the interface -> that the UPDATE was received on? The destination address of the -> received UPDATE may help in choosing the SPI to respond with -- -> although the draft says "a basic property of HIP SAs is that the -> inbound IP address is not used as a selector for the SA." (sect. 4.1) -> If B wants to rekey, it seems that both SAs/SPIs will be affected. This looks like one possible alternative. If the implementation uses the suggested "one SA per interface" scheme, then I think that the selection of correct SPI to use in the reply-UPDATE is quite simple to implement. Just get the interface through which the packet was received, and then perform a simple lookup from the network_interface-SA relationship table. From Jan.Melen@nomadiclab.com Fri Sep 10 03:11:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Fri Sep 10 02:11:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: References: <200409090948.18423.Jan.Melen@nomadiclab.com> Message-ID: <200409101016.16924.Jan.Melen@nomadiclab.com> =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 09 September 2004 15:18, Mika Kousa wrote: > > After the base exchange: > > --SPI_AtoB_1--> > A B > <--SPI_BtoA_1-- > > > A adds a new interface which has SPI=3DSPI_BtoA_2. According to section "= 5.2 > Host multihoming": > > A sends UPDATE(NES(Old SPI=3DSPI_BtoA_2, New SPI=3DSPI_BtoA_2), SEQ) > B sends UPDATE(NES(Old SPI=3DSPI_AtoB_1, New SPI=3DSPI_AtoB1'), SEQ, ACK) > A sends UPDATE(ACK) > > (SPI_AtoB1' indicates that it replaces the old SPI SPI_AtoB1.) > > Now A and B are back in established state, and B sees that it can select > from two possible SPIs of A: > > --SPI_AtoB_1'--> > A B > <--SPI_BtoA_1-- > <--SPI_BtoA_2-- > > See, no two pairs of SAs. I have understood that a host can have 1..n > active SAs at the same time, so SAs need not to be "paired" somehow. Or > they even can not be paired: how to pair SAs if A has 3 SAs and B has 4 > SAs ? Yes, I'll see but how are you planning to use those SAs. For example if=20 interfaces on A have different link speeds?=20 You will never be able to use the full link capacity from either interface = as=20 returning packets are always going through one interface. (You have one pai= r=20 and a half) OR are you planning to use the AtoB SA on two different interfaces then I'l= l=20 have to ask how are planning to protect yourself from replay protection=20 window over run? Regards, Jan =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBQVS+p4iklvjQtTgRAsfdAJwJCuD7NvOx6fuEuRQWWrGuUCgrDwCeKUcV fQJt3/rUWrDacz4dUGhFDus=3D =3DC87h =2D----END PGP SIGNATURE----- From yogesh.swami@acm.org Sat Sep 11 19:18:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Sat Sep 11 18:18:01 2004 Subject: [Hipsec] Moving the base spec forward Message-ID: <20040911232318.87825.qmail@web81205.mail.yahoo.com> Hi, I sent a big part of these comments to the authors directly, but may be it's useful to discuss this on the mailing list as well. Some General Comments: * Motivation for not using IKE (+MobIKE). The draft needs to motivate the need for a new key exchange protocol. If I understand right, there are three different parts to HIP. First is the issue of securely naming the TCP/IP kernel. HIs and HITs do this job superbly, although any name could do the job as long as public-keys could be easily/securely bound to that name. The second issue is how to use these HI/HITs to get a security association. For this the draft proposes to use HIP exchange. IMO, however, IKE (+MOBIKE) with public-key encryption (which can be obtained from DNNSec) can achieve almost everything that this draft achieves. The third issue is how does the key exchange protocol tells the kernel to do IP to HIT flipping (among other things). BTW, I am not against a new key exchange protocol; just need to see some good reason for a new one (for example, if HIP exchange will reduce the connection setup latency compared to IKE). * A protocol-type just for a key exchange? Why do we need a protocol type just for the key exchange. To me it seems frivolous to assign a protocol type for a 4 message exchange which could very well be done at the application layer using UDP. I could not see any advantage of doing the key exchange at IP layer. But I can see quite a few disadvantages. The biggest disadvantage is that if HIP is implemented in Kernel, every time there is a need for an upgrade, for example due to bugs, broken (colliding) MACs, broken DH (sub)groups, you will need a kernel upgrade. Another disadvantage is that it's hard to log events from the kernel in a reliable way. Yet another disadvantage is that keeping human-in-the-loop in the authentication process is more difficult in the kernel. IKE is implemented on UDP for a good reason. HIP draft needs to justify why those reasons are not valid. * Optimize for most common case. The cookie and puzzle mechanisms are quite nice, but it assumes that all Initiators are guilty until proved innocent. In the real world, however, more than 99% of time hosts are innocent and the puzzle and cookie mechanism is just an overhead. A much better case for HIP would be to have a one round trip key exchange--with the DoS protection switched on only if the responder thinks it's under attack. [[ Consider, for example, a simple exchange such as the following that can allow the Initiator to start sending data right after one RTT. 1. I->R: g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, encrypt_with_g^ir {[HI-R,]R: HIT-I, HIT-R, encrypt_with_g^ir_/_random_key{HI-I, USER_ID-I, SPI-I} HMAC, SIG-I private_key{random_key} Under DoS suspicion, or if the DH groups don't match, the responder might tell the Initiator to do the puzzle stuff with the appropriate difficulty. ]]> Specific comments (assuming people want to keep the key exchange as is.) * Page-12: I-1 needs to have a type which says what DH groups Initiator supports. We should not assume that I-1 can/will-want to handle all the DH groups. Additionally, if Responder cannot select any of the proposed groups, it should say something. * Page-12: I think all messages, including I1 should contain a nonce/cookie (similar to R1 counter to match incoming and outgoing requests) in addition to HITs. For example, If the local policy requires one SA per USER_ID, then the present key exchange will not be able to meet these requirements. * Page-12: The key exchange on this page is somewhat unclear. I kept flipping between section 4, 7, 6, and 5 (often in that order) to figure out which message means what. It will be nice to explain all the messages right underneath the figure. Also, its not clear which parts of the message are included in the signature, and which ones are left out. (Of course, if someone reads the entire draft, she'll be able to figure out everything. I am just suggesting to provide a short description in section 4.) * Page-14: The description of what is included in the signature for R1 on page 14 and page 51 are inconsistent. On page 14, g^r is left out of signature calculation; on 51 it's included. I would personally prefer the entire signature out from R1 (i.e., there is no need for HIP_SIGNATURE_2). Removing SIG_2 in R1 doesn't hurt MITM issues because R2 is still signed. Additionally, I would modify I2 to contain HMAC and signature (similar to R2) than just a signature. HMAC on I2 proves a lot more than the signature alone. R2 is okay. * Page-15: ""The packets R1, I2, and R2 implement a standard authenticated DH..."". Draft needs a reference here. I guess you mean ISO based scheme here, right? * Page-16: I'm not sure what is the attacker going to gain from replaying R1 and I2. The attacker cannot derive the DH keys by replaying R1/I2. She might be able to force the Initiator/Responder to solve the puzzle (but that is a lot less computation than the Signature verification). So I would suggest removing the replay protection text. (I would still keep R1-COUNTER as a nonce but not keep states across reboots.) Warning: I might have missed something here. IMO, if more than one R1 or I2, they should all be considered valid until a right authentication comes. Following IKEv2 design choices... * Page-16: More text is needed about caching the random number r of g^r in R1. BTW, how does this protocol behave if the random number r is deleted and g^r arrives after that. It should send new g^r and the Initiator should be able to accept it (section 8.7 doesn't seem to say anything either. I might have missed it.) * Page-37: HOST_ID should probably be renamed USER_ID. This field also needs a OPAQUE type for unknown HOST_ID types (e.g., cell-phone numbers etc). Also, it might be good to say in the introduction that a HOST_ID is different from HITs/HIs, just to avoid confusion. * The SPIs needs to be encrypted. It provides limited user traffic confidentiality. * Page-40: Order of concatenation for signature calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 are not clear. It's better to use || than text, which is confusing to me. To summarize, I would prefer the key exchange to look something like: I->R: IP( HIP( I1-COUNTER /* just a random number */ R1-COUNTER /* = 0 */ HIP-TRANSFORM /* with list of DH groups */ )) R->I: IP( HIP( Both counters; no change except remove HIP_SIGNATURE_2 HOST_ID /* ? why is this here in clear ? */ /* Probably better to move it to R2. ID protection from passive attacker is still a good idea. */ ) ) I->R: IP( HIP( Both counters. no change, except add a new field HMAC. I am not sure if signing the whole message has any advantage over just encrypting the HMAC with private key. ) ) R->I: IP( HIP( Both counters; No change. But Probably better to put encrypted HOST_ID here instead in R1. Before authenticating this message, policies won't be enforced anyway. ) ) Comments? I think more people need to read this draft before the Last Call. Thanks Yogesh From yogesh.swami@acm.org Sat Sep 11 20:33:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Sat Sep 11 19:33:00 2004 Subject: [Hipsec] Moving the base spec forward In-Reply-To: <20040911232318.87825.qmail@web81205.mail.yahoo.com> Message-ID: <20040912003751.24556.qmail@web81206.mail.yahoo.com> Oops! I garbled some text during cut-n-paste. Please replace the following text with the text underneath it. > [[ Consider, for example, a simple exchange such as the > following that can allow the Initiator to start sending data > right after one RTT. > > 1. I->R: g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups > > 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, > encrypt_with_g^ir {[HI-R,]R: HIT-I, HIT-R, > encrypt_with_g^ir_/_random_key{HI-I, > USER_ID-I, SPI-I} HMAC, SIG-I > private_key{random_key} > [Replace with:] R: g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, encrypt_with_g^ir {[HI-R,], USER_ID-R, SPI-R}, HMAC(KEYMAT, all previous fields), SIG-R At this point Initiator will be able to start sending the packets (TCP packets, for example). The responder still needs to authenticate the Initiator, but that could be done in parallel. 3. I->R: HIT-I, HIT-R, encrypt_with_g^ir_--or--_random_key{HI-I, USER_ID-I, SPI-I} HMAC, SIG-I private_key{random_key} --- Sorry about that. Thanks YOgesh From Gonzalo.Camarillo@ericsson.com Mon Sep 13 06:34:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Mon Sep 13 05:34:01 2004 Subject: [Hipsec] IETF 60 MoM Message-ID: <414578B1.1030502@ericsson.com> Folks, we will be submitting shortly the minutes of the HIP meeting in San Diego, which are available at: http://hip.piuha.net/meetings/ietf60/notes/ietf60-hip-minutes.html The notes and a jabber log are available at: http://hip.piuha.net/meetings/ietf60/notes/ Regards, Gonzalo HIP co-chair From capacity77@tin.it Mon Sep 13 07:13:00 2004 From: capacity77@tin.it (capacity77@tin.it) Date: Mon Sep 13 06:13:00 2004 Subject: [Hipsec] layer Message-ID: <4119713300014466@ims6a.cp.tin.it> Hi! could anybody tell me which should the level of HIP in layer architecture= ? higher or lower than IP's? capacity From pekka.nikander@nomadiclab.com Mon Sep 13 07:23:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 13 06:23:01 2004 Subject: [Hipsec] layer In-Reply-To: <4119713300014466@ims6a.cp.tin.it> References: <4119713300014466@ims6a.cp.tin.it> Message-ID: > could anybody tell me which should the level of HIP in layer > architecture? > higher or lower than IP's? In most presentations it is shown on the top of IP, just below TCP and UDP. In practise, most implementations seem to integrate it within the IP layer, in one way or another. IIRC, the architecture draft discusses this issue briefly. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Sep 13 07:53:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 13 06:53:01 2004 Subject: [Hipsec] Moving the base spec forward In-Reply-To: <20040911232318.87825.qmail@web81205.mail.yahoo.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> Message-ID: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Good questions and comments, we need more like this. > I sent a big part of these comments to the authors directly, but > may be it's useful to discuss this on the mailing list as well. [I'll answer to that next, after this one, cc:ing the relevant parts to the list.] > * Motivation for not using IKE (+MobIKE). The original motivation was that IKEv1 is not so well defined. To put it bluntly, it was clunky. The situation is slightly different now. It might be possible to reuse IKEv2 for HIP. However, it has been an explicit design goal to make the HIP base exchange as simple as possible while still retaining the overall architectural goals, including DoS protection. From that point of view, IKEv2 is too complex. One bigger issue is relationship to middlex boxes, though. HIP has been designed to be middle box friendly, explicitly keeping fields that middle boxes might inspect, including SPIs, in clear text. IKE favours confidentiality and secrecy here, HIP doesn't. > The draft needs to motivate the need for a new key exchange > protocol. Actually, that is the task of the architecture draft. If it doesn't, or does the job poorly, please indicate which parts of the architecture draft you would like to see improved. (-06 is malformated, I'm in the process of issuing -07. -05 may be easier to read, if you can find it.) > IMO, however, IKE (+MOBIKE) with public-key encryption (which can > be obtained from DNNSec) can achieve almost everything that this > draft achieves. Yes it can, with the possible exception of different approach to DoS protection. However, it is considerably more complex than the HIP base exchange. > * A protocol-type just for a key exchange? Well, architecturally all traffic flows over the new protocol type, as there is a new layer between IP and upper layers. Using ESP is just a convenient shorthand. > .... But I can see quite a few disadvantages. The biggest > disadvantage is that if HIP is implemented in Kernel, every time > there is a need for an upgrade, for example due to bugs, broken > (colliding) MACs, broken DH (sub)groups, you will need a kernel > upgrade. Actually not. You can easily implement 99% of HIP on user level. IMHO, it is useful to push I1 handling to the kernel (or even to a separate node, see the hi3 draft), but do the rest of processing in user level. But different implementations are differ. The rest of your disadvantages don't apply once you realise this. > IKE is implemented on UDP for a good reason. HIP draft needs to > justify why those reasons are not valid. Again, see the architecture draft, and please indicate if it in your opinion is not clear enough. > * Optimize for most common case. You can vary the cookie difficulty. There is nothing wrong in making K=0 by default. Currently, the main goal is to keep the protocol as simple as possible, not to optimise it for any specific use case. > following that can allow the Initiator to start sending data > right after one RTT. (This is just an example. It might have > security flaws.) > > 1. I->R: g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups > > 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, > encrypt_with_g^ir {[HI-R,], USER_ID-R, SPI-R}, > HMAC(KEYMAT, all previous fields), SIG-R Ever heard about TCP SYN flooding? :-) That is a real problem, even if CPU exhaustion attacks may not be (yet). It would be possible to design HIP in such a way that you don't need I1/R1 exchange (and I know that some people have considered such variations for various purposes, including broadcast R1s), but that would add complexity. Hence, preserved for later consideration. > Specific comments (assuming people want to keep the key exchange as > is.) > > * Page-12: I-1 needs to have a type which says what DH groups Initiator > supports. We should not assume that I-1 can/will-want to > handle all the DH groups. Additionally, if Responder cannot > select any of the proposed groups, it should say something. Good point. I think we have discussed this before, but I don't know what were the thoughts about this. Anyone? > * Page-12: I think all messages, including I1 should contain a > nonce/cookie (similar to R1 counter to match incoming and > outgoing requests) in addition to HITs. For example, > If the local policy requires one SA per USER_ID, > then the present key exchange will not be able to meet > these > requirements. I don't understand this comment. Please elaborate. (Editorial comments left to Petri, the current editor.) > I would personally prefer the entire signature > out from R1 (i.e., there is no need for HIP_SIGNATURE_2). > Removing SIG_2 in R1 doesn't hurt MITM issues because R2 > is still signed. No, it doesn't protect against MitM. It is there to protect the hosts from certain kinds of replay attacks. I think the draft says it somewhere, but maybe it doesn't? > Additionally, I would modify I2 to > contain HMAC and signature (similar to R2) than just > a signature. HMAC on I2 proves a lot more than the > signature alone. How come? I don't understand, but maybe I'm blind. Supposedly the Responder hasn't got any state when it gets I2. > * Page-15: ""The packets R1, I2, and R2 implement a standard > authenticated DH..."". Draft needs a reference here. I > guess you mean ISO based scheme here, right? A reference to Hugo's SIGMA paper? Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO 2003: 400-425 > * Page-16: I'm not sure what is the attacker going to gain from > replaying R1 and I2. The attacker cannot derive the > DH keys by replaying R1/I2. She might be able to force the > Initiator/Responder to solve the puzzle (but that is a lot > less computation than the Signature verification). Not necessarily. With large K, solving the puzzle takes a lot of CPU. > IMO, if more than one R1 or I2, they should all be > considered valid until a right authentication comes. > Following IKEv2 design choices... Good point. Please elaborate so that we understand better, I haven't been following IKEv2. > * Page-16: More text is needed about caching the random number r of g^r > in R1. BTW, how does this protocol behave if the random > number r is deleted and g^r arrives after that. It should > send new g^r and the Initiator should be able to accept it > (section 8.7 doesn't seem to say anything either. I might > have missed it.) Suggested text to be added? > * Page-37: HOST_ID should probably be renamed USER_ID. This field also > needs a OPAQUE type for unknown HOST_ID types (e.g., > cell-phone numbers etc). Good point, though I'm a little bit reluctant as it slightly adds complexity. HIP is a _Host_ Identity Protocol, after all, even though various people (me included) have pondered issues like supporting multiple Host Identities within a multi-user host etc. > * The SPIs needs to be encrypted. It provides limited user traffic > confidentiality. Definitely not. Here I (and I guess a number of other people) disagree strongly. HIP has been explicitly designed to be middle box friendly, which IKE (including IKEv2) is not. > To summarize, I would prefer the key exchange to look something like: > > I->R: IP( HIP( > I1-COUNTER /* just a random number */ > R1-COUNTER /* = 0 */ > HIP-TRANSFORM /* with list of DH groups */ > )) Responder could select a suitable pre-computed R1 from a pool, using the suggested D-H? Adding optional HIP-TRANSFORM here might be a good idea. Or even make it mandatory, for simplicity's sake? I don't understand the need for the I1 nonce. To remove the need for R1 signature? Didn't we discuss that before? Anyone remembers the conclusions or cares to dig up the archives? > HOST_ID /* ? why is this here in clear ? */ > /* Probably better to move it to R2. > ID protection from passive attacker is > still a good idea. > */ Maybe, but IMHO not now. Something to remember for the next revision. See Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity Protection Framework for End-points", to appear in Security Protocols, Twelfth International Workshop, Cambridge, 24-28 April, 2004. > no change, except add a new field HMAC. > I am not sure if signing the whole message has > any advantage over just encrypting the HMAC with > private > key. You forget middle boxes. If you have the signature, there is no explicit benefit from the HMAC. If the responder knows the initator's identity, it can verify the signature before constructing the D-H keys. > I think more people need to read this draft before the Last Call. I strongly concur. --Pekka From pekka.nikander@nomadiclab.com Mon Sep 13 07:58:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 13 06:58:00 2004 Subject: [Hipsec] Moving the base spec forward In-Reply-To: <4140CE01.3070109@nokia.com> References: <4140CE01.3070109@nokia.com> Message-ID: > [[I skipped the mailing list; please feel free to put it back if you > want. ]] Did so. Didn't find anything that would have been different from the message that you sent to the ML. > I think more people need to read this draft before the Last Call, and > I will certainly read it once again. Hope these comments are useful. Your comments were _very_ useful indeed. I hope that you'll have time to really read the draft again. --Pekka From miika@iki.fi Mon Sep 13 08:53:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Sep 13 07:53:01 2004 Subject: [Hipsec] Moving the base spec forward In-Reply-To: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Message-ID: On Mon, 13 Sep 2004, Pekka Nikander wrote: > > Specific comments (assuming people want to keep the key exchange as > > is.) > > > > * Page-12: I-1 needs to have a type which says what DH groups Initiator > > supports. We should not assume that I-1 can/will-want to > > handle all the DH groups. Additionally, if Responder cannot > > select any of the proposed groups, it should say something. > > Good point. I think we have discussed this before, but I don't know > what were the thoughts about this. Anyone? > See the "DH Group selection " thread from: http://honor.trusecure.com/pipermail/hipsec/2003-December/thread.html To summarize, it is theoretically possible to negotiate two different DH group selection, but in practice this may be difficult. As a consequence, we negotiate only one DH group. Since we are negotiating of a single DH group, either party has to suggest the groups and the other has to accept one of them. HIP is designed to protect both the initiator and the responder from various kinds of attacks, but the emphasis is still on protecting the responder, IMHO. As a result, it is better for the responder to be the party that is allowed to make the suggestion to avoid initiators from overloading busy servers with overly large DH groups. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From miika@iki.fi Mon Sep 13 09:50:00 2004 From: miika@iki.fi (Miika Komu) Date: Mon Sep 13 08:50:00 2004 Subject: [Hipsec] Native HIP API Message-ID: I conclude my work on the native HIP API regarding to the master's thesis. The final version can be downloaded from the URL below: http://hipl.hiit.fi/hipl/hip-native-api-final.pdf The next set of changes will be applied on the forthcoming API draft. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From capacity77@tin.it Mon Sep 13 12:25:01 2004 From: capacity77@tin.it (capacity77@tin.it) Date: Mon Sep 13 11:25:01 2004 Subject: [Hipsec] personal HI Message-ID: <4119713300019285@ims6a.cp.tin.it> Hi there! I'd like to know some functionality about HIP, if it can provide a person= al key, a sort of HI static that a host can use everywhere in order to be re= cognized (even if he has different IP addresses) by a particular a router who give= s him a certain QoS. I want to use this key to make a corrispondence with a physical person an= d to give him a QoS wherever he uses internet. Is it possible using HIP? Another question: how HIT can generate a collision? Is the generation of the HI random, so it can happen that a random generated key is already in= use by any other one? From pekka.nikander@nomadiclab.com Mon Sep 13 14:37:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Sep 13 13:37:00 2004 Subject: [Hipsec] personal HI In-Reply-To: <4119713300019285@ims6a.cp.tin.it> References: <4119713300019285@ims6a.cp.tin.it> Message-ID: <984EBA22-05B4-11D9-A8F6-000D9331AFB0@nomadiclab.com> > I'd like to know some functionality about HIP, if it can provide a > personal > key, a sort of HI static that a host can use everywhere in order to be > recognized > (even if he has different IP addresses) Yes, so far. > by a particular a router who gives him a certain QoS. No, that QoS has been beyond the scope of the work. > I want to use this key to make a corrispondence with a physical person > and > to give him a QoS wherever he uses internet. Is it possible using HIP? Maybe. Not with the way it has been specified right now, but I don't see any reason why it couldn't be extended in such a way. > Another question: how HIT can generate a collision? Is the generation > of > the HI random, so it can happen that a random generated key is already > in > use by any other one? Well, HI generation is random. The probability that two hosts generate the same HI is extremely low, though, unless the hosts happen to use the same faulty random number generator. However, the probability that two different HIs hash into the same HIT is very small but not that small that it couldn't happen in real life. --Pekka From yogesh.swami@acm.org Mon Sep 13 15:14:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Sep 13 14:14:00 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Message-ID: <4145F262.8090805@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA6864CF482FA156CE4B2953B Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka- I split the e-mail into different parts. I guess, it's too late in the game, so I am not going to "fight" too much here, but see inline: ext Pekka Nikander wrote: > Good questions and comments, we need more like this. > >> I sent a big part of these comments to the authors directly, but >> may be it's useful to discuss this on the mailing list as well. > > > [I'll answer to that next, after this one, cc:ing the relevant > parts to the list.] > >> * Motivation for not using IKE (+MobIKE). > > > The original motivation was that IKEv1 is not so well defined. > To put it bluntly, it was clunky. > When I say IKE, I mean IKEv2. My bad. :-) IMO, it's important to consider IKEv2 for a variety of reasons. The biggest reason is that it will improve the usability of HIP. It's a lot harder, practically speaking, to convince people to buy/build a new product such as HIP when their older products (IKEv2) can already achieve something similar. I think we should learn the right lessons from IPv6 deployment. Also, the more number of key exchange protocols you have, the more fragments of secure, but isolated, networks you will have in future. It's not hard to envision cases where one organization only supports IKE (because they already spent like crazy on PKI), while the other one only has HIP. > The situation is slightly different now. It might be possible > to reuse IKEv2 for HIP. However, it has been an explicit design > goal to make the HIP base exchange as simple as possible while > still retaining the overall architectural goals, including DoS > protection. From that point of view, IKEv2 is too complex. > The basic IKEv2 is no more complex than HIP exchange, IMO. But, I agree that in case of DoS, there is a possibility of message explosion, but that's different from complexity (i.e., to me, ping-ponging a few messages only in case of DoS is not complexity, but a good design choice.) In addition, the security properties of IKEv2 is well understood. Hugo's paper has a provably secure analysis of SIGMA, on which IKE is based. This is not the case with HIP key exchange. (In SIGMA both sides provide a proof of possession of the ephemeral key by the HMAC. In HIP only Responder provides this proof in R2. This can have different, and unintended consequences... Haven't analyzed it yet, though.) > One bigger issue is relationship to middlex boxes, though. HIP > has been designed to be middle box friendly, explicitly keeping > fields that middle boxes might inspect, including SPIs, in clear > text. IKE favours confidentiality and secrecy here, HIP doesn't. > My preferred approach for middle boxes (some prefer evil-boxes) is to let the protocol break in its presence. Clearly, I'm in a minority here! :-) But I see your point. Although, I won't keep the SPI in clear, I can still live with it. Without SPI encryption, USER_ID encryption alone looses a few of its of benefits. >> The draft needs to motivate the need for a new key exchange >> protocol. > > > Actually, that is the task of the architecture draft. If it doesn't, > or does the job poorly, please indicate which parts of the architecture > draft you would like to see improved. (-06 is malformated, I'm > in the process of issuing -07. -05 may be easier to read, if you > can find it.) Well, I didn't find any discussion in draft-moskowitz-hip-arch-06.txt on why someone will choose a "low policy granularity" based key-exchange (i.e., present HIP) when another one already exists. Also, I am not clear why HIP has lower policy granularity. Isn't policy based on the USER_ID (e-mail. FQDN etc.) -- which HIP already has? Do you mean fancy ways of authenticating hosts, by policy granularity? I must be missing something here. > >> IMO, however, IKE (+MOBIKE) with public-key encryption (which can >> be obtained from DNNSec) can achieve almost everything that this >> draft achieves. > > > Yes it can, with the possible exception of different approach to > DoS protection. However, it is considerably more complex than the > HIP base exchange. You mention complexity a couple of times in your e-mail. To me it seems like the biggest complexity is reinventing a new key exchange. :-) I general, I won't reinvent the wheel if tweaking the existing ones meets my requirements. Depending upon other protocols is a good design principle, IMO. Not saying we should not have HIP key exchange. But do add some text on why? IESG might as well ask the same question. More in next e-mail. Thanks Yogesh [[Blanket Disclaimer: All opinions are solely mine, and doesn't represent the opinions of my employer.]] --------------enigA6864CF482FA156CE4B2953B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUXyaHkjMhOId4nzAQKYmgf/d7wWotwhZksMsa5eCBW9j4euq51X2qdx jiyYxHH0BDWrk4Bg9JLfq/poEl0v2z1GNeDStX9b0C7MXwiXdhcSmxKmlXICm0pl SOR3CuWb0RoZO+pL6rj7XWc4zQJ9PuOUA9tsK4uVjOXQmsEuWO5GWNb5SkQ6tJtH MCB/Y2Zq8CyeB5MSUgccbCEKolKy5M8fltbfHQmHoXtLavUNGDnI1SoxiXuD0Tof v8ChG5lmRTO1XGlzraGYR5itaPpMeRextYzf6yHj08Cnsoki/i4CmYprSYBrJRvB 8n/8OLyrAr0KCfJBCiwtxWde/jfOlwEFOPtikzz8BZGC1K6HSzVo3Q== =64HB -----END PGP SIGNATURE----- --------------enigA6864CF482FA156CE4B2953B-- From yogesh.swami@acm.org Mon Sep 13 15:16:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Sep 13 14:16:01 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Message-ID: <4145F2A3.5030204@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4803AE4239ECFD7D595D74F9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 2nd e-mail. > >> * A protocol-type just for a key exchange? > > > Well, architecturally all traffic flows over the new protocol type, > as there is a new layer between IP and upper layers. Using ESP > is just a convenient shorthand. I strongly disagree with this. Let's backtrack a little bit here. In the past (and present) we have used the socket quadruple to demux different connection. The assumption was that the quad will not change after connection setup. With mobility and multi homing, the IP address change, so we need a new mechanism to demux different connections. You are achieving this through SPIs. (Note also, that the HIT flipping as defined in the draft is also not essential. Keeping it there might still be a good idea, if you don't want to change your TCP code, but it's not needed, in principle. The connection is already demuxed by the time of IPsec processing, beyond which you only need to look at port numbers.) So the first issue is demuxing. That is, how do I demux different connections, if my IP address keeps changing. The second issue is how do I maintain this binding between the demux numbers (i.e., SPI in this case) and the present IP address of the host. This issue is completely separate from the choice of using an SPI, or a new IP option or what have you. HIP base, to me seems like a protocol for manging this demux binding. If you were to propose a new protocol type that will be carried in every packet (just as SPI) for the purpose of demuxing (and I would have preferred that over ESP), I wouldn't have complained. But I strongly disagree that the management of demuxing numbers should be given a protocol type and should be mixed. I would like to listen from other people on what they think. > >> .... But I can see quite a few disadvantages. The biggest >> disadvantage is that if HIP is implemented in Kernel, every time >> there is a need for an upgrade, for example due to bugs, broken >> (colliding) MACs, broken DH (sub)groups, you will need a kernel >> upgrade. > > > Actually not. You can easily implement 99% of HIP on user level. If you're going to implement in user level, then just use UDP. Isn't that the reasons why UDP exists? Also, if you want to support multicast using HIP, you will need yet another key exchange--substantially different from HIP key exchange. Are you proposing to use another protocol-type for multicast key exchange. (Also, in case of multicast, one key exchange might not fit all use cases, so you will need a lot of protocol types if you want to do it at IP layer. And yes, you can multiplex all of them on the same protocol type, but then it will be my turn to cry the complexity wolf. :-) ) > IMHO, it is useful to push I1 handling to the kernel (or even to > a separate node, see the hi3 draft), but do the rest of processing > in user level. But different implementations are differ. > > The rest of your disadvantages don't apply once you realise this. To me, architecturally it seems cleaner to keep the SA management (i.e., 3.5 layer management) separate from the 3.5 layer itself. HIP key exchange is a 3.5 layer manager, and there is no need to mix it with the 3.5 demuxing layer itself--which you achieve through SPI. > >> IKE is implemented on UDP for a good reason. HIP draft needs to >> justify why those reasons are not valid. > > > Again, see the architecture draft, and please indicate if it in your > opinion is not clear enough. > Well the arch document doesn't say anything about this either. Am I reading the right draft: http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-06.txt? Isn't this draft in RFC queue right now? --Yogesh --------------enig4803AE4239ECFD7D595D74F9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUXyo3kjMhOId4nzAQJEywf/dnv4kFPAJgTbhoB7MDBurZA6JdQOEFzf zOSk2M7UG1M0Hvp9aZ7VIueiQnMq2MEgeVjcrOUu0xjpPjBwq9huAa/apdbFDU2u u1mwxmD6a7Tpx0sE9zRXZ5B5fLkRmqd8BpUuoDvx6gDE7RaGLG5G2Opsg+ookVFf 7otrImlM7Xhgqac4nRb0MrdaH1S3I24QMP7J8Asj+tUE5+JKz/U/qg0FXjyaFblT CYDp7bg9usNZBrh5iEWdSdkOqOlN2mj+OvT2tg7nkGRKAsHUFW3+yxq7UUqK8/8G vcRNTVqf8r+Vm0LWuR07o/O06QqP73Fk1rKTwF4nMTkFJSTlJ2JRbg== =IX6E -----END PGP SIGNATURE----- --------------enig4803AE4239ECFD7D595D74F9-- From yogesh.swami@acm.org Mon Sep 13 15:16:04 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Sep 13 14:16:04 2004 Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Message-ID: <4145F2C6.8000505@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1844D61101FB9E3076625681 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 3rd. ext Pekka Nikander wrote: > >> * Optimize for most common case. > > > You can vary the cookie difficulty. There is nothing wrong in > making K=0 by default. Right, but you still loose a Round Trip. > > Currently, the main goal is to keep the protocol as simple as > possible, not to optimise it for any specific use case. > Well, considering a DoS attack is an optimization, isn't it? >> > following that can allow the Initiator to start sending data >> right after one RTT. (This is just an example. It might have >> security flaws.) >> >> 1. I->R: g^i, HIT-I, HIT-R, nonce-I, Supported-DH-Groups >> >> 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, >> encrypt_with_g^ir {[HI-R,], USER_ID-R, SPI-R}, >> HMAC(KEYMAT, all previous fields), SIG-R > > > Ever heard about TCP SYN flooding? :-) That is a real problem, even Never heard of it, really. Aha! Did the Babylonians face this kind of flooding? :-)) You removed the text below message 2 and changed the meaning completely. I was suggesting that if the responder *perceives* an attack, only then it should trigger the cookie/puzzle mechanism. If not, there is no need to waste a round trip. Here is the text from my previous message. "" 2. R->I: g^r, HIT-I, HIT-R, nonce-I, nonce-R, encrypt_with_g^ir {[HI-R,], USER_ID-R, SPI-R}, HMAC(KEYMAT, all previous fields), SIG-R At this point Initiator will be able to start sending the packets (TCP packets, for example). The responder still needs to authenticate the Initiator, but that could be done in parallel. 3. I->R: HIT-I, HIT-R, encrypt_with_g^ir_/_random_key{HI-I, USER_ID-I, SPI-I} HMAC, SIG-I private_key{random_key} Under DoS suspicion, or if the DH groups don't match, the responder might tell the Initiator to do the puzzle stuff with the appropriate difficulty. ]]> "" But I understand that you design goal is to let the responder select the right group etc., and that might interfere with what I am proposing. Which choice is better is debatable, though. --Yogesh --------------enig1844D61101FB9E3076625681 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUXyxnkjMhOId4nzAQJ15Qf+KWQGPvKHVCxmJvXcOWZ0mQj9NX0/pofM e2QcPpWU1LV0zFABVT90obon/eSoqxz/kqyiuhaJWuVG8+U6dV49F/0ByaO/mSH7 VATHNRR50ra9OVtuAnVLXufMcYV4Q+O1JfD66makleukrOSe1ZzYbH62XAYHrfz/ wnWKuob+ZxwhMWkyImFsAMtvRwhJS/3ap8gdUcXRvrAW7pU4RrWWq1q1RfJ07W0v EM9fNeaQG0xWAC8e+d0CZUGdfPMKzkCLb8nl/9+feKRBBF0QOiuWP/MHqfzclADl x4WGquGNtzw6tIAbFEZBSVfmU9UG8GrnDREF49R3WBtLJOfCIrS4ag== =LS3v -----END PGP SIGNATURE----- --------------enig1844D61101FB9E3076625681-- From yogesh.swami@acm.org Mon Sep 13 15:17:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Sep 13 14:17:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> Message-ID: <4145F320.3020208@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8058B04EBF392BC9A9FA298 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 4th, and last! I promise. ext Pekka Nikander wrote: >> Specific comments (assuming people want to keep the key exchange as is.) >> >> * Page-12: I-1 needs to have a type which says what DH groups Initiator >> supports. We should not assume that I-1 can/will-want to >> handle all the DH groups. Additionally, if Responder cannot >> select any of the proposed groups, it should say something. > > > Good point. I think we have discussed this before, but I don't know > what were the thoughts about this. Anyone? I read Mika's comments and the old discussion, but I still think it's useful to put HIP-TRANSFORM in I1. It's possible that the Initiator and Responder both consider a certain group to be safe, but the default choice on the two sides could be different. In those cases, HIP-XFRM in I1 will help. Also, just because I1 proposes a HIP transform, Responder doesn't have to accept it (so there is no chance of attacker degrading the quality of SA). It might send it's own choice anyways (falling back to the present scheme, to some extent.) > >> * Page-12: I think all messages, including I1 should contain a >> nonce/cookie (similar to R1 counter to match incoming and >> outgoing requests) in addition to HITs. For example, >> If the local policy requires one SA per USER_ID, >> then the present key exchange will not be able to meet these >> requirements. > > > I don't understand this comment. Please elaborate. > Okay, may be I misunderstood, so let me ask a question. Let's say I want to have 3 different SA between same hosts at the same time (because my local policy requires on 1 SA per TCP connection and all three TCP connections start at once.) How does HIP disambiguate between these three parallel ongoing key exchange. Does it mean SA creating should be sequential. I guess this is what you mean by coarse granular key exchange for HIP, right? Some text in either of the two drafts (base/arch) will help. > (Editorial comments left to Petri, the current editor.) > >> I would personally prefer the entire signature >> out from R1 (i.e., there is no need for HIP_SIGNATURE_2). >> Removing SIG_2 in R1 doesn't hurt MITM issues because R2 >> is still signed. > > > No, it doesn't protect against MitM. It is there to protect the > hosts from certain kinds of replay attacks. I think the draft > says it somewhere, but maybe it doesn't? > > >> Additionally, I would modify I2 to >> contain HMAC and signature (similar to R2) than just >> a signature. HMAC on I2 proves a lot more than the >> signature alone. > > > How come? I don't understand, but maybe I'm blind. Supposedly > the Responder hasn't got any state when it gets I2. Wow! back up a little bit. When Initiator receives R1, it can compute the session key. If you want to follow the design choice of sigma, you should provide a proof of possession of the ephemeral key by the HMAC, not just the signature as it is in the draft right now. But then, this makes me ask another question. How does the Responder get the public-key of the Initiator. If it's from DNSSec, then it's useful to use HMAC. If not, then why bother--you are anyway willing to risk identity mis binding. > >> * Page-15: ""The packets R1, I2, and R2 implement a standard >> authenticated DH..."". Draft needs a reference here. I >> guess you mean ISO based scheme here, right? > > > A reference to Hugo's SIGMA paper? > > Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated > Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO 2003: 400-425 > I disagree that the present key-exchange is based on SIGMA. That was the whole point of my question for a reference :-) >> * Page-16: I'm not sure what is the attacker going to gain from >> replaying R1 and I2. The attacker cannot derive the >> DH keys by replaying R1/I2. She might be able to force the >> Initiator/Responder to solve the puzzle (but that is a lot >> less computation than the Signature verification). > > > Not necessarily. With large K, solving the puzzle takes a lot of CPU. This is unnecessary protection, IMO. Also, what is the order of processing for these messages, i.e., do you fist verify the signature or compute the solution. If you verify the signature first -- as you should -- then aren't you opening up to some kind of DoS? Note that a counter (R1_COUNTER) doesn't help because a smart blind attacker can just send a value in the upper quarter of the number space with high probability of success, so the primitive sequence number check before signature verification will not help much. > >> IMO, if more than one R1 or I2, they should all be >> considered valid until a right authentication comes. >> Following IKEv2 design choices... > > > Good point. Please elaborate so that we understand better, I haven't > been following IKEv2. One way to get rid of the signature in R1 is to consider all R1s as a valid response. Since only a valid Initiator can provide an R2 (because of HMAC), its safe to delete the other invalid R1s after the key exchange is completed. IKEv2 draft does a better job than me in explaining these things ... so please see that. > >> * Page-16: More text is needed about caching the random number r of g^r >> in R1. BTW, how does this protocol behave if the random >> number r is deleted and g^r arrives after that. It should >> send new g^r and the Initiator should be able to accept it >> (section 8.7 doesn't seem to say anything either. I might >> have missed it.) > > > Suggested text to be added? You might want to check JFK paper (Steve Bellovin, et. al. "Just Fast Keying) on r caching. > >> * Page-37: HOST_ID should probably be renamed USER_ID. This field also >> needs a OPAQUE type for unknown HOST_ID types (e.g., >> cell-phone numbers etc). > > > Good point, though I'm a little bit reluctant as it slightly adds > complexity. HIP is a _Host_ Identity Protocol, after all, even though No. That's not what I meant. In the draft you refer to e-mail address, FQDN, etc as HOST_ID (you need these for polices, right?). This is confusing and it should be renamed USER_ID, IMO. Also adding an OPAQUE field there doesn't add complexity--or maybe this time I am "blind." :-) > various people (me included) have pondered issues like supporting > multiple Host Identities within a multi-user host etc. > >> * The SPIs needs to be encrypted. It provides limited user traffic >> confidentiality. > > > Definitely not. Here I (and I guess a number of other people) > disagree strongly. I can live with a clear SPIN--although it does make traffic confidentiality little worse. > > HIP has been explicitly designed to be middle box friendly, which > IKE (including IKEv2) is not. > Well IKEv2 does not have any problems (or it's being fixed) with middle boxes to the best of my knowledge. >> To summarize, I would prefer the key exchange to look something like: >> >> I->R: IP( HIP( >> I1-COUNTER /* just a random number */ >> R1-COUNTER /* = 0 */ >> HIP-TRANSFORM /* with list of DH groups */ >> )) > > > Responder could select a suitable pre-computed R1 from a pool, > using the suggested D-H? Adding optional HIP-TRANSFORM here > might be a good idea. Or even make it mandatory, for simplicity's > sake? > > I don't understand the need for the I1 nonce. To remove the > need for R1 signature? > But also to allow parallel SA creation. May be you don't want to consider in the design choice. > Didn't we discuss that before? Anyone remembers the conclusions > or cares to dig up the archives? > >> HOST_ID /* ? why is this here in clear ? */ >> /* Probably better to move it to R2. >> ID protection from passive attacker is >> still a good idea. >> */ > > > Maybe, but IMHO not now. Something to remember for the next revision. > > See Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity > Protection Framework for End-points", to appear in Security Protocols, > Twelfth International Workshop, Cambridge, 24-28 April, 2004. > Sure. Thanks. >> no change, except add a new field HMAC. >> I am not sure if signing the whole message has >> any advantage over just encrypting the HMAC with private >> key. > > > You forget middle boxes. If you have the signature, there is no > explicit benefit from the HMAC. If the responder knows the initator's > identity, it can verify the signature before constructing the D-H keys. Agreed, but on the other hand, HMAC is more resistant to attacks due to HASH collision. With SHA0 nearly colliding, and MD5 gone, my confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter) is still relatively secure. So much form me! Hope this is useful discussion. Thanks Yogesh --------------enigD8058B04EBF392BC9A9FA298 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUXzIHkjMhOId4nzAQJi0Af9HvVs6V5cdi3NZUdWL9MXeB7Y4C0mBFox BQzwRX3JSnHDXFnnUwUn053juFd5/hXteYAi+Sg58jFaqd+DevD6qcx/wnBFlc+d S9ACTDG0Z58cKu5nO5NXKopCQgnUqnNJdCXLSghP8yYi3jXoKEUYgpFhyj/b9TgJ xd21f+mXEISNgrEyYsHxpcKJSQuPO9a9Q7h3UQ8DRqqFSyLZgJ8MxJHyehh/9QgC d5Axtdbir0wIwZhpnwW4FRjPsnMIxEXb3AnVX6X9V2De7H8g/Qq4loHTYNL8KMH1 KwZOmCFLbEU66eJRHLZDSO0Cqv//fHcbrv2MFr9vQR0WQ+uBNB1OVg== =0B9l -----END PGP SIGNATURE----- --------------enigD8058B04EBF392BC9A9FA298-- From thomas.r.henderson@boeing.com Mon Sep 13 19:42:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 13 18:42:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060832@xch-nw-27.nw.nos.boeing.com> Yogesh, thanks for your discussions, I have a few responses inline: >=20 > > One bigger issue is relationship to middlex boxes, though. HIP > > has been designed to be middle box friendly, explicitly keeping > > fields that middle boxes might inspect, including SPIs, in clear > > text. IKE favours confidentiality and secrecy here, HIP doesn't. > >=20 >=20 > My preferred approach for middle boxes (some prefer evil-boxes) is to > let the protocol break in its presence. Clearly, I'm in a=20 > minority here! :-) There was a recent position paper in Sigcomm conference that argues that middleboxes can be your friend :) >=20 > But I see your point. Although, I won't keep the SPI in clear, I can > still live with it. Without SPI encryption, USER_ID encryption alone > looses a few of its of benefits. One application of HIP that my company is quite interested in is the ability to do access controls on a HIP-enabled data connection, for which the middleboxes need to know the mapping from HITs to SPIs that are generated by the HIP exchange. I have been told many times that large corporations are not going to throw away their middleboxes once IPv6 comes around. >=20 >=20 > >> The draft needs to motivate the need for a new key exchange > >> protocol. > >=20 > >=20 > > Actually, that is the task of the architecture draft. If=20 > it doesn't, > > or does the job poorly, please indicate which parts of the=20 > architecture > > draft you would like to see improved. (-06 is malformated, I'm > > in the process of issuing -07. -05 may be easier to read, if you > > can find it.) >=20 >=20 > Well, I didn't find any discussion in=20 > draft-moskowitz-hip-arch-06.txt on > why someone will choose a "low policy granularity" based key-exchange > (i.e., present HIP) when another one already exists. >=20 > Also, I am not clear why HIP has lower policy granularity.=20 > Isn't policy > based on the USER_ID (e-mail. FQDN etc.) -- which HIP already has? Do > you mean fancy ways of authenticating hosts, by policy granularity? I > must be missing something here. >=20 I have always understood this phrasing to mean that HIP exchange does not offer as many negotiation options for the SA attributes, and does not enable things like setting up multiple SAs between hosts that match on various different header values in the data packets. > Not saying we should not have HIP key exchange. But do add=20 > some text on > why? IESG might as well ask the same question. >=20 I agree with you that the architecture draft does not really talk about why HIP is different from IKE. It seems to be nowhere written down. From thomas.r.henderson@boeing.com Mon Sep 13 19:43:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 13 18:43:01 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base specforward Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> continuing inline below... > -----Original Message----- > From: Yogesh Prem Swami [mailto:yogesh.swami@acm.org]=20 > Sent: Monday, September 13, 2004 12:19 PM > To: ext Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving=20 > the base specforward >=20 >=20 > 2nd e-mail. >=20 >=20 > >=20 > >> * A protocol-type just for a key exchange? > >=20 > >=20 > > Well, architecturally all traffic flows over the new protocol type, > > as there is a new layer between IP and upper layers. Using ESP > > is just a convenient shorthand. >=20 >=20 > I strongly disagree with this. Let's backtrack a little bit=20 > here. In the > past (and present) we have used the socket quadruple to demux=20 > different > connection. The assumption was that the quad will not change after > connection setup. With mobility and multi homing, the IP=20 > address change, > so we need a new mechanism to demux different connections. You are > achieving this through SPIs. (Note also, that the HIT flipping as > defined in the draft is also not essential. Keeping it there might > still be a good idea, if you don't want to change your TCP code, but > it's not needed, in principle. The connection is already=20 > demuxed by the > time of IPsec processing, beyond which you only need to look at port > numbers.) I think that what you say is correct-- that SPI + port is sufficient to demultiplex-- since SPI is a locally unique alias for a HIT. But there still needs to be something to put into the transport = pseudoheader, and the HIT seems cleanest to use, especially in mobile or multihomed world. There has also been some interest expressed in multi6 community of not requiring IPsec for all flows, in which case SPI might not be there-- see section 3.1 of: http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt >=20 > So the first issue is demuxing. That is, how do I demux different > connections, if my IP address keeps changing. >=20 > The second issue is how do I maintain this binding between the demux > numbers (i.e., SPI in this case) and the present IP address=20 > of the host. > This issue is completely separate from the choice of using=20 > an SPI, or a > new IP option or what have you. >=20 > HIP base, to me seems like a protocol for manging this demux=20 > binding. If > you were to propose a new protocol type that will be carried in every > packet (just as SPI) for the purpose of demuxing (and I would have > preferred that over ESP), I wouldn't have complained. But I strongly > disagree that the management of demuxing numbers should be given a > protocol type and should be mixed. >=20 > I would like to listen from other people on what they think. I don't think that I understand fully your objection. If you are arguing that HIP exchange should run over UDP instead of raw IP, there may be value in that in terms of traversing middleboxes-- but I don't think that is the basis of your objection to a new protocol type value. >=20 > >=20 > >> .... But I can see quite a few disadvantages. The biggest > >> disadvantage is that if HIP is implemented in Kernel,=20 > every time > >> there is a need for an upgrade, for example due to bugs, broken > >> (colliding) MACs, broken DH (sub)groups, you will need a kernel > >> upgrade. > >=20 > >=20 > > Actually not. You can easily implement 99% of HIP on user level. >=20 > If you're going to implement in user level, then just use=20 > UDP. Isn't that > the reasons why UDP exists? See above comment-- UDP might be preferable for transporting the handshake. But what is the basis of your objection to using a new protocol number and running it on top of IP? I do not have a strong opinion as to whether HIP exchange should run over IP or UDP-- I have been thinking that it would be useful to define both modes and see which one is more useful in practice. Tom=20 From thomas.r.henderson@boeing.com Mon Sep 13 19:44:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 13 18:44:01 2004 Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the base spec forward Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060834@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Yogesh Prem Swami [mailto:yogesh.swami@acm.org]=20 > Sent: Monday, September 13, 2004 12:20 PM > To: ext Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the=20 > base spec forward >=20 >=20 > 3rd. >=20 >=20 > ext Pekka Nikander wrote: >=20 > >=20 > >> * Optimize for most common case. > >=20 > >=20 > > You can vary the cookie difficulty. There is nothing wrong in > > making K=3D0 by default. >=20 >=20 > Right, but you still loose a Round Trip. It is possible in theory (no one has implemented it yet) to piggyback the TCP SYN and SYN/ACK on the 3rd and 4th packets, respectively. From thomas.r.henderson@boeing.com Mon Sep 13 19:45:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 13 18:45:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Yogesh Prem Swami [mailto:yogesh.swami@acm.org]=20 > Sent: Monday, September 13, 2004 12:21 PM > To: ext Pekka Nikander > Cc: hipsec@honor.trusecure.com > Subject: Last e-mail in this thread -- was -- Re: [Hipsec]=20 > Moving the basespec forward >=20 >=20 > 4th, and last! I promise.=20 >=20 > ext Pekka Nikander wrote: >=20 >=20 > >> Specific comments (assuming people want to keep the key=20 > exchange as is.) > >> > >> * Page-12: I-1 needs to have a type which says what DH=20 > groups Initiator > >> supports. We should not assume that I-1 can/will-want to > >> handle all the DH groups. Additionally, if=20 > Responder cannot > >> select any of the proposed groups, it should=20 > say something. > >=20 > >=20 > > Good point. I think we have discussed this before, but I don't know > > what were the thoughts about this. Anyone? >=20 >=20 > I read Mika's comments and the old discussion, but I still think it's > useful to put HIP-TRANSFORM in I1. It's possible that the=20 > Initiator and > Responder both consider a certain group to be safe, but the default > choice on the two sides could be different. In those cases,=20 > HIP-XFRM in > I1 will help. Also, just because I1 proposes a HIP transform,=20 > Responder > doesn't have to accept it (so there is no chance of attacker degrading > the quality of SA). It might send it's own choice anyways > (falling back to the present scheme, to some extent.) >=20 My recollection was that the lack of I1 preferences and nonces was=20 because R1s are precomputed, and it didn't seem to be offering anything since both sides could still get what they wanted based on advertisement or choice.=20 >=20 > >=20 > >> * Page-12: I think all messages, including I1 should contain a > >> nonce/cookie (similar to R1 counter to match=20 > incoming and > >> outgoing requests) in addition to HITs. For example, > >> If the local policy requires one SA per USER_ID, > >> then the present key exchange will not be able=20 > to meet these > >> requirements. > >=20 > >=20 > > I don't understand this comment. Please elaborate. > >=20 >=20 >=20 > Okay, may be I misunderstood, so let me ask a question. Let's=20 > say I want > to have 3 different SA between same hosts at the same time=20 > (because my > local policy requires on 1 SA per TCP connection and all three TCP > connections start at once.) How does HIP disambiguate between these > three parallel ongoing key exchange. Does it mean SA creating=20 > should be > sequential. I guess this is what you mean by coarse granular key > exchange for HIP, right? Some text in either of the two drafts > (base/arch) will help. >=20 > > (Editorial comments left to Petri, the current editor.) > >=20 > >> I would personally prefer the entire signature > >> out from R1 (i.e., there is no need for=20 > HIP_SIGNATURE_2). > >> Removing SIG_2 in R1 doesn't hurt MITM issues=20 > because R2 > >> is still signed. > >=20 > >=20 > > No, it doesn't protect against MitM. It is there to protect the > > hosts from certain kinds of replay attacks. I think the draft > > says it somewhere, but maybe it doesn't? > >=20 > >=20 > >> Additionally, I would modify I2 to > >> contain HMAC and signature (similar to R2) than just > >> a signature. HMAC on I2 proves a lot more than the > >> signature alone. > >=20 > >=20 > > How come? I don't understand, but maybe I'm blind. Supposedly > > the Responder hasn't got any state when it gets I2. >=20 >=20 > Wow! back up a little bit. When Initiator receives R1, it can compute > the session key. If you want to follow the design choice of=20 > sigma, you > should provide a proof of possession of the ephemeral key by=20 > the HMAC, > not just the signature as it is in the draft right now. >=20 > But then, this makes me ask another question. How does the=20 > Responder get > the public-key of the Initiator. If it's from DNSSec, then it's useful > to use HMAC. If not, then why bother--you are anyway willing to risk > identity mis binding. >=20 > >=20 > >> * Page-15: ""The packets R1, I2, and R2 implement a standard > >> authenticated DH..."". Draft needs a=20 > reference here. I > >> guess you mean ISO based scheme here, right? > >=20 > >=20 > > A reference to Hugo's SIGMA paper? > >=20 > > Hugo Krawczyk: SIGMA: The 'SIGn-and-MAc' Approach to Authenticated > > Diffie-Hellman and Its Use in the IKE-Protocols. CRYPTO=20 > 2003: 400-425 > >=20 >=20 > I disagree that the present key-exchange is based on SIGMA.=20 > That was the > whole point of my question for a reference :-) >=20 >=20 > >> * Page-16: I'm not sure what is the attacker going to gain from > >> replaying R1 and I2. The attacker cannot derive the > >> DH keys by replaying R1/I2. She might be able=20 > to force the > >> Initiator/Responder to solve the puzzle (but=20 > that is a lot > >> less computation than the Signature verification). > >=20 > >=20 > > Not necessarily. With large K, solving the puzzle takes a=20 > lot of CPU. >=20 > This is unnecessary protection, IMO. Also, what is the order of > processing for these messages, i.e., do you fist verify the=20 > signature or > compute the solution. If you verify the signature first -- as you > should -- then aren't you opening up to some kind of DoS? Note that a > counter (R1_COUNTER) doesn't help because a smart blind attacker can > just send a value in the upper quarter of the number space with high > probability of success, so the primitive sequence number check before > signature verification will not help much. If the attacker is blind, then it doesn't know when an initiator has sent the I1, right? The first check in R1 processing is whether initiator is in state I1-SENT or I2-SENT with respect to that responder. If the attacker can snoop the packets, then there is a possibility to generate bogus R1s with slightly higher R1_COUNTERs and force=20 initiator to validate lots of signatures (after the first presumably=20 good one) but a smart initiator might get wise to the failed signatures after a while. >=20 > >=20 > >> IMO, if more than one R1 or I2, they should all be > >> considered valid until a right authentication comes. > >> Following IKEv2 design choices... > >=20 > >=20 > > Good point. Please elaborate so that we understand better,=20 > I haven't > > been following IKEv2. >=20 >=20 > One way to get rid of the signature in R1 is to consider all R1s as a > valid response. Since only a valid Initiator can provide an=20 > R2 (because > of HMAC), its safe to delete the other invalid R1s after the key > exchange is completed. IKEv2 draft does a better job than me in > explaining these things ... so please see that. Wouldn't that lead to a way for MitM to get initiator to disclose encrypted HI? Plus, this would seem to negate the possibility to encrypt and piggyback data on the I2. >=20 > >=20 > >> * Page-16: More text is needed about caching the random=20 > number r of g^r > >> in R1. BTW, how does this protocol behave if the random > >> number r is deleted and g^r arrives after that.=20 > It should > >> send new g^r and the Initiator should be able=20 > to accept it > >> (section 8.7 doesn't seem to say anything=20 > either. I might > >> have missed it.) > >=20 > >=20 > > Suggested text to be added? >=20 >=20 > You might want to check JFK paper (Steve Bellovin, et. al. "Just Fast > Keying) on r caching. >=20 > >=20 > >> * Page-37: HOST_ID should probably be renamed USER_ID.=20 > This field also > >> needs a OPAQUE type for unknown HOST_ID types (e.g., > >> cell-phone numbers etc). > >=20 > >=20 > > Good point, though I'm a little bit reluctant as it slightly adds > > complexity. HIP is a _Host_ Identity Protocol, after all,=20 > even though >=20 > No. That's not what I meant. In the draft you refer to e-mail address, > FQDN, etc as HOST_ID (you need these for polices, right?). This is > confusing and it should be renamed USER_ID, IMO. Also adding an OPAQUE > field there doesn't add complexity--or maybe this time I am=20 > "blind." :-) Do you mean unknown Domain Identifier types? Not sure I follow. Are you saying that HOST_ID might not be a public key? >=20 > > various people (me included) have pondered issues like supporting > > multiple Host Identities within a multi-user host etc. > >=20 > >> * The SPIs needs to be encrypted. It provides limited user traffic > >> confidentiality. > >=20 > >=20 > > Definitely not. Here I (and I guess a number of other people) > > disagree strongly. >=20 >=20 > I can live with a clear SPIN--although it does make traffic > confidentiality little worse. >=20 > >=20 > > HIP has been explicitly designed to be middle box friendly, which > > IKE (including IKEv2) is not. > >=20 >=20 > Well IKEv2 does not have any problems (or it's being fixed)=20 > with middle > boxes to the best of my knowledge. >=20 > >> To summarize, I would prefer the key exchange to look=20 > something like: > >> > >> I->R: IP( HIP( > >> I1-COUNTER /* just a random number */ > >> R1-COUNTER /* =3D 0 */ > >> HIP-TRANSFORM /* with list of DH groups */ > >> )) > >=20 > >=20 > > Responder could select a suitable pre-computed R1 from a pool, > > using the suggested D-H? Adding optional HIP-TRANSFORM here > > might be a good idea. Or even make it mandatory, for simplicity's > > sake? > >=20 > > I don't understand the need for the I1 nonce. To remove the > > need for R1 signature? > >=20 >=20 > But also to allow parallel SA creation. May be you don't want to > consider in the design choice. >=20 > > Didn't we discuss that before? Anyone remembers the conclusions > > or cares to dig up the archives? > >=20 > >> HOST_ID /* ? why is this here in clear ? */ > >> /* Probably better to move it to R2. > >> ID protection from passive=20 > attacker is > >> still a good idea. > >> */ > >=20 > >=20 > > Maybe, but IMHO not now. Something to remember for the=20 > next revision. > >=20 > > See Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity > > Protection Framework for End-points", to appear in=20 > Security Protocols, > > Twelfth International Workshop, Cambridge, 24-28 April, 2004. > >=20 >=20 > Sure. Thanks. >=20 > >> no change, except add a new field HMAC. > >> I am not sure if signing the whole message has > >> any advantage over just encrypting the=20 > HMAC with private > >> key. > >=20 > >=20 > > You forget middle boxes. If you have the signature, there is no > > explicit benefit from the HMAC. If the responder knows the=20 > initator's > > identity, it can verify the signature before constructing=20 > the D-H keys. >=20 >=20 > Agreed, but on the other hand, HMAC is more resistant to=20 > attacks due to > HASH collision. With SHA0 nearly colliding, and MD5 gone, my > confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter) > is still relatively secure. >=20 > So much form me! Hope this is useful discussion. >=20 yes, very. Tom From yogesh.swami@acm.org Tue Sep 14 00:00:02 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Sep 13 23:00:02 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base specforward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> Message-ID: <41466DAA.9010900@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0BB310B09BA5983BCAE4B2A8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, Please see inline: ext Henderson, Thomas R wrote: > continuing inline below... > > >>-----Original Message----- >>From: Yogesh Prem Swami [mailto:yogesh.swami@acm.org] >>Sent: Monday, September 13, 2004 12:19 PM >>To: ext Pekka Nikander >>Cc: hipsec@honor.trusecure.com >>Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving >>the base specforward >> >> >>2nd e-mail. >> >> >> >>>>* A protocol-type just for a key exchange? >>> >>> >>>Well, architecturally all traffic flows over the new protocol type, >>>as there is a new layer between IP and upper layers. Using ESP >>>is just a convenient shorthand. >> >> >>I strongly disagree with this. Let's backtrack a little bit >>here. In the >>past (and present) we have used the socket quadruple to demux >>different >>connection. The assumption was that the quad will not change after >>connection setup. With mobility and multi homing, the IP >>address change, >>so we need a new mechanism to demux different connections. You are >>achieving this through SPIs. (Note also, that the HIT flipping as >>defined in the draft is also not essential. Keeping it there might >>still be a good idea, if you don't want to change your TCP code, but >>it's not needed, in principle. The connection is already >>demuxed by the >>time of IPsec processing, beyond which you only need to look at port >>numbers.) > > > I think that what you say is correct-- that SPI + port is sufficient > to demultiplex-- since SPI is a locally unique alias for a HIT. But > there still needs to be something to put into the transport pseudoheader, > and the HIT seems cleanest to use, especially in mobile or multihomed > world. > > There has also been some interest expressed in multi6 community of > not requiring IPsec for all flows, in which case SPI might not be > there-- see section 3.1 of: > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt > I too would've preferred a new "only SPI; nothing more" extension header, with the possibly of managing SPI to IP address binding/update secure. > > I don't think that I understand fully your objection. If you are > arguing that HIP exchange should run over UDP instead of raw IP, > there may be value in that in terms of traversing middleboxes-- but > I don't think that is the basis of your objection to a new protocol > type value. I guess I was responding to Peeka's comment (at the start of this e-mail) that HIP key exchange is needed at IP layer because all traffic uses this new protocol. In reality, this is not true, because all traffic goes over ESP (which in itself is sufficient to demultiplex connections, HIP or not). So HIP key exchange in reality is a SPI (SA in case of ESP) management protocol. So I was suggestion to move HIP key exchange to UDP (as SHOULD) and probably IP as MAY, if people feel strongly about keeping it at IP. Thanks Yogesh --------------enig0BB310B09BA5983BCAE4B2A8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUZtsXkjMhOId4nzAQITiwf+L7effkAjImSYHVlCbn47xd2h7jDyW1ev +HASjUJ5j4JZGlFkwGY0Avl5fOB/YhmOJKbLKGaTfhC3XBsqApgZDctRM6U/mp++ hcM8k5ZUhhFxL6Ui+eEbZTJ9tdTWjk7R0HEH6mrCSJF2gqhsNaxJw3I1g+bMkqtj NxIAOU2NhBa2nH0LX/gFl7qKw5TaKNmZ0rkHpyrvKYBrmXYrooXz3ZSrnwR3U3T0 ou0m39GzBEr/YO4QwOzBgy3LqMAq4aHPXmdLdVIBKjrETfr8o5QIJkReBrkVWWcb 2t5nMhd3RsZLVVhFvEfr5QXZOQ+5LbHT/4E30Iv1tYr9C5lhBb59aw== =uMVh -----END PGP SIGNATURE----- --------------enig0BB310B09BA5983BCAE4B2A8-- From yogesh.swami@acm.org Tue Sep 14 02:18:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Tue Sep 14 01:18:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> Message-ID: <4146786F.7070400@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F77523C0157D687D301B1A5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Continuing... ext Henderson, Thomas R wrote: > My recollection was that the lack of I1 preferences and nonces was > because R1s are precomputed, and it didn't seem to be offering > anything since both sides could still get what they wanted based > on advertisement or choice. > In some cases it's possible that the responder will have a cache of multiple g^r corresponding to different group and one preferred group out of those. In the present scheme, the responder will choose the preferred group, and send it in R1. But if the Initiator does not support this group, then the connection will fail, right? (I might have missed something.) It's still however possible that Initiator and responder do have a common group. By putting HIP-XFRM in I1, it will help in these cases. >> >>This is unnecessary protection, IMO. Also, what is the order of >>processing for these messages, i.e., do you fist verify the >>signature or >>compute the solution. If you verify the signature first -- as you >>should -- then aren't you opening up to some kind of DoS? Note that a >>counter (R1_COUNTER) doesn't help because a smart blind attacker can >>just send a value in the upper quarter of the number space with high >>probability of success, so the primitive sequence number check before >>signature verification will not help much. > > > If the attacker is blind, then it doesn't know when an initiator > has sent the I1, right? The first check in R1 processing is whether > initiator is in state I1-SENT or I2-SENT with respect to that responder. > > If the attacker can snoop the packets, then there is a possibility > to generate bogus R1s with slightly higher R1_COUNTERs and force > initiator to validate lots of signatures (after the first presumably > good one) but a smart initiator might get wise to the failed signatures > after a while. > I don't have very strong opinion about removing SIGNATURE_2. To me SIG_2 doesn't seem to provide much gain compared to computation involved. Consider how much computation is needed before the Initiator sends I2: it needs to calculate a) the signature-verification of SIG_2 ( = 1 MAC, one public-key encryption), b) the puzzle solution, c) g^y generation, d) (g^x)^y (to get the key, if we want to follow SIGMA), e) and one more SIGNATURE (for I2). That's 4 exponent computation (and a lot of HASH computation if the puzzle is tough) before sending I2. Removing SIG_2 will reduce it to 3 exponent calculation (not a bit feat, but useful on some low computation power environments, nonetheless.) >>No. That's not what I meant. In the draft you refer to e-mail address, >>FQDN, etc as HOST_ID (you need these for polices, right?). This is >>confusing and it should be renamed USER_ID, IMO. Also adding an OPAQUE >>field there doesn't add complexity--or maybe this time I am >>"blind." :-) > > > Do you mean unknown Domain Identifier types? Not sure I follow. > Are you saying that HOST_ID might not be a public key? I misunderstood this part (eh! the PKI tunnel vision. :-)). I was thinking that in addition to HIs, there might be a need for another field such as e-mail address or FQDN for policy purposes. For example, even though every host inside a corporation might be able able to have a security association with any other host, not every user will get the same level of access to resources. In those cases, these USER IDs might be useful. I guess HIP doesn't support this yet, right? (or, perhaps requires every user to have their own HIs, which could be hard operationally). Thanks Yogesh --------------enig0F77523C0157D687D301B1A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUZ4dXkjMhOId4nzAQLh/AgAjXEy9rzfdh8pg3VOEb8RJ+caNrqnEY/O 5LTHRrn5R45ql01QibPn7SFxH57LnUciMALVAQA4JO1QTDwQ0P1g/eNI0AvKy7hp LY0PeXg61XnTLlGfQiMBEND68sP6OwQyvsqL/EUVS32RhVyNZDCtg/udW8gi7GVi 0EXDfszZaGBB+tUh+DCzRNBtf5ZKz9YWkbHpBKtEiCrtjoe9vkj0WBwk7aqGMfAU dAMCvbTQsgnRNBpCVEk4vQkmTKzvVI2qTAEn6+lkbNTSWGb0ETK/pDD5TEnvqxNt v/2D2RfIyBolngEzB++wMc4rEf1J+GQ+KmsN+A+YE25MFeFYOKnYKQ== =2xnl -----END PGP SIGNATURE----- --------------enig0F77523C0157D687D301B1A5-- From miika@iki.fi Tue Sep 14 04:29:00 2004 From: miika@iki.fi (Miika Komu) Date: Tue Sep 14 03:29:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> Message-ID: On Mon, 13 Sep 2004, Henderson, Thomas R wrote: > > Agreed, but on the other hand, HMAC is more resistant to > > attacks due to > > HASH collision. With SHA0 nearly colliding, and MD5 gone, my > > confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter) > > is still relatively secure. Just to separate rumours from facts, see: http://www.sandelman.ottawa.on.ca/ipsec/1996/05/msg00021.html Q: Is SHA-1 broken? A: No. Eli Biham described attacks that work against simplified versions of SHA-1, but there is no suggestion that any known attack technique can be extended to break the full SHA-1. (The attacks presented against SHA-0 are also effective against a 36-round reduced variant of SHA-1, but the standard version of SHA-1 uses a full 80 rounds and has not been compromised.) Although there has been speculation that SHA-1 will fall soon, extending the current results to the full SHA-1 appears to be an extremely difficult problem and we do not anticipate such an attack in the immediate future. Nevertheless, the new results certainly do merit a full re-evaluation of all hash functions. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkousa@cc.hut.fi Tue Sep 14 05:09:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Sep 14 04:09:01 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: <200409101016.16924.Jan.Melen@nomadiclab.com> References: <200409090948.18423.Jan.Melen@nomadiclab.com> <200409101016.16924.Jan.Melen@nomadiclab.com> Message-ID: On Fri, 10 Sep 2004, Jan Mikael Melen wrote: -> -----BEGIN PGP SIGNED MESSAGE----- -> Hash: SHA1 -> -> On Thursday 09 September 2004 15:18, Mika Kousa wrote: -> > -> > After the base exchange: -> > -> > --SPI_AtoB_1--> -> > A B -> > <--SPI_BtoA_1-- -> > -> > -> > A adds a new interface which has SPI=SPI_BtoA_2. According to section "5.2 -> > Host multihoming": -> > -> > A sends UPDATE(NES(Old SPI=SPI_BtoA_2, New SPI=SPI_BtoA_2), SEQ) -> > B sends UPDATE(NES(Old SPI=SPI_AtoB_1, New SPI=SPI_AtoB1'), SEQ, ACK) -> > A sends UPDATE(ACK) -> > -> > (SPI_AtoB1' indicates that it replaces the old SPI SPI_AtoB1.) -> > -> > Now A and B are back in established state, and B sees that it can select -> > from two possible SPIs of A: -> > -> > --SPI_AtoB_1'--> -> > A B -> > <--SPI_BtoA_1-- -> > <--SPI_BtoA_2-- -> > -> > See, no two pairs of SAs. I have understood that a host can have 1..n -> > active SAs at the same time, so SAs need not to be "paired" somehow. Or -> > they even can not be paired: how to pair SAs if A has 3 SAs and B has 4 -> > SAs ? -> -> Yes, I'll see but how are you planning to use those SAs. For example if -> interfaces on A have different link speeds? I really haven't even thought that far. The only thing I just wanted to know is that what to put in the Old SPI field of the NES parameter when there are multiple choices. I would like to see some guidance about this issue in the specification, because I can't even test alternative implementations if I can't figure out what data I should put into the packets. -> You will never be able to use the full link capacity from either interface as -> returning packets are always going through one interface. (You have one pair -> and a half) As above... -> OR are you planning to use the AtoB SA on two different interfaces then I'll -> have to ask how are planning to protect yourself from replay protection -> window over run? What I'm trying is to implement is the one-SA-per-network interface, as recommended in the draft (section 4.1). Not to use some kind of a shared SA for all interfaces. From pekka.nikander@nomadiclab.com Tue Sep 14 06:51:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 05:51:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4145F262.8090805@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> Message-ID: Tom already answered to a number of points (and I am trying to avoid repeating him), but perhaps I can say something more. > IMO, it's important to consider IKEv2 for a variety of reasons. The > biggest reason is that it will improve the usability of HIP. It's a lot > harder, practically speaking, to convince people to buy/build a new > product such as HIP when their older products (IKEv2) can already > achieve something similar. I think we should learn the right lessons > from IPv6 deployment. I agree with you that it is important to consider IKEv2, or IKEv3, in the longer run. However, right now IMHO the goals of IKEv2 and the goals of HIP are sufficiently different to warrant a separate KMP. On the other hand, as you indicate below, it seems that we've missed some crucial elements of IKEv2, and should copy them. More importantly, the atmosphere in the ipsec WG has always been such that it would have been utterly impossible to develop something like HIP there. A large number of ipsec WG members are what I call "managed security" folks. In their mind, security always means administrators and very secure systems. A large number of people at the HIP wg are what I call "opportunistic security" folks. In our mind, there is _also_ value to improve security in a situation where you cannot afford separate security managers and where your security goal may not be that high. HIP aims to both managed and opportunistic security, with more focus currently on the opportunistic side. Our current goal is to make IKEv2 and HIP to happily coexist on a single host. We are not there yet, but almost. Once we know what kind of extensions you need to PF_KEY, I will most probably write a revision of PF_KEY. > The basic IKEv2 is no more complex than HIP exchange, IMO. When I speak about complexity, I mostly mean the number of lines needed to implement. With this measure, IKEv2 is considerably more complex than HIP. Among other things, the policy negotiation in HIP is virtually non-existent. > In addition, the security properties of IKEv2 is well understood. > Hugo's > paper has a provably secure analysis of SIGMA, on which IKE is based. > This is not the case with HIP key exchange. The aim in HIP has been to base it on SIGMA. Apparently we have missed it, as none of us (except perhaps Bob) are real crypto protocol experts. We need to fix this. I would be very glad if you would outline the necessary _minimal_ changes that are needed to make HIP to be based on SIGMA. > Well, I didn't find any discussion in draft-moskowitz-hip-arch-06.txt > on > why someone will choose a "low policy granularity" based key-exchange > (i.e., present HIP) when another one already exists. Ok, I will add a section on this. > Also, I am not clear why HIP has lower policy granularity. Isn't policy > based on the USER_ID (e-mail. FQDN etc.) -- which HIP already has? I don't remember why and when we added NAI support. Before that only FQDN was supported. I guess it was added to ease integration with legacy AAA systems. The aim has been and still is that you use a single logical pair of SAs between two hosts, and you route all traffic between the hosts over those SAs. No selectors used. Maybe this isn't clear from the draft. If so, please suggest added/modified wording. There are hooks here and there for adding multi-user support so that you could use a different pair of SAs for each user, but that has not been defined. > You mention complexity a couple of times in your e-mail. To me it seems > like the biggest complexity is reinventing a new key exchange. :-) Apparently we have missed some finer details of IKEv2. It is time now to fix this. There is no real need to re-invent the security properties of IKEv2. We just want to a) embed DoS protection which is always usable (not optimised away) b) make the protocol middle box friendly c) support no selector based policy I think that we could then later on define a mode of operation where the mandatory DoS protection can be optionally skipped, and where people that want to have more selector policy control can add it. But such things should be add-ons, not intrinsic parts of the base protocol. > Not saying we should not have HIP key exchange. But do add some text on > why? IESG might as well ask the same question. Point taken, and will be better addressed in arch-07. --Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 06:58:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 05:58:01 2004 Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4145F2C6.8000505@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F2C6.8000505@acm.org> Message-ID: >> Currently, the main goal is to keep the protocol as simple as >> possible, not to optimise it for any specific use case. > > Well, considering a DoS attack is an optimization, isn't it? No, it is a fundamental property of the base design. DoS protection is taken into a new level in Hi3, and wouldn't be possible without this base DoS protection. > You removed the text below message 2 and changed the meaning > completely. Sorry about that. > I was suggesting that if the responder *perceives* an > attack, only then it should trigger the cookie/puzzle mechanism. If > not, there is no need to waste a round trip. Here is the text from my > previous message. There is no extra round trip in the typical case. See my separate message, next. > But I understand that you design goal is to let the responder select > the right group etc., and that might interfere with what I am > proposing. > Which choice is better is debatable, though. Sure it is debatable. OTOH, an attacker can choose when to play Initiator. If it wants to play Responder, it has to wait. That's the rationale behind our choice. --Pekka From jari.arkko@piuha.net Tue Sep 14 06:59:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Sep 14 05:59:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> Message-ID: <4146CFF7.4090900@piuha.net> FWIW, I agree with Pekka that the goals of HIP and IKEv2 are sufficiently different that they deserve their own protocols. --Jari From pekka.nikander@nomadiclab.com Tue Sep 14 07:00:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:00:00 2004 Subject: Cookie mechanism -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060834@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060834@xch-nw-27.nw.nos.boeing.com> Message-ID: >>> You can vary the cookie difficulty. There is nothing wrong in >>> making K=0 by default. >> >> Right, but you still loose a Round Trip. > > It is possible in theory (no one has implemented it yet) to > piggyback the TCP SYN and SYN/ACK on the 3rd and 4th packets, > respectively. Actually, if your implementation can defer tcb creation, you can carry TCP SYN and SYN/ACK in the first and second packets, respectively. The third will then already contain data traffic. Hence, in the TCP/SCTP case the situation can be arranged so that you don't loose any round trips. For UDP, you have to wait 1 RTT. You can piggyback data on I2. Implementation with the current PF_KEY is pretty tricky, though. --Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 07:07:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:07:01 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base specforward In-Reply-To: <41466DAA.9010900@acm.org> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> <41466DAA.9010900@acm.org> Message-ID: > I guess I was responding to Pekka's comment (at the start of this > e-mail) that HIP key exchange is needed at IP layer because all > traffic uses this new protocol. I didn't say it is *needed*. I said that it is *architecturally* cleaner as it is arranged today. There are many practical reasons, including NATs, why it would be more desirable to use UDP for HIP. That has been suggested multiple times, and I have strongly resisted it for the sake of architectural purity. If people want to define HIP-over-UDP for NAT traversal etc, I don't have anything against that per se, even though I'm afraid that it might prove to be more popular than "pure" HIP. However, I definitely don't want that to be the default case, mostly because of this architectural purity stance, but also as that would necessitate us to carry yet another unnecessary header in the packets. > In reality, this is not true, because all traffic goes over ESP (which > in itself is sufficient to demultiplex connections, HIP or not). So > HIP key exchange in reality is a SPI (SA in case of ESP) management > protocol. Almost, but not quite. > So I was suggestion to move HIP key exchange to UDP (as SHOULD) and > probably IP as MAY, if people feel strongly about keeping it at IP. I am willing to consider UDP as OPTIONAL. I cannot be easily convinced to move the current arrangement into anything less than SHOULD. Architecturally, there is too much at stake. The IETF has a bad history of sacrificing long term architectural view to short term practical considerations. --Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 07:13:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:13:00 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base specforward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060833@xch-nw-27.nw.nos.boeing.com> Message-ID: > I think that what you say is correct-- that SPI + port is sufficient > to demultiplex-- since SPI is a locally unique alias for a HIT. But ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is important. Architecturally, the SPI is an _alias_ for a HIT pair. >> If you were to propose a new protocol type that will be carried >> in every packet (just as SPI) for the purpose of demuxing (and I >> would have referred that over ESP), I wouldn't have complained. There has been some talk of replacing ESP with something else for HIP use. Maybe the time starts to be mature for this? Define a simplified (0-bit) format for the current HIP payload, cleary distinguishable from the default HIP header? And then reuse the same protocol number? For example, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controls | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (64 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notice the "1" in the end of the first word. This would firstly have a 64 bit SPI, making collision management in middle boxes easier. Secondly, it would have the standard IPv6 extension header, creating less ugly code in kernels. Of course, it would not be as secure as ESP, as it would always show what is the type of the next header (if any), but IMHO that doesn't matter. -_Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 07:26:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:26:00 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4145F2A3.5030204@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F2A3.5030204@acm.org> Message-ID: > I strongly disagree with this. Let's backtrack a little bit here. In > the > past (and present) we have used the socket quadruple to demux different > connection. The assumption was that the quad will not change after > connection setup. With mobility and multi homing, the IP address > change, > so we need a new mechanism to demux different connections. You are > achieving this through SPIs. No, we are not achieving this through SPIs. We are achieving this through using the HITs in the socket and the pseudo-header, as Tom already wrote. There rest, like using SPIs as a shorthand, is details, and not important from the highest architectural-level point of view. The rest of your argument doesn't hold, as it looks at the situation from a very different point of view. While your viewpoint is true for many of the current implementations, it misses the architectural change. > Also, if you want to support multicast using HIP, you will need yet > another key exchange--substantially different from HIP key exchange. > Are you proposing to use another protocol-type for multicast key > exchange. Of course not. There are more than enough space for extensions in the current HIP protocol. > And yes, you can multiplex all of them on the same protocol > type, but then it will be my turn to cry the complexity wolf. I still hold the opinion that architectural complexity is well measured by the number of LOC needed to implement it. (With some caveat emptors, of course, like not accepting ugly code.) As you add more features, you need more code. If your new protocols can benefit from existing infrastructure, in a clean way, then you can save in terms of LOC. In other words, I don't buy you argument that implementing different kinds of control protocols within a layer 3.5 control protocol is necessarily bad design and leads to complexity. Using TCP or UDP demuxing may lead to architecturally worse complexity, like necessitating built-in port based policy rules. > To me, architecturally it seems cleaner to keep the SA management > (i.e., > 3.5 layer management) separate from the 3.5 layer itself. HIP key > exchange is a 3.5 layer manager, and there is no need to mix it with > the > 3.5 demuxing layer itself--which you achieve through SPI. This is a fundamental difference in opinions. Some people hold the opinion that it is better to have separate control protocols and separate data traffic protocols, like in the telephone networks. Some people think that it is better to have in-band signalling, like in TCP. I guess my opinion is somewhere in the middle ground. Especially, I think that Layer N signalling should not depend on Layer N+K protocols for any K>0. Consequently, Layer N signalling is always either in-band at layer N, or directly at Layer N+1. (You can read the comment above that IKE, with is use of UDP, is badly designed.) Another issue here is, again, middle boxes. Having the control protocol on a separate protocol number makes it easier to separate data traffic and control traffic on a middle box. No need to look inside ESP, TCP or UDP, and therefore simpler fast path. >>> IKE is implemented on UDP for a good reason. Out of curiosity, what are those good reasons? > http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-06.txt? > Isn't this draft in RFC queue right now? -05 was, but was pulled back for a number of reasons. The current plan is to resubmit -07. --Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 07:38:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:38:01 2004 Subject: [Hipsec] HIP transforms in I1 (was .Re: Last e-mail in ...) In-Reply-To: <4146786F.7070400@acm.org> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> <4146786F.7070400@acm.org> Message-ID: <47A91DD8-0643-11D9-82B1-000D9331AFB0@nomadiclab.com> > In some cases it's possible that the responder will have a cache of > multiple g^r corresponding to different group and one preferred group > out of those. In the present scheme, the responder will choose the > preferred group, and send it in R1. But if the Initiator does not > support this group, then the connection will fail, right? (I might > have missed something.) It's still however possible that Initiator and > responder do have a common group. By putting HIP-XFRM in I1, it will > help in these cases. I think this is a valid comment, and that we should either a) add HIP transforms as a mandatory parameter to I1, or b) write a separate extension draft that defines an optional HIP transforms parameter that MAY be included to I1 I am in favour of b), but can live with a). Others? --Pekka From pekka.nikander@nomadiclab.com Tue Sep 14 07:40:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Sep 14 06:40:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward In-Reply-To: <4146786F.7070400@acm.org> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> <4146786F.7070400@acm.org> Message-ID: <927F33F7-0643-11D9-82B1-000D9331AFB0@nomadiclab.com> > I don't have very strong opinion about removing SIGNATURE_2. To me > SIG_2 doesn't seem to provide much gain compared to computation > involved. The Initiator does not need to verify SIG_2 unless is suspects that it may be false. It looks like we can close this piece of this discussion. > ... I was thinking that in addition to HIs, there might be a need for > another field such as e-mail address or FQDN for policy purposes. For > example, even though every host inside a corporation might be able > able to have a security association with any other host, not every > user will get the same level of access to resources. In those cases, > these USER IDs might be useful. > > I guess HIP doesn't support this yet, right? Right. The idea is that to support multiple users with different security levels, you need to represent each user with a different HIT. Architecturally that is easy, but not easy to implement. --Pekka From yogesh.swami@acm.org Tue Sep 14 12:50:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Tue Sep 14 11:50:00 2004 Subject: Last e-mail in this thread -- was -- Re: [Hipsec] Moving the basespec forward In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> Message-ID: <4147221E.6010100@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCF5BD28DAA567CF86A5212DA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Miika, Thanks for pointing this out. I realized I was not careful in my wording, and didn't mean to give the impression that SHA1 is any less secure than what it was before crypto '04. I will respond to other mails from Pekka somewhat later on. Thanks Yogesh ext Miika Komu wrote: > On Mon, 13 Sep 2004, Henderson, Thomas R wrote: > > >>>Agreed, but on the other hand, HMAC is more resistant to >>>attacks due to >>>HASH collision. With SHA0 nearly colliding, and MD5 gone, my >>>confidence in SHA1 is very low. But HMAC-SHA (or MD5 for that matter) >>>is still relatively secure. > > > Just to separate rumours from facts, see: > > http://www.sandelman.ottawa.on.ca/ipsec/1996/05/msg00021.html > > Q: Is SHA-1 broken? > A: No. Eli Biham described attacks that work against simplified versions > of SHA-1, but there is no suggestion that any known attack technique can > be extended to break the full SHA-1. (The attacks presented against SHA-0 > are also effective against a 36-round reduced variant of SHA-1, but the > standard version of SHA-1 uses a full 80 rounds and has not been > compromised.) Although there has been speculation that SHA-1 will fall > soon, extending the current results to the full SHA-1 appears to be an > extremely difficult problem and we do not anticipate such an attack in the > immediate future. Nevertheless, the new results certainly do merit a full > re-evaluation of all hash functions. > --------------enigCF5BD28DAA567CF86A5212DA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUciMHkjMhOId4nzAQJpPAf/fqaqgmH/cAj452DmWuDE8WmK/jnoqFtg RSBJpVinX9eOK8tv6I4nqjvR6ZK2qhlwO2XSa/YPSiz/So7Z8d4AvdrMOG9UTG0D +RAZ1DwGfYbCRCuCutqx4lIkLVn0JtdIKLPWqIe5Hb6YJGv2mHKrI2HBDWVZDWYF DO9wrwzQgsNuH+jhjmlnGow7cYDywCNyfVKWBObFoxZCMaZq1urCOszySw+AjLl5 LppLjjgxitlrxjGFLO6czPQRKZg7pPpjlTWsnIhNBJXXohNvJxWXl0d3psw36vOC NMncMqMq/iNdHUigME8sL5DgnXTYMidPzmVTlR4HhkDttkpNMmsbgQ== =IisU -----END PGP SIGNATURE----- --------------enigCF5BD28DAA567CF86A5212DA-- From gurtov@cs.helsinki.fi Tue Sep 14 12:50:05 2004 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Tue Sep 14 11:50:05 2004 Subject: [Hipsec] HIP checksumming and FROM option Message-ID: <41472266.4080706@cs.helsinki.fi> Hi, While trying to implement indirection support for HIP, I had some challengies related to changing IP addresses in the I1 packet. With current specs it requires adding a FROM option containing the source IP address and recomputing the HIP checksum (that covers the pseudoheader including IP addresses). Some people have argued that such checksumming was a bad design choice in UDP, since it violates a clean layering concept and e.g. prevents running UDP over anything but IP. Is there any strong reason for including pseudoheader in the HIP checksum? Without it, it would be easier to change IP addresses in the network, facilitating traversal of NATs and middleboxes. There is a checksum in the IP header anyway. Furthemore, how about making the FROM option mandatory in handshake packets? It would make middlebox programming easier. Andrei From capacity77@tin.it Tue Sep 14 13:01:02 2004 From: capacity77@tin.it (capacity77@tin.it) Date: Tue Sep 14 12:01:02 2004 Subject: [Hipsec] IPv4 and IPv6 Message-ID: <4146496B00000FE6@ims6a.cp.tin.it> Dear All, is it true that HIP for Linux works only over IPv6? doesn't it work on IPv4? And what about HIP for BSD? Does it work over IPv4? Thanks capacity From Jan.Melen@nomadiclab.com Tue Sep 14 13:13:01 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Tue Sep 14 12:13:01 2004 Subject: [Hipsec] IPv4 and IPv6 In-Reply-To: <4146496B00000FE6@ims6a.cp.tin.it> References: <4146496B00000FE6@ims6a.cp.tin.it> Message-ID: <200409142017.37522.Jan.Melen@nomadiclab.com> > And what about HIP for BSD? Does it work over IPv4? HIP for BSD is supporting both IPv4 and IPv6. Regards, Jan From rgm@htt-consult.com Tue Sep 14 13:14:01 2004 From: rgm@htt-consult.com (Robert Moskowitz) Date: Tue Sep 14 12:14:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060832@xch-nw-27.nw.nos. boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060832@xch-nw-27.nw.nos.boeing.com> Message-ID: <6.1.2.0.2.20040914131151.05250c48@localhost> At 07:47 PM 9/13/2004, Henderson, Thomas R wrote: > > Not saying we should not have HIP key exchange. But do add > > some text on why? IESG might as well ask the same question. > > > >I agree with you that the architecture draft does not really talk >about why HIP is different from IKE. It seems to be nowhere written >down. Becuase I was told to take it all out. For those of you that do not have a history of HIP, I started it right after the Orlando IETF (dec 1998), only months after the IPsec specs were out. In my not so humble opinion, the concepts in HIP have been borrowed by other efforts, and someone not knowing who's on first and what's on second, things can get confusing. And the reason I was told to take any references out was very sensible: Let HIP stand on its own merits, and not be faced with a competition with IKE (HIP concepts were done before IKEv2 started). The parties that instructed me on this shall remain nameless, but they included many of the IETF heavies. If someone wants to compare HIP and IKE, they are welcomed to write an Internet Draft. From miika@iki.fi Tue Sep 14 13:18:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Sep 14 12:18:01 2004 Subject: [Hipsec] IPv4 and IPv6 In-Reply-To: <4146496B00000FE6@ims6a.cp.tin.it> References: <4146496B00000FE6@ims6a.cp.tin.it> Message-ID: On Tue, 14 Sep 2004 capacity77@tin.it wrote: > is it true that HIP for Linux works only over IPv6? > doesn't it work on IPv4? The IPv4 support will be implemented during this fall (by me). We have HIPL specific mailing lists. See http://hipl.hiit.fi/hipl/ for the details. Please use them to ask questions about the HIPL implementation. > And what about HIP for BSD? Does it work over IPv4? Yes. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From miika@iki.fi Tue Sep 14 16:32:00 2004 From: miika@iki.fi (Miika Komu) Date: Tue Sep 14 15:32:00 2004 Subject: [Hipsec] HIP transforms in I1 (was .Re: Last e-mail in ...) In-Reply-To: <47A91DD8-0643-11D9-82B1-000D9331AFB0@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060835@xch-nw-27.nw.nos.boeing.com> <4146786F.7070400@acm.org> <47A91DD8-0643-11D9-82B1-000D9331AFB0@nomadiclab.com> Message-ID: On Tue, 14 Sep 2004, Pekka Nikander wrote: > > In some cases it's possible that the responder will have a cache of > > multiple g^r corresponding to different group and one preferred group > > out of those. In the present scheme, the responder will choose the > > preferred group, and send it in R1. But if the Initiator does not > > support this group, then the connection will fail, right? (I might > > have missed something.) It's still however possible that Initiator and > > responder do have a common group. By putting HIP-XFRM in I1, it will > > help in these cases. > > I think this is a valid comment, and that we should either > > a) add HIP transforms as a mandatory parameter to I1, or > > b) write a separate extension draft that defines an optional > HIP transforms parameter that MAY be included to I1 > > I am in favour of b), but can live with a). Others? I have another alternative in my mind that tries to avoid the introduction of new parameters in I1. It offers only a partial solution to the problem as it mostly concerns devices with limited CPU resources. The idea is that we could have a new "G" flag which the initiator sets if it requests the lowest possible DH group. I had a small off-line conversation with Jeff on a fourth alternative that does not work, but perhaps is worth mentioning. The idea is to move the DH parameter from R1 to R2, and to put a DH_GROUP_TRANSFORM parameter into R1. This does not work for two reasons. First, the initiator needs to have the responder's DH in R1 to be able to encrypt it's HI in I2. Second, the initiator needs to validate the HMAC in R2, but it is not possible because the DH is inside the invalidated R2. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From yogesh.swami@acm.org Tue Sep 14 17:21:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Tue Sep 14 16:21:00 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F2A3.5030204@acm.org> Message-ID: <4147619C.8050602@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D41745D0AF8BB7C0E0A6CF4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pekka- Please see inline: ext Pekka Nikander wrote: >> I strongly disagree with this. Let's backtrack a little bit here. In the >> past (and present) we have used the socket quadruple to demux different >> connection. The assumption was that the quad will not change after >> connection setup. With mobility and multi homing, the IP address change, >> so we need a new mechanism to demux different connections. You are >> achieving this through SPIs. > > > No, we are not achieving this through SPIs. We are achieving this > through using the HITs in the socket and the pseudo-header, as > Tom already wrote. > > There rest, like using SPIs as a shorthand, is details, and not > important from the highest architectural-level point of view. I understand this point. And I totally agree with you that keeping the SPI (or even HIT, if someone so wanted) in every packet is the right architecture. What I don't agree with is that the protocol that does the binding between the current IP address and a corresponding HIT should also be an IP protocol type. I guess the difference in opinion is because in my mind, multiplexing connections and managing bindings are separate issues (and it might just be my tunnel vision). To me the present HIP key-exchange is a connection oriented protocol, unlike the traditional connectionless model of IP. So I am a little reluctant to mix the key-exchange (ip-to-hit-binding-management) with the actual packet processing (which I want to keep connection less). Note that the way ESP is designed, is connection less (even though aalmost all key exchanges, even for Multicast, will be connection oriented running as applications on some transport protocol). I would like to keep the connection-less model of IP as it is, even after introducing the layer 3.5, and to me this means separating the binding management from the actual packet processing. Please note that this situation is very different from TCP, which is always connection oriented. All that blah blah said, I think it's okay to gain experience using the present draft (i.e., IP as MUST as you want, and UDP as SHOUD/MAY/OPTIONAL--pick one). We can always come back during STD track discussion. > > The rest of your argument doesn't hold, as it looks at the situation > from a very different point of view. While your viewpoint is true > for many of the current implementations, it misses the architectural > change. > I guess the implementation viewpoint is just the reflection of present architecture. I like the present architecture, but I also like the ideas of HIP. And I want both. :-) >> Also, if you want to support multicast using HIP, you will need yet >> another key exchange--substantially different from HIP key exchange. >> Are you proposing to use another protocol-type for multicast key >> exchange. > > > Of course not. There are more than enough space for extensions > in the current HIP protocol. > >> And yes, you can multiplex all of them on the same protocol >> type, but then it will be my turn to cry the complexity wolf. > > > I still hold the opinion that architectural complexity is well > measured by the number of LOC needed to implement it. (With > some caveat emptors, of course, like not accepting ugly code.) > > As you add more features, you need more code. > > If your new protocols can benefit from existing infrastructure, > in a clean way, then you can save in terms of LOC. In other > words, I don't buy you argument that implementing different > kinds of control protocols within a layer 3.5 control protocol > is necessarily bad design and leads to complexity. Using > TCP or UDP demuxing may lead to architecturally worse complexity, > like necessitating built-in port based policy rules. > >> To me, architecturally it seems cleaner to keep the SA management (i.e., >> 3.5 layer management) separate from the 3.5 layer itself. HIP key >> exchange is a 3.5 layer manager, and there is no need to mix it with the >> 3.5 demuxing layer itself--which you achieve through SPI. > > > This is a fundamental difference in opinions. Some people hold the > opinion that it is better to have separate control protocols and > separate data traffic protocols, like in the telephone networks. > Some people think that it is better to have in-band signalling, > like in TCP. I guess my opinion is somewhere in the middle ground. > Especially, I think that Layer N signalling should not depend on Layer > N+K protocols for any K>0. Consequently, Layer N signalling is > always either in-band at layer N, or directly at Layer N+1. > Please see above. > (You can read the comment above that IKE, with is use of UDP, > is badly designed.) > > Another issue here is, again, middle boxes. Having the control > protocol on a separate protocol number makes it easier to separate > data traffic and control traffic on a middle box. No need to > look inside ESP, TCP or UDP, and therefore simpler fast path. > >>>> IKE is implemented on UDP for a good reason. > > > Out of curiosity, what are those good reasons? > I guess I pointed that in first paragraph. The IPsec documents and IETF in general (if I can muster enough courage to say so :-) ) doesn't keep track of the design decisions. So I am just extrapolating what I understand ... Another point that Steve Deering made during the IETF plenary session of August 2001 ( http://www.ietf.org/proceedings/01aug/slides/plenary-1/sld001.htm) was to look at Internet Protocols as an hourglass whose waistline is IP. There is advantage in keeping that waistline thin (and straight), IMO. My rule of thumb: if its not related to routing, don't put it near IP (take it of leave it; I'm not going to argue either way on this. :-) ). Yogesh --------------enig4D41745D0AF8BB7C0E0A6CF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUdhoHkjMhOId4nzAQLpWQgAhZP9Z1/vkksbIwsYqyCvj8LdRs+VTZ1J VehpVlj5VlxQcDcNUVMcMQXjQ2hDVXQGcWpoUkjQWp8nTWTOw/GL7v3jRa9k92fa Z9co2gz93D6GSsotA5xLidEEsJjM2V9B5UYijTHU43I3oeoDgcXvD8QVizhznADr i3KOeGTDbyVyBrA0kbM1XefSDfA5dHVK+WBtQSbn1tgWg1zSgzdxSOxT6oBBPcXN 2tPT84WHPpNli4Q21D5y4k02iGVM1qB1af0c6g/ngjbBwaYrc6pSoFtQHo3aFYGz EYsQ//nbvjdp8KJ7qGU/m43yUvWd+suFPpa0NtO6euqN30BLEVechg== =4OmA -----END PGP SIGNATURE----- --------------enig4D41745D0AF8BB7C0E0A6CF4-- From jeffrey.m.ahrenholz@boeing.com Tue Sep 14 17:53:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Tue Sep 14 16:53:01 2004 Subject: [Hipsec] HIP transforms in I1 (was .Re: Last e-mail in ...) Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361ED1@xch-nw-09.nw.nos.boeing.com> I would also be in favor of (b), or add a new flag as Miika suggests. Note a couple of things: -a compliant implementation will always support group IDs 1 and 3 -with the existing draft, using the NOTIFY parameter with an error type of NO_DH_PROPOSAL_CHOSEN, the Initiator could abort the exchange and signal the Responder that it wants a different DH group. (but the Responder might need some state then to remember to send a new group next time) -also, you could always start an exchange with a mandatory group ID and later use the UPDATE mechanism to switch to a new "preferred" group ID. -Jeff > I think this is a valid comment, and that we should either >=20 > a) add HIP transforms as a mandatory parameter to I1, or >=20 > b) write a separate extension draft that defines an optional > HIP transforms parameter that MAY be included to I1 >=20 > I am in favour of b), but can live with a). Others? >=20 > --Pekka From mcr@sandelman.ottawa.on.ca Tue Sep 14 19:55:01 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Tue Sep 14 18:55:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message from Pekka Nikander of "Tue, 14 Sep 2004 13:56:41 +0300." References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> Message-ID: <11608.1095206370@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- My recommendation is to finish the drafts as they are. If there are still opportunities to steal IKEv2 concepts (i.e. packet formats, traffic selector descriptors, etc.) for the current document, do so. (I would have thought it was too late for that) Were I implementing HIP in Openswan (which I wish I had resources to do), I would likely write a seperate daemon, but turn many pieces of pluto relating to PF_KEY, management, policy, etc. into libraries. It would be nice if HIPv2 was simply a set of extensions to IKEv2(.1) that applied to IPv6 host-host use only. I think we are among the few with feet in both the "managed insecurity" camp, and the "opportunistic security" :-) (Recently, we have been discussing how to use EAP and/or XAUTH to "upgrade" an opportunistic connection to a "managed" one) - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUeF4YqHRg3pndX9AQHG9wQA1QP5qsU9e7IYxo5Fy73Xio7NGVdYNYy0 YpgcjeEl08Z3Z6/ZylMOEc4tqvE31Z4NFPFFYRAIL98NajHrJgflPIUDrKReyBw7 rpe4X7QalSXGJ0IW874v/yxle407hcdHiiw+64pEfg1zByU4RbOnt+P0Gv9MVGvZ JFgVABsu5UM= =eVUn -----END PGP SIGNATURE----- From Julien.Laganier@Sun.COM Wed Sep 15 03:37:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Sep 15 02:37:01 2004 Subject: [Hipsec] HIP checksumming and FROM option In-Reply-To: <41472266.4080706@cs.helsinki.fi> References: <41472266.4080706@cs.helsinki.fi> Message-ID: <200409150942.59156.julien.laganier@sun.com> On Tuesday 14 September 2004 18:55, Andrei Gurtov wrote: > Hi, Hi, > While trying to implement indirection support for HIP, I had some > challengies related to changing IP addresses in the I1 packet. > With current specs it requires adding a FROM option containing the > source IP address and recomputing the HIP checksum (that covers the > pseudoheader including IP addresses). Some people have argued that > such checksumming was a bad design choice in UDP, since it violates > a clean layering concept and e.g. prevents running UDP over > anything but IP. Is there any strong reason for including > pseudoheader in the HIP checksum? I believe the reason for including pseudoheader in the HIP checksum is the same as for any upper layer (e.g., UDP, TCP, etc.): avoiding packets to end-up to the wrong recipient without they even notice it. Perhaps it's not a big deal if a wrong recipient get a HIP I1, because there is the HITs anyway, but if one think to opportunistic mode, the recipient will answer with an R1... This is useless traffic and processing. > Without it, it would be easier to > change IP addresses in the network, facilitating traversal of NATs > and middleboxes. Sure but, > There is a checksum in the IP header anyway. There's no checksum in the IPv6 header, and the IPv6 specs says: o Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header > Furthemore, how about making the FROM option mandatory in handshake > packets? It would make middlebox programming easier. There are several reason why FROM is not mandatory: You might simply rewrite the destination address if there's no egress filtering at the RVS's network, so no need for FROM since the source address isn't altered. You might also want to omit it intentionnaly (for privacy). What do others think? Thanks, --julien -- Julien Laganier SUN Microsystems Laboratories From mkousa@cc.hut.fi Wed Sep 15 06:30:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Sep 15 05:30:00 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 In-Reply-To: References: Message-ID: The more I read the draft the more I'm beginning to get confused.. If the initial UPDATE contains multiple NES parameters as mentioned in section 6.2, does the reply UPDATE also have to include all NES parameters in a single packet ? The draft doesn't seem to answer this, so let's speculate what happens when NES parameters are not sent in a single packet: The initial UPDATE packet sent by host A contains NES1+NES2+SEQ. The packet is sent out and the peer host B starts to process it. Let's assume that the peer B sends corresponding NES+SEQ+ACK for each of the NES received in the initial UPDATE. B sends a reply UPDATE containing only one NES, and moves to rekeying state. Then assume that before the host B continues processing on to NES2, host A sends ACK, and B receives it. According to the base draft host B can now move back to established, because B has sent its own NES and even received ACK for it. Now B continues to process the rest of the A's NES parameters, NES2 that is. At this point B is in established state, but the NES processing function might think it is in still in rekeying state. Problems might arise. The other thing here is that the SEQ parameter can not be the same for all reply UPDATES of B, or else they are considered as retransmissions (and therefore possibly dropped). So, in short I assume that the answer to my question is "yes"; all NES parameters of B have to be in a single packet. The solution to the state machine problem would be to send the reply UPDATE not before all of the NES parameters are ready. If someone else understood what I'm trying to say here, I would like to get some confirmation whether I'm right or wrong. The draft might also be updated regarding this issue. I also have a feeling that the possibility of sending a separate UPDATE containing only ACK and then a separate UPDATE containing the corresponding NES+SEQ could be removed. Allowing reply UPDATEs to contain only NES+SEQ+ACK might provide cleaner implementations. From pekka.nikander@nomadiclab.com Thu Sep 16 02:37:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Sep 16 01:37:01 2004 Subject: [Hipsec] HIP checksumming and FROM option In-Reply-To: <200409150942.59156.julien.laganier@sun.com> References: <41472266.4080706@cs.helsinki.fi> <200409150942.59156.julien.laganier@sun.com> Message-ID: > I believe the reason for including pseudoheader in the HIP checksum is > the same as for any upper layer (e.g., UDP, TCP, etc.): avoiding > packets to end-up to the wrong recipient without they even notice it. Right. Furthermore, the location of the checksum in the pseudo-header is such that it should be possible to use existing hardware accelerators to verify and compute it. >> Furthemore, how about making the FROM option mandatory in handshake >> packets? It would make middlebox programming easier. > > There are several reason why FROM is not mandatory: You might simply > rewrite the destination address if there's no egress filtering at the > RVS's network, so no need for FROM since the source address isn't > altered. You might also want to omit it intentionnaly (for privacy). Agreed. Especially in the Hi3 case you may want just to rewrite the destination address, as most probably you want to route the reply packet through i3, too. Optionally, you could also rewrite the source address to point to an i3 server that is topologically close to the Recipient. --Pekka From pekka.nikander@nomadiclab.com Thu Sep 16 03:33:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Sep 16 02:33:00 2004 Subject: Protocol type for HIP -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4147619C.8050602@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F2A3.5030204@acm.org> <4147619C.8050602@acm.org> Message-ID: <7401317C-07B3-11D9-8BA1-000D9331AFB0@nomadiclab.com> >> No, we are not achieving [demultiplexing] through SPIs. We are >> achieving [that]=A0through using the HITs in the socket and the >> pseudo-header, as >> Tom already wrote. >> >> There rest, like using SPIs as a shorthand, is details, and not >> important from the highest architectural-level point of view. > > I understand this point. And I totally agree with you that keeping > the SPI (or even HIT, if someone so wanted) in every packet is the > right architecture. What I don't agree with is that the protocol > that does the binding between the current IP address and a > corresponding HIT should also be an IP protocol type. Ok. I understand your stance, but disagree. A perhaps major source of my disagreement is that I don't consider HIP just as a binding management protocol, but as a new, full layer. But let's see... > I guess the difference in opinion is because in my mind, > multiplexing connections and managing bindings are separate > issues (and it might just be my tunnel vision). I don't quite understand what do you mean with that statement. Reading further... > To me the present HIP key-exchange is a connection oriented > protocol, unlike the traditional connectionless model of IP. Ah. But by adding replay protection to IPsec you basically make the whole IP layer to have state, i.e., connection-oriented. Apparently we need to go into fundamentals. For more on my stance on this, see Tuomas Aura and Pekka Nikander, "Stateless connections," in proceedings of International Conference on Information and Communications Security ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, Springer Verlag 1997. Trying to summarize some of the thoughts in that paper, the basic difference between connection-oriented and connection-less protocols is where the state is maintained. The organization of retransmissions is less relevant, as is congestion control. They are different aspects, and almost orthogonal. In a connection-oriented protocol you keep state on both ends. (According to this classification, a bound UDP socket is connection-oriented.) In a connection-less protocol you typically keep state only at the client/initiator/whatever end, or at neither end. In the latter case the state is typically kept at the higher protocol layers. In traditional IP, all state is at upper layers. The only state that IP needs to keep is the routing state. Especially, there is no state associated with a given peer IP address. This all changes with the introduction of IPsec, and especially when you apply replay protection. Then you have to keep state per peer address, including the session keys AND the replay counter. =46rom this point of view, making the HIP control protocol something that is more or less parallel to ICMP is the right choice. (This stance is strengthened with middle-box considerations.) > So I am a little reluctant to mix the key-exchange > (ip-to-hit-binding-management) with the actual packet processing > (which I want to keep connection less). Well, that is not mixed, currently. In effect, you are now arguing that instead of allocating one protocol number, we should allocate two: one for HIP control traffic, and the other one for HIP data traffic. The fact that we are using ESP for the latter _is_ problematic, but currently it is the best we can easily do without allocating yet another protocol number. > Note that the way ESP is designed, is connection less But it is not :-) Already the keys create a kind of peer-to-peer connection, and that is made much stricter and stronger with the introduction of replay-protection counters. > (even though aalmost all key exchanges, even for Multicast, will be > connection oriented running as applications on some transport=20 > protocol). Remember my earlier comment about the relationship between a control protocol and the corresponding payload protocol? I don't want to repeat that. Think about parallels in modern design: - ICMP runs on the top of IP, which it controls. - SIP runs on the top of UDP, which it typically controls. - HTTP control is in-band. - SCTP and TCP control is in-band. - most routing protocols run on the top of IP, which they control Hence, the majority of IP world control protocols seem to run either directly on the top of the protocol that they control, or in-band. The notable exceptions are IKE and some routing protocols. In the routing protocols' case TCP is used for retransmissions. =46rom an architectural point of view, I consider the IKE case especially problematic, as it requires a specific exception to the default IPsec policies in order to allow IKE to get through. Such exceptions make any architecture less beautiful. (Read: I still think that some aspects of IKE stink, even with IKEv2.) In summary, to me it is almost impartial whether the future HIP will be based on a single protocol number, where both the control and data protocols share the same protocol number, or whether we use two protocol numbers. What I am opposing is moving the control protocol to an upper layer, where it does _not_ belong. I slightly favour two protocol numbers, as using two protocol numbers makes it easier to separate control and data traffic at middle boxes. > I would like to keep the connection-less model of IP as it is, > even after introducing the layer 3.5, and to me this means > separating the binding management from the actual packet processing. I don't have anything against separating the control protocol (your binding management) and the data protocol (your packet processing). That is what we effectively do today. What I am opposing is the idea of unnecessarily inserting another protocol between the control protocol and the data protocol. That opposition is purely architectural, as I have written a number of times. Practical matters weight otherwise, and as I have written, if people want to write a HIP-over-UDP draft, I will be in favour of accepting it as a WG item. > I think it's okay to gain experience using the present draft > (i.e., IP as MUST as you want, and UDP as SHOUD/MAY/OPTIONAL-- > pick one). We can always come back during STD track discussion. Agreed other than that if there is UDP, it should be OPTIONAL, or at most SHOULD implement, MAY use, default use being IP. > I guess the implementation viewpoint is just the reflection of > present architecture. I like the present architecture, but I > also like the ideas of HIP. And I want both. :-) You want the benefits but not the drawbacks. :-) How nice. :-) More seriously, for me the new architecture that HIP presents is much more important than the features it gives. >>>>> IKE is implemented on UDP for a good reason. >> >> Out of curiosity, what are those good reasons? > > ... I am just extrapolating what I understand ... Still, it would be nice to explicitly hear what you understand so that I can rip it down and tear in pieces :-) > Another point that Steve Deering made during the IETF plenary > session of August 2001 was to look at Internet Protocols as an > hourglass whose waistline is IP. There is advantage in keeping > that waistline thin (and straight), IMO. I was there. Many people think that it is time to move that waistline on the top of IP (or around IPsec), which is exactly what HIP is doing. (The motivation for moving the waistline up is that we currently have two waists, IPv4 and IPv6.) > My rule of thumb: if its not related to routing, don't put it > near IP (take it of leave it; I'm not going to argue either > way on this. :-) ). The current IP has much more than just routing. IPsec is a main culprit (if not the main culprit) for that. Based on your argument, we should get rid of IPsec and use TLS. The "lower" part of IP, which implements routing, fragmentation and few other things, is fine and dandy. It is the upper, host-specific part of IP which has become bloated and ugly. If I was to blame a single party, I would point to the VPN and IPsec gateway folks in the IPsec WG, and Paul Francis for inventing NAT. But that would most probably be unfair. More seriously, I think that the current situation results from too little direction from the IAB and too little architectural house-keeping from the IESG members. --Pekka From pekka.nikander@nomadiclab.com Thu Sep 16 03:38:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Sep 16 02:38:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <11608.1095206370@marajade.sandelman.ottawa.on.ca> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> Message-ID: <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> > If there are still opportunities to steal IKEv2 concepts (i.e. packet > formats, traffic selector descriptors, etc.) for the current document, > do so. (I would have thought it was too late for that) I don't think we would like to steal IKEv2 packet formats, because IMHO our packet format is slightly better. We don't need to steal traffic selectors, as we don't have them. (If someone is to write a traffic selector extension to HIP, it would be nice if they used IKEv2 compatible mechanisms.) What we should do is to fix HIP to be SIGMA compliant. I asked Yogesh to make a write-up for that, as he seems to be a better expect in that aspect than we are. But he hasn't answered whether he will do that or not, or at least I haven't seen any indication from him in that respect. > Were I implementing HIP in Openswan (which I wish I had resources to > do), I would likely write a seperate daemon, but turn many pieces of > pluto relating to PF_KEY, management, policy, etc. into libraries. Sounds pretty much how we've implemented HIP for FreeBSD. BTW, our user level parts now compile on Linux, too. They don't run, as we don't implement NETLINK support and Linux doesn't implement the necessary PF_KEY extensions. > It would be nice if HIPv2 was simply a set of extensions to IKEv2(.1) > that applied to IPv6 host-host use only. Agreed other than that I don't understand your reference to IPv6. HIP supports quite nicely IPv4, both at the API and especially as a packet transport. --Pekka From yogesh.swami@acm.org Thu Sep 16 12:33:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Thu Sep 16 11:33:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> Message-ID: <4149C130.8080409@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig325C6F73E38B5C7E82A853F0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Pekka, ext Pekka Nikander wrote: >> If there are still opportunities to steal IKEv2 concepts (i.e. packet >> formats, traffic selector descriptors, etc.) for the current document, >> do so. (I would have thought it was too late for that) > > > I don't think we would like to steal IKEv2 packet formats, because > IMHO our packet format is slightly better. We don't need to steal > traffic selectors, as we don't have them. (If someone is to write > a traffic selector extension to HIP, it would be nice if they used > IKEv2 compatible mechanisms.) > > What we should do is to fix HIP to be SIGMA compliant. I asked > Yogesh to make a write-up for that, as he seems to be a better expect > in that aspect than we are. But he hasn't answered whether he will > do that or not, or at least I haven't seen any indication from him > in that respect. > I will do this sometime next week (and reply to a few e-mails in the same time frame). Sorry about not replying to those e-mails earlier (I got caught up with some other work). Thanks Best Regards Yogesh --------------enig325C6F73E38B5C7E82A853F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQUnBPXkjMhOId4nzAQLZ2Qf/SnD6gmod906cre1UuCD6HuKBeU9YMFJa Ot/WJS0ihfgWkIWjRZic4m+B4CU4ACa6QRywcNTvcXgq1d/gtLyr5AaDyHBQMFgU CdHEu+xeiJomQnaqaGO8/NRm8YSk3vxZRbIjZtIic+Hmi/wmEiXmGDcRZ0y0AJ9D 7il/yv/5I+bALIMtJQSpAALi9l9SJFcaguPiqZchvwSnS2uiOfpslm8eP/tK9FWE aeNT95PJ7k2/6zczHLki+r1csvCjE2XNPKKTxFNXwBoTfSWpT/K0RmyJP/L+xD6B R5utTbjrQy6lY2yalxmjV+blJgPypSbrLxiEHHhrrt3Z2dIBVKfE0A== =HiRr -----END PGP SIGNATURE----- --------------enig325C6F73E38B5C7E82A853F0-- From mcr@sandelman.ottawa.on.ca Thu Sep 16 16:21:01 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu Sep 16 15:21:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message from Pekka Nikander of "Thu, 16 Sep 2004 10:43:06 +0300." <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> Message-ID: <3995.1095344096@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: >> If there are still opportunities to steal IKEv2 concepts Pekka> I don't think we would like to steal IKEv2 packet formats, Pekka> because IMHO our packet format is slightly better. We don't I was pretty sure it was too late for such a thing anyway :-) ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUmf34qHRg3pndX9AQHZUwP9EEC7y/q36OkXZJVcFcfHTlX9rIhLojcW +CBgnd2smeiVQqA7pAfRdJgBpXVrApz3BQpDmcH7sYAozr0YJHagnrXaAeS291ll TQWB3nESnKJ/wOfpta6dGXd0Rtt9vAndwALu9pcR4fabEEorzGncmD/wGGbrMPw8 wsMJA3lr6SE= =deOk -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Thu Sep 16 16:21:06 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu Sep 16 15:21:06 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message from Pekka Nikander of "Thu, 16 Sep 2004 10:43:06 +0300." <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> Message-ID: <2688.1095340120@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: >> It would be nice if HIPv2 was simply a set of extensions to >> IKEv2(.1) that applied to IPv6 host-host use only. Pekka> Agreed other than that I don't understand your reference to Pekka> IPv6. HIP supports quite nicely IPv4, both at the API and Pekka> especially as a packet transport. I realize this, but I the places where I think HIP will be easily adopted are IPv6 situations. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUmQVoqHRg3pndX9AQGq8gQAxTxQU/zXL4Udb6imat4z8BFcGhRisT97 I2AzZFbV9SB47HLW8O4qYwSm5fXwFtCmeQdOTsmnd9vnWmmI5/9rOD7U+BiTEm95 uqdNfhEHE9JgfAUYZUUTtqp4M2ofH07QluOiqhSZxieL7L6794RUZ+PIQqx5M7GR 2LjOF/GcRX0= =zvfF -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Thu Sep 16 16:28:01 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu Sep 16 15:28:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message from Pekka Nikander of "Thu, 16 Sep 2004 10:43:06 +0300." <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> Message-ID: <3644.1095366783@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: >> It would be nice if HIPv2 was simply a set of extensions to >> IKEv2(.1) that applied to IPv6 host-host use only. Pekka> Agreed other than that I don't understand your reference to Pekka> IPv6. HIP supports quite nicely IPv4, both at the API and Pekka> especially as a packet transport. I realize this, but I the places where I think HIP will be easily adopted are IPv6 situations. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUmQVoqHRg3pndX9AQGq8gQAxTxQU/zXL4Udb6imat4z8BFcGhRisT97 I2AzZFbV9SB47HLW8O4qYwSm5fXwFtCmeQdOTsmnd9vnWmmI5/9rOD7U+BiTEm95 uqdNfhEHE9JgfAUYZUUTtqp4M2ofH07QluOiqhSZxieL7L6794RUZ+PIQqx5M7GR 2LjOF/GcRX0= =zvfF -----END PGP SIGNATURE----- From mcr@sandelman.ottawa.on.ca Thu Sep 16 16:28:05 2004 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Thu Sep 16 15:28:05 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: Message from Pekka Nikander of "Thu, 16 Sep 2004 10:43:06 +0300." <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <11608.1095206370@marajade.sandelman.ottawa.on.ca> <0C75816C-07B4-11D9-8BA1-000D9331AFB0@nomadiclab.com> Message-ID: <3654.1095366787@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: >> If there are still opportunities to steal IKEv2 concepts Pekka> I don't think we would like to steal IKEv2 packet formats, Pekka> because IMHO our packet format is slightly better. We don't I was pretty sure it was too late for such a thing anyway :-) ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUmf34qHRg3pndX9AQHZUwP9EEC7y/q36OkXZJVcFcfHTlX9rIhLojcW +CBgnd2smeiVQqA7pAfRdJgBpXVrApz3BQpDmcH7sYAozr0YJHagnrXaAeS291ll TQWB3nESnKJ/wOfpta6dGXd0Rtt9vAndwALu9pcR4fabEEorzGncmD/wGGbrMPw8 wsMJA3lr6SE= =deOk -----END PGP SIGNATURE----- From yogesh.swami@acm.org Sun Sep 19 17:04:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Sun Sep 19 16:04:00 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> Message-ID: <414DF55F.7020802@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA050F40EF8C6E8B1B248CB7 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > I would be very glad if you would outline the necessary _minimal_ > changes that are needed to make HIP to be based on SIGMA. > Okay, the minimal changes required in the present HIP key exchange is to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in the HMAC of message 4 (shown in the message exchange below). Note that the present protocol in the draft looks fairly secure, but as SIGMA paper points out encryption is not the right method to prove possession of session key (but the attack that the paper describes in the presence of stream cipher doesn't apply here). So while the encrypted token { PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token guarantees that identity mis-binding attack cannot be carried out, it's still better to use HMAC, IMO. (Besides we have a proof that HMAC based scheme is secure.) I have also added nonce-I and nonce-R in all these message. This is important to allow parallel SA creation, and allow cases where both initiator and responder choose pre computed g^i and g^r (this can happen, unless the draft explicitly prevents it). The nonce should be used in deriving the session keys. So the key exchange with minimum change should look something like: 1. I->R: NCN-I, 0, HIT-I, [HIT-R] 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R SIG( HIT-R, g^r, PUBLIC_KEY-R) 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, { PUBLIC_KEY-I, Domain-ID-I }_g^ri, SIG( HIT-I, HIT-R, SPI, g^i, { PUBLIC_KEY-R, Domain-ID }_g^ri, ) *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content has changed */ o In the draft it's important to say that the responder should keep the random value r for at least 2*MSL (and possibly longer) from the last time it sent message 2. In case Message 3 arrives after 2*MSL, and no random number r can be found, it should be dropped and an ICMP message should be sent. If the Initiator receives an ICMP after sending message-3, it should not assume that the responder sent the message, and should not close that session. An Initiator MAY however start with a new parallel I1 with a new nonce value. Couple of observations about this key exchange: A) The identity of Responder cannot be concealed even against the passive attack. The HOST_ID in message-2 is required so that the Initiator can get the public-key to verify the SIGNATURE from responder. B) The identity of Initiator cannot be concealed against an active attacker unless g^r is covered in SIGNATURE calculation in message-2. (So keep section-7 description and change section-4 text) (A) and (B) together means that if we want to get responders ID protection then we need to severely reorganize the messages. One simple thing one can do is to only send the public-key and in message-2 (and leave Domain-ID-R field completely out). Later, Responder can put Domain-ID as encrypted in message-4 and let Initiator verify it against the MAC received in message-2. The advantage is that we can now protect the identity of Initiator against passive attacker and the Identity of responder against Active attackers. The disadvantage is that the Initiator's ID cannot be protected against active attackers. Also, the HOST_ID packet format will have to be changed. Note that protecting the Public-Key alone without Domain-ID is not that useful. The worst thing that an attacker can do by stealing the public key is to register it under her own name (i.e., Eve takes Alice's public key and puts it in DNSsec under Eve's name, assuming DNSsec doesn't do proof of possession checks). But the HMAC binding to name in SIGMA prevents from attacks that can result from this kind of behavior, so it's not that useful to protect the public-key. Note that this is the reason I have added HOST_ID in message-4. HMACing only HITs will get us in trouble. Yogesh --------------enigDA050F40EF8C6E8B1B248CB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQU31aXkjMhOId4nzAQJcZAgAi17PW+WVdKNmvAkIUw+G/CKaThuV35Gy tkWnUr17vtqQktUcfxQPO88r9PAd1aofygS4GQESZ7lCXag/f79K8Vwx3tkGzzRI hXp5djomPCkHtBDcTtEYVqaet/tHORHUAjBrtWAJ1+A1SxkiRThMRarz31hpD1Bt lV7bFopJVW1B9yX/4neFKWtLAWRe9IyL+DHBi5WI8KTCR0gqBLbE5uVGTcXVng3S 7eUzBc5JK5vKpGI1Kb9lgKnl5vQKQZU5WRZYQrbKaWN3CosobtutTPfdzmQyRm7/ lvQhGqHEiEvSGA2d4ewuH3jIcprIHDlHRbVyeB87KbXB1PkLxEFASw== =lHQ9 -----END PGP SIGNATURE----- --------------enigDA050F40EF8C6E8B1B248CB7-- From gurtov@cs.helsinki.fi Thu Sep 23 08:19:04 2004 From: gurtov@cs.helsinki.fi (Andrei Gurtov) Date: Thu Sep 23 07:19:04 2004 Subject: [Hipsec] HIPL test server running In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040607D2@xch-nw-27.nw.nos.boeing.com> Message-ID: <4152C093.4030900@cs.helsinki.fi> A test server hipserver.hiit.fi running IPv6 HIPL implementation for Linux 2.6.6 from HIIT is online. Its IPv6 address is 2001:5c0:8fff:fffe::2cd and HIT 556b:0617:26ce:0752:be2b:75bd:ac26:190f. It will be frequently booted during day time, but should be available during European night time. Andrei From thomas.r.henderson@boeing.com Mon Sep 27 13:13:03 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Sep 27 12:13:03 2004 Subject: [Hipsec] new Linux implementation of HIP available Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C045225DA@xch-nw-27.nw.nos.boeing.com> I'm pleased to announce the availability of Boeing's experimental=20 HIP implementation for Linux at: http://hipserver.mct.phantomworks.org More details are at: http://hipserver.mct.phantomworks.org/docs/hipdoc.html The test server is still operational for HIP testing, as before. Kudos to Jeff Ahrenholz for the bulk of the coding and testing of this implementation. Tom From thomas.r.henderson@boeing.com Tue Sep 28 13:01:08 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Sep 28 12:01:08 2004 Subject: [Hipsec] Multiple SAs and UPDATE, mm-02 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406086A@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi]=20 > Sent: Wednesday, September 15, 2004 3:35 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Multiple SAs and UPDATE, mm-02 >=20 >=20 > The more I read the draft the more I'm beginning to get confused.. >=20 >=20 > If the initial UPDATE contains multiple NES parameters as=20 > mentioned in=20 > section 6.2, does the reply UPDATE also have to include all=20 > NES parameters=20 > in a single packet ? I do not believe that this is (or should be) a requirement. >=20 > The draft doesn't seem to answer this, so let's speculate=20 > what happens=20 > when NES parameters are not sent in a single packet: >=20 > The initial UPDATE packet sent by host A contains NES1+NES2+SEQ. The=20 > packet is sent out and the peer host B starts to process it. >=20 > Let's assume that the peer B sends corresponding NES+SEQ+ACK=20 > for each of=20 > the NES received in the initial UPDATE. B sends a reply=20 > UPDATE containing=20 > only one NES, and moves to rekeying state. Then assume that=20 > before the=20 > host B continues processing on to NES2, host A sends ACK, and=20 > B receives=20 > it. According to the base draft host B can now move back to=20 > established,=20 > because B has sent its own NES and even received ACK for it. I don't think that B can move back to established because it has additional NES pending to process. The base draft doesn't=20 cover the multihomed case, so there should be language in hip-mm to clarify this. >=20 > Now B continues to process the rest of the A's NES=20 > parameters, NES2 that=20 > is. At this point B is in established state, but the NES processing=20 > function might think it is in still in rekeying state. Problems might=20 > arise. I don't think that state machine should transition in the middle of packet processing. >=20 > The other thing here is that the SEQ parameter can not be the=20 > same for all=20 > reply UPDATES of B, or else they are considered as=20 > retransmissions (and=20 > therefore possibly dropped). >=20 Agreed. Each time a new UPDATE is generated, a new SEQ should be used. >=20 > So, in short I assume that the answer to my question is=20 > "yes"; all NES=20 > parameters of B have to be in a single packet. The solution=20 > to the state=20 > machine problem would be to send the reply UPDATE not before=20 > all of the=20 > NES parameters are ready. I think that one can certainly hold the reply UPDATE, but it is not mandated. =20 >=20 > If someone else understood what I'm trying to=20 > say here, I would like to get some confirmation whether I'm right or=20 > wrong. The draft might also be updated regarding this issue. >=20 >=20 > I also have a feeling that the possibility of sending a=20 > separate UPDATE=20 > containing only ACK and then a separate UPDATE containing the=20 > corresponding NES+SEQ could be removed. Allowing reply=20 > UPDATEs to contain=20 > only NES+SEQ+ACK might provide cleaner implementations. I would prefer to avoid such restrictions on packetization unless necessary. Tom