From kurtis@kurtis.pp.se Wed Oct 1 00:47:01 2003 From: kurtis@kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue Sep 30 23:47:01 2003 Subject: [Hipsec] Re: Security requirements for identification In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hmmm.... I suppose that I should respond. ;-) Thanks! :-) > Yes, I think that that some kind of consensus on the properties > of identifiers is a necessity. There is a long discussion > to get there. Could we get rough consensus on it? Yes, I think > so, but it might be very rough. I think we need a point to start at anyway. > And it might take a very long > time. Certainly the discussions within our design team have taken > awhile and that's with a much smaller number of people. It may > well be faster to start the discussion with the output of one of > the design teams, so that the discussion can revolve around an > entire design, rather than effectively throwing open design discussions > to the entire WG. I'm flexible in this regard. I am just trying to get a feeling of what people think. I do agree that working on the output of the DTs might be the fastest way, on the other hand, whatever we could do in parallel is just an added value. > However, as a Loyal Opponent of Bureaucracy, I have to question > whether this needs to be a document. And whether this needs to > be an official WG document, given that it will not become end > product. It could become a product, question is if that would help us. I will be the first to agree to cut down the amount of drafts published, so if we can do without, the better. I just have a feeling that we lack actual text to discuss around. We are just adding more ideas, but not producing real consensus one way or the other. > In the Good Olde Days, the WG chair was a neutral discussion > leader and tried to establish consensus by ensuring that > differing points of view were represented in the work output > and that the group came to rough consensus on very small points > in a gradual manner. This is not the only way that these things > can happen, but a reminder of what once was. I leave it to the > WG to choose the best path. I agree with the above. I have at least _tried_ to be neutral, maybe even to neutral to get the discussion going in a direction. But from above, I think this would also be easier on my part if we actually had real text to discuss around. But I have no strong feeling one way or the other on the original question. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP3ndx6arNKXTPFCVEQJu8QCgrbj5uTfbhbO/6fkMQ+MuKiPg+QEAoPa0 zCV52StE3RrhRBiHeVmpOAOR =XeGK -----END PGP SIGNATURE----- From Tony.Li@procket.com Wed Oct 1 00:47:03 2003 From: Tony.Li@procket.com (Tony Li) Date: Tue Sep 30 23:47:03 2003 Subject: [Hipsec] RE: Security requirements for identification Message-ID: Ok, let me see if I can give a taxonomy of possible identifier properties: 1. Syntax Fixed length Partitioned Fixed size partitions Variable sized partitions Atomic Variable length 2. Global Semantics None Globally unique Database key No further semantics 3. Local Semantics None Locally unique No further semantics Expresses local geography Expresses local topology Expresses other local properties 3. Generation Random bit string Cryptographic hash Hierarchical assignment Tony From Erik Nordmark Wed Oct 1 00:47:04 2003 From: Erik Nordmark (Erik Nordmark) Date: Tue Sep 30 23:47:04 2003 Subject: [Hipsec] RE: Security requirements for identification In-Reply-To: "Your message with ID" Message-ID: > As you mention, there are multiple times that i don't really need to know > the identifier of the end-point that i want to communicate to, but what i > want is the identifier of the service that i want to contact (is this what > you meant?) Yep. > So in this case, the fqdn act as a service identifier. So if i have a > permanent service identifier (i.e. a fqdn), it is enough to have ephemeral > end-points identifier, since when i want to establish a communication with a > given service i just look for the currently valid ephermeral endpoint > identifier. > > The next question then is whether this is enough... I mean can we just live > with ephemeral endpoint identifiers and stable service identifiers? >From the perspective of handling at least a narrow interpretation of multi6 I think this is enough. But it doesn't make the identifiers first class objects in the architecture; it would be impossible to use them as the sole handle for referrals and perhaps also for rendez-vous (in Keith's definition of that term; "call me back when you are done") I think this means that we can use it to make transport protocols and simple applications protocols unaware of multihoming, but richer application protocols would need something else. Whether that means passing around a list of locators to represent a peer, or do use a fqdn to designate a peer (which requires work to avoid confusing with fqdns which designate a service), or something else I don't know. > Not so sure, i mean, you are using the fqdn to make the initial contact, so > the fqdn is an permanent identifier. You can consider that the fqdn is a > service identifier. Ok, then when contact the other end through the locators > that you have obtained through the DNS, you will exchange a ephemeral > identifier, but this ephemeral identifier is a *service* ephemeral > identifier, isn't it? i mean you know that a service is at given location > and then you exchange an identifier to be sure that you always talk to the > same entity, this would be a service identifier, i guess. The FQDN could be viewed as an identifier for the service i.e. consistent with current usage of fqdns. You'd exchange the ephemeral identifier with a peer node thus you'd presumably get an ID for that node (a stack name), and not an ID for the service. You would need to find out which of the locators refer to that identity so that you don't try to redirect the traffic to go to a different node. Perhaps that could also be exchanged as part of the handshake that exchanges the emphemeral ids. > So my question is whether we should focus on providing a multi-homing > solution based on the loc/id split or we should design a loc/id split that > covers as many as possible of the apsects related with the overloaded model > of identifiers in current IP, such as the ones that you mention or the ones > covered in JNC's paper. If it was "free" I think the more general problem would be the right one. But designing and deploying a system capable of looking up identifiers (with desirable properties; they would be flat or near-flat ids I think) is clearly something which will take time. In practice I think we need to figure out something which can be incrementally deployed providing incremental multihoming benefits along the way. If we can do this and maintain the ability add the lookup system along the way it the lookup system wouldn't be a gating factor for deployment of a solution to the multi6 connection rehoming problem. Erik From pekka.nikander@nomadiclab.com Wed Oct 1 04:54:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 03:54:01 2003 Subject: [Hipsec] Update: HIP base exchange issues status In-Reply-To: <3F5C7FA9.8070609@nomadiclab.com> References: <3F5C7FA9.8070609@nomadiclab.com> Message-ID: <3F7A8E6F.5000500@nomadiclab.com> I think we have closed issue #5, extensions, and issue #10a, IPv4 pseudo header format. I also think that we can close #11a, HMAC, since I have received no comments on that. #13, sending multiple I1s in parallel, seems also to be closed. Discussion on #15, checking of anynymous HIs, seem to be ceased, and can be IMHO closed, too. If you disagree with closing any of these, please send a note NOW. I am still waiting for comments on the following issues: 3. NES 4/12. Adding HMAC to R2 14. Adding of new state E4, to close the weakness when receiving an I2 in established state 17. Unifying the suites for HIP and ESP SAs. Consequently, we have only two open issues: 16. Details for handling of LSIs. The discussion on this is going on. 18. Need example checksums This basically needs just text, and can be added to -09. Hence, this is not a show stopper for -08. I will send separate mails on issues #3, #4/12, #14 and #17 to get them closed. Summary: Closed: 1, 2, 5, 6, 7, 8, 9, 10, 10a, 11, 11a, 13, 15 Proposal: 3, 4/12, 14, 17 Open: 16, 18 --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 04:58:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 03:58:00 2003 Subject: [Hipsec] Closing issue #3: NES and REA Message-ID: <3F7A8F5C.7020104@nomadiclab.com> I want to close issue #3 for the base draft as soon as possible. Please read the new NES sections in the -08-pre draft. Please send your comments, even if they are just "looks good". I don't want to close this before receiving some comments, since I don't trust ability to think about all aspects just alone. Sections to read: 4.3 Rekey 6.3.12 NES_INFO 8.9 Processing NES packets URLs for easy reading: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor17 http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor34 http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor48 --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 05:01:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 04:01:00 2003 Subject: [Hipsec] Closing issue #4/12: Adding HMAC to R2 Message-ID: <3F7A9040.1040704@nomadiclab.com> In -08-pre, we have added HMAC to the R2 to plug a potential R1/R2 replay attack. Please read the relevant sections and send your comments to the list, even if they are just "looks good". The relevant sections are: 6.3.9 HMAC 7.4 R2 - the second HIP responder packet 8.7 Processing incoming R2 packets URLs for easy reading: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#HMAC http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#R2 http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor45 --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 05:04:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 04:04:01 2003 Subject: [Hipsec] Closing issue 14: New state E4 Message-ID: <3F7A90E2.3080708@nomadiclab.com> In -08-pre, there is a new state E4 in the state machine. It is used in the E3 state if the host receives an I2 with a proper birthday. Please read the revised sections and send your comments, even if they were just "looks good". The relevant sections are: 5.4 HIP State Machine 8.6 Processing incoming I2 packets URLs for easy reading: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#state-machine http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor44 --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 05:07:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 04:07:01 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs Message-ID: <3F7A918A.5080902@nomadiclab.com> Since we added the HMAC parameter, we now need separate integrity and encryption keys in the HIP SAs. To facilitate this, -08-pre defines the HIP transform crypto parameters differently from -07 Please read the revised sections, and send your comments to the list. This time I am not quite happy with the text; I'm afraid there are corner cases (e.g. with NES) that haven't been really worked out. The relevant sections: 6.3.4 HIP_TRANSFORM 6.3.5 ESP_TRANSFORM 9. HIP KEYMAT URLs for easy reading: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anchor32 http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#keymat --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 06:41:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 05:41:01 2003 Subject: [Hipsec] Issue 16: Details of LSI handling In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AF1@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5AF1@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F7AA789.1000300@nomadiclab.com> Tom, Thanks for clarifying this issue (again). I think that your description is very valuable, and I am planning to include it into an appendix in -08 in some for or another. > ... In our discussions in SF, there were two schools of thought, if > I recall correctly: > i) have resolver return an LSI in place of an actual IP address, and > have applications use the LSI instead of the IP address in socket > calls. > ii) have HIP be kept in kernel land, with the kernel doing the right > housekeeping. ... [T]he use of HIP is coordinated by a policy table > that temporarily traps packets going to particular IP addresses until > a HIP exchange completes and the security association is set up. We have now implemented i), but just always returning the default, HIT based LSI, and not invoking the HIP exchange from the resolver. We simply return the HIT or the LSI as the first "address" returned by gethostbyname, gethostbyname2 or getaddrinfo. The HIT or LSI is then followed by the actual addresses. Seems to work well enough for the time being. > Long term, I'd like to see host identity information exposed to > applications and explicitly used in socket calls, together with IP > addresses if need be, rather than the workarounds described above. Agreed. Actually, in our implementation if the application uses the newer getaddrinfo API, it can check whether the first returned "address" is actually a HIT/LSI or a genuine address. The flags allow this. On the other hand, Miika's "native HIP API" seems to be the right way to go in the longer term. > For the time being (without changing applications), I favor approach > ii) above, because I haven't seen anyone effectively solve all of the > issues associated with i), and because ii) basically works without > changes to the applications except for some corner cases that we > haven't encountered. Whichever solution we adopt, we probably should > document the various limitations or restrictions on use. Since we apparently have implementations doing both i) and ii), I would suggest that we leave this issue open for now. In practise, I propose that we have the current LSI exchange in I2/R2, but we leave it undefined what the hosts should do if there is a collision, referring to an appendix that contains your description of the situation. We are heading for an experimental RFC anyway, and therefore I think we can live with a few loose ends if necessary. Hence, unless I receive a very clever scheme with ready text from someone, I am planning to leave this issue technically open, and formally close it just to get -08 shipped. Is this OK for everybody? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 1 07:22:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 1 06:22:01 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis Message-ID: <3F7AB147.3060306@nomadiclab.com> I have placed now a new set of -08-pre versions on my web site: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-diff.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-chbar.txt Unless there are new issues, I expect to get -08 out before the deadline, once I've got feedback on issues #3, #4/12, #14, #16 and #17. I am planning to leave #18 open. The question is now: Shall we try base our interop tests (and possible BOF demos) in Minneapolis on -07 or -08? Personally I would prefer -08, even if it would require some more work from us. However, if nobody else has time to update their implementation to -08, we would be happy with -07, too. Our current code is (mostly) based on -07. --Pekka Nikander From Spencer Dawkins" <200310011203.07689.jrh@it.uc3m.es> Message-ID: <04a701c38826$f3c64d20$0400a8c0@DFNJGL21> Dear Juan, I'm also a little confused by the discussion, but I had assumed that we had a service name and were using DNS SRV records, which also include port numbers, etc. Not sure how a computer knows www.google.com is HTTP - or how travel.yahoo.com is also HTTP, if you're keying off the name... But somebody can tell us what they REALLY meant now. Spencer ----- Original Message ----- From: "Juan Rodriguez Hervella" To: "Erik Nordmark" ; Cc: "Erik Nordmark" ; "Pekka Nikander" ; "Multi6 WG" ; Sent: Wednesday, October 01, 2003 5:03 AM Subject: Re: Security requirements for identification > Hello, > > I'm trying to follow this thread, which seems very interesting, but I'm > surprised with this statement. IMO when you make a DNS query > you want to get the identifier of the end-point, to be able to start > the communication. Although it's true that the name usually > gives hints about the service, this isn't always true. If you > need "www.google.com", you already know that the service will > be "HTTP". You don't ask the DNS for the service, what you really > need to know is the address of "google" to start the HTTP transfer. > > Don't you agree with this ? > > Cheers. > > -- > JFRH > From thomas.r.henderson@boeing.com Wed Oct 1 12:56:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 1 11:56:01 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B30@xch-nw-27.nw.nos.boeing.com> >=20 > The question is now: Shall we try base our interop tests > (and possible BOF demos) in Minneapolis on -07 or -08? >=20 > Personally I would prefer -08, even if it would require some > more work from us. However, if nobody else has time to update > their implementation to -08, we would be happy with -07, too. > Our current code is (mostly) based on -07. >=20 Considering that there is a push to take -08 forward in the near future, I think it would be wise to try to achieve interoperability on the basis of that draft. From andrew@indranet.co.nz Thu Oct 2 17:34:03 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Oct 2 16:34:03 2003 Subject: [Hipsec] Closing issue #4/12: Adding HMAC to R2 In-Reply-To: <3F7A9040.1040704@nomadiclab.com> References: <3F7A9040.1040704@nomadiclab.com> Message-ID: <363000000.1065128472@ijir> -----BEGIN PGP SIGNED MESSAGE----- This looks good. We may wish to add to the note on the signature processing something along these lines: Signature the signature is calculated over the HIP packet, excluding the HIP_SIGNATURE TLV field, but including the HMAC field if present. ... and similarly for HIP_SIGNATURE_2. Andrew - --On Wednesday, October 01, 2003 11:28:48 AM +0300 Pekka Nikander wrote: > In -08-pre, we have added HMAC to the R2 to plug > a potential R1/R2 replay attack. > > Please read the relevant sections and send your comments > to the list, even if they are just "looks good". > > The relevant sections are: > > 6.3.9 HMAC > 7.4 R2 - the second HIP responder packet > 8.7 Processing incoming R2 packets > > URLs for easy reading: > > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#HMAC > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#R2 > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anch > or45 > > --Pekka Nikander > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP3ySHFGmVIGYWzvRAQGIPAQAk7/mpaUM+wAq5zK/2/cZG4ypxcZV2P1+ Eb66ZplwA5h81KYfyYpfPtXH1PujvHU8uStdea1In7V4kRDiMU8v4L9QUd5ffbs2 t6YHyulBN/Qsp/TTop2hry3oCB4Ps4CaeL9PD4BqMi0FQV9mhkrH78Y+BcVa6Sfi f4dZ0HUl/Qs= =ax5A -----END PGP SIGNATURE----- From andrew@indranet.co.nz Thu Oct 2 17:44:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Oct 2 16:44:01 2003 Subject: [Hipsec] Closing issue 14: New state E4 In-Reply-To: <3F7A90E2.3080708@nomadiclab.com> References: <3F7A90E2.3080708@nomadiclab.com> Message-ID: <367290000.1065129103@ijir> -----BEGIN PGP SIGNED MESSAGE----- Looks good. Actually, E4 is spread around all the processing, not just on incoming I2. This change does remove the rekey race (I can make the race happen in practice with the old rules, the window can be as much as a couple of seconds). Andrew - --On Wednesday, October 01, 2003 11:31:30 AM +0300 Pekka Nikander wrote: > In -08-pre, there is a new state E4 in the state machine. > It is used in the E3 state if the host receives an I2 > with a proper birthday. > > Please read the revised sections and send your comments, > even if they were just "looks good". > > The relevant sections are: > > 5.4 HIP State Machine > 8.6 Processing incoming I2 packets > > URLs for easy reading: > > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#stat > e-machine > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anch > or44 > > --Pekka Nikander > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP3yUj1GmVIGYWzvRAQFqxQQAosf6J6caPBouCGYrsu9ZMxioUROzAPs3 KYbWVyxbUAdSqednlr3NHptgHtbLnbcgw30Oq6RU6mb2FLgewy0rmZOqYiBNld8k 9hWloCdHZYo1S1pxZQ+ZazlU02onf4xo4m10F8vf5MMIxv9fPcuxwgsuLF6zzROP hAHaZgBBaUA= =I87r -----END PGP SIGNATURE----- From andrew@indranet.co.nz Thu Oct 2 19:47:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Oct 2 18:47:01 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <3F7A918A.5080902@nomadiclab.com> References: <3F7A918A.5080902@nomadiclab.com> Message-ID: <371270000.1065136442@ijir> -----BEGIN PGP SIGNED MESSAGE----- It seems to me that current text is fine so long as we don't want to rekey the HIP keys along with ESP. It seems to me that the rekey procedure should do ESP only, since there is a way if we really want to to rekey HIP (simulate loss of state, i.e. increment the birthday and send an I2). Anything else will create races with respect to packet reordering in the network. In a fast mobility situation, this will happen and could very easily result in losing contact unnecessarily. I don't see a large security benefit to rekeying HIP anyway, since in most cases the number of messages protected will be fairly small by comparison to the number of ESP payloads. Comments? Andrew - --On Wednesday, October 01, 2003 11:34:18 AM +0300 Pekka Nikander wrote: > Since we added the HMAC parameter, we now need separate > integrity and encryption keys in the HIP SAs. To facilitate > this, -08-pre defines the HIP transform crypto parameters > differently from -07 > > Please read the revised sections, and send your comments > to the list. This time I am not quite happy with the > text; I'm afraid there are corner cases (e.g. with NES) > that haven't been really worked out. > > The relevant sections: > > 6.3.4 HIP_TRANSFORM > 6.3.5 ESP_TRANSFORM > 9. HIP KEYMAT > > URLs for easy reading: > > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#anch > or32 > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Sep24.html#keym > at > > --Pekka Nikander > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP3yxOlGmVIGYWzvRAQEozwP/ZumdKfaq1m+Nbju3iQOHX2lzHxy4Jngc RhV++hJhTLDAqEvNtgGtk54r5mx1l+qyNQtssRoK7tHHLnEQSEj+yKHly6/vdEDu 2A053JuYGkHraZHECWfmsQeJ3MYrbt12o9znmB8uzBsoGjp2UArUuCqwgYSPH9XS 8Jl2GYXT1yw= =2DFV -----END PGP SIGNATURE----- From andrew@indranet.co.nz Thu Oct 2 19:49:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Oct 2 18:49:00 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B30@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B30@xch-nw-27.nw.nos.boein g.com> Message-ID: <376310000.1065136584@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Wednesday, October 01, 2003 09:22:24 AM -0700 "Henderson, Thomas R" wrote: >> >> The question is now: Shall we try base our interop tests >> (and possible BOF demos) in Minneapolis on -07 or -08? >> >> Personally I would prefer -08, even if it would require some >> more work from us. However, if nobody else has time to update >> their implementation to -08, we would be happy with -07, too. >> Our current code is (mostly) based on -07. >> > Considering that there is a push to take -08 forward in the > near future, I think it would be wise to try to achieve > interoperability on the basis of that draft. I agree. I suspect I will have my hands full just getting up to -08, so I probably won't get mobility working any better. -08 does give us a workable rekey procedure, so we are still increasing the interoperability coverage. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP3yxyFGmVIGYWzvRAQE31AP/SikKZci/OtDK3Ug+/EHiZgr55hRlW0Q1 24x7jfmAarCYr9reS8a0ID6EGAGNfT6Vr72SCjzvJ+cn+MWTpiLRmObkGEIZGh4n e1t6uB8/bP29qOiajKBsDMhw2b7ezKcd/uaCU3RVE5RB07svuSH5CiltBFFTiYuO cBJa+JFEFdY= =RIxC -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Fri Oct 3 03:06:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 3 02:06:01 2003 Subject: [Hipsec] Closing issue #4/12: Adding HMAC to R2 In-Reply-To: <363000000.1065128472@ijir> References: <3F7A9040.1040704@nomadiclab.com> <363000000.1065128472@ijir> Message-ID: <3F7D183A.8010209@nomadiclab.com> Andrew McGregor wrote: > This looks good. We may wish to add to the note on the signature > processing something along these lines: > > Signature the signature is calculated over the HIP packet, > excluding the HIP_SIGNATURE TLV field, but including the > HMAC field if present. > ... > > and similarly for HIP_SIGNATURE_2. Ok, added. Thanks for the comment! --Pekka >> In -08-pre, we have added HMAC to the R2 to plug >> a potential R1/R2 replay attack. ... >> The relevant sections are: >> >> 6.3.9 HMAC >> 7.4 R2 - the second HIP responder packet >> 8.7 Processing incoming R2 packets From pekka.nikander@nomadiclab.com Fri Oct 3 03:16:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 3 02:16:01 2003 Subject: [Hipsec] Closing issue 14: New state E4 In-Reply-To: <367290000.1065129103@ijir> References: <3F7A90E2.3080708@nomadiclab.com> <367290000.1065129103@ijir> Message-ID: <3F7D1A9A.4070209@nomadiclab.com> Andrew, > Looks good. Actually, E4 is spread around all the processing, not just on > incoming I2. This change does remove the rekey race (I can make the race > happen in practice with the old rules, the window can be as much as a > couple of seconds). Thanks for the comment! I must have been half asleep when sending the original closing message. Yes, E4 is spread around all the processing. --Pekka >> In -08-pre, there is a new state E4 in the state machine. >> It is used in the E3 state if the host receives an I2 >> with a proper birthday. >> >> The relevant sections are: >> >> 5.4 HIP State Machine >> 8.6 Processing incoming I2 packets From pekka.nikander@nomadiclab.com Fri Oct 3 03:26:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 3 02:26:02 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <371270000.1065136442@ijir> References: <3F7A918A.5080902@nomadiclab.com> <371270000.1065136442@ijir> Message-ID: <3F7D1CD9.2090209@nomadiclab.com> Andrew McGregor wrote: > It seems to me that current text is fine so long as we don't want to rekey > the HIP keys along with ESP. > > It seems to me that the rekey procedure should do ESP only, since there is > a way if we really want to to rekey HIP (simulate loss of state, i.e. > increment the birthday and send an I2). Anything else will create races > with respect to packet reordering in the network. In a fast mobility > situation, this will happen and could very easily result in losing contact > unnecessarily. I don't see a large security benefit to rekeying HIP > anyway, since in most cases the number of messages protected will be fairly > small by comparison to the number of ESP payloads. Agreed. Now, what shall we do with KEYMAT? I have currently written the text so that the first bytes of the new KEYMAT would be thrown away, corresponding to the non-used new HIP keys. Is that what we want, or would it be better to draw the new ESP keys from the beginning of KEYMAT? Basically, the question is of what is simpler from the implementation point of view. Since I have not been involved in writing the crypto parts of our implementation, I don't know, and can't have any good opinion. --Pekka From Julien.Laganier@Sun.COM Fri Oct 3 04:50:02 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 3 03:50:02 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis In-Reply-To: <3F7AB147.3060306@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> Message-ID: <200310031017.02040.julien.laganier@sun.com> On Wednesday 01 October 2003 12:49, Pekka Nikander wrote: > I have placed now a new set of -08-pre versions on my > web site: > > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.xml > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.txt > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01.html > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-diff.html > http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-pre-Oct01-chbar.txt Hi Folks, I am a bit confused by the parameter encryption process. While having to encrypt a parameter in TLV format, this parameter is aligned on a 64 bits boundary. But while using a block cipher whose block size is greater than 64 bits (e.g., 128 bits for AES), additional padding might be needed while encrypting. So are we supposed to: (i) let the encryption routines (like openssl's ones) add padding to the parameter? OR (ii) pad ourself the parameter TLV up to the nearest block size boundary, so that no additional padding is needed? I am guessing that the two above are functionnaly equivalent, but I'm not sure. Perhaps we can further clarify section 6.2.15 ENCRYPTED with something like: If necessary, an implementation MUST append any TLV parameter that is to be encrypted with an additional padding, so that the length of the resulting cleartext is a multiple of the cipher block size length. Or is this clear for everybody except me ? ;-) Thanks, --julien From andrew@indranet.co.nz Fri Oct 3 08:42:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Fri Oct 3 07:42:01 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <3F7D1CD9.2090209@nomadiclab.com> References: <3F7A918A.5080902@nomadiclab.com> <371270000.1065136442@ijir> <3F7D1CD9.2090209@nomadiclab.com> Message-ID: <406990000.1065182935@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Friday, October 03, 2003 09:53:13 AM +0300 Pekka Nikander wrote: > Now, what shall we do with KEYMAT? I have currently written the > text so that the first bytes of the new KEYMAT would be thrown > away, corresponding to the non-used new HIP keys. Is that what > we want, or would it be better to draw the new ESP keys from > the beginning of KEYMAT? > > Basically, the question is of what is simpler from the implementation > point of view. Since I have not been involved in writing the > crypto parts of our implementation, I don't know, and can't have any > good opinion. Six of one, half a dozen of the other. Throwing away the first keys drawn may take a few more cycles (will for me), but may mean less code for some implementations. Logically, KEYMAT is a stream and we should just draw from the beginning, is my opinion. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP31m2lGmVIGYWzvRAQHMNgP/a5fPR7HDT/0hO/s46gPuPnRrA4R9HQtj 2tJ4wFv3Tfvvf8LHU7jXwTc0814vrdvwOK5Lo9oNaIss2Uh+9sT2XuD6470Nujp2 aOsCJWbYIX1VSBWg9h2RNc1o8AjbUhiOoLbAdY6q5Uxc1Sn3Wt075p8tdyz7kV4i uAi173xj7kU= =aRUZ -----END PGP SIGNATURE----- From Julien.Laganier@Sun.COM Fri Oct 3 09:05:06 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 3 08:05:06 2003 Subject: [Hipsec] Issue on IV ? In-Reply-To: <3F7A8E6F.5000500@nomadiclab.com> References: <3F5C7FA9.8070609@nomadiclab.com> <3F7A8E6F.5000500@nomadiclab.com> Message-ID: <200310031432.41145.julien.laganier@sun.com> Folks, It seems that draft-moskowitz-hip indicate an IV length of 64 bits (original text at the end of the mail). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But while using AES_128_CBC, isn't the IV length 128 bits long? Perhaps the IV field should be 128 bits long? Or use a variable length field, using the HIP_TRANSFORM suite_id to infer it. So have either: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IV | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / Encrypted data / / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What do you think? --julien -------------------------------------------------------------------------------------------------------- Original text ------------- 6.3.12 ENCRYPTED 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted data / / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 20 Length length in octets, excluding T and L fields Reserved zero when sent, ignored when received IV Initialization vector, if needed, zero otherwise Encrypted the data is encrypted using an encryption algorithm as data defined in HIP transform From Julien.Laganier@Sun.COM Fri Oct 3 09:14:00 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 3 08:14:00 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <3F7D1CD9.2090209@nomadiclab.com> References: <3F7A918A.5080902@nomadiclab.com> <371270000.1065136442@ijir> <3F7D1CD9.2090209@nomadiclab.com> Message-ID: <200310031440.48885.julien.laganier@sun.com> On Friday 03 October 2003 08:53, Pekka Nikander wrote: > > Now, what shall we do with KEYMAT? I have currently written the > text so that the first bytes of the new KEYMAT would be thrown > away, corresponding to the non-used new HIP keys. Is that what > we want, or would it be better to draw the new ESP keys from > the beginning of KEYMAT? Pekka, AFAICS, the only point in favor of throwing away the non-used HIP keys might be to make legacy implementations compatible with an hypothetical future usage of the HIP keys; otherwise I can't imagine what simplification goal would be achieved by throwing them, nor what would be the usefullness of rekeying HIP. Thanks, --julien From pekka.nikander@nomadiclab.com Mon Oct 6 02:50:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 01:50:01 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <200310031440.48885.julien.laganier@sun.com> References: <3F7A918A.5080902@nomadiclab.com> <371270000.1065136442@ijir> <3F7D1CD9.2090209@nomadiclab.com> <200310031440.48885.julien.laganier@sun.com> Message-ID: <3F810917.8090403@nomadiclab.com> Thanks for your input, Andrew and Julien! Andrew McGregor wrote: > Six of one, half a dozen of the other. Throwing away the first keys drawn > may take a few more cycles (will for me), but may mean less code for some > implementations. Logically, KEYMAT is a stream and we should just draw > from the beginning, is my opinion. Julien Laganier wrote: > AFAICS, the only point in favor of throwing away the non-used HIP keys might > be to make legacy implementations compatible with an hypothetical future > usage of the HIP keys; otherwise I can't imagine what simplification goal > would be achieved by throwing them, nor what would be the usefullness of > rekeying HIP. The consensus seems to be that we draw the new ESP keys from the beginning of the new KEYMAT. I have fixed the draft. Unless there are any other problems here, the issue is now closed. (Which, of course, doesn't mean that it can't be reopened if needed, or that we can't create new issues. I just will not consider this any more for getting -08 out.) --Pekka From pekka.nikander@nomadiclab.com Mon Oct 6 02:54:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 01:54:03 2003 Subject: [Hipsec] Issue 19: Issue on IV In-Reply-To: <200310031432.41145.julien.laganier@sun.com> References: <3F5C7FA9.8070609@nomadiclab.com> <3F7A8E6F.5000500@nomadiclab.com> <200310031432.41145.julien.laganier@sun.com> Message-ID: <3F810A13.4090807@nomadiclab.com> Julien Laganier wrote: > It seems that draft-moskowitz-hip indicate an IV length of 64 bits (original > text at the end of the mail). So it does. > But while using AES_128_CBC, isn't the IV length 128 bits long? I have to confess that I don't know. > Perhaps the IV field should be 128 bits long? Or use a variable length field, > using the HIP_TRANSFORM suite_id to infer it. Using a variable length field, the length being inferred from the HIP_TRANSFORM suite, sounds OK to me. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IV / > / / > / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / > / Encrypted data / > / | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Looks good. > What do you think? Opinions, others? Petri, I think you did the original ENCRYPTED format used in the current draft. Do you remember the rationale back then? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 6 02:57:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 01:57:02 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <200310031017.02040.julien.laganier@sun.com> References: <3F7AB147.3060306@nomadiclab.com> <200310031017.02040.julien.laganier@sun.com> Message-ID: <3F810AC1.90409@nomadiclab.com> Julien Laganier wrote: > I am a bit confused by the parameter encryption process. > > While having to encrypt a parameter in TLV format, this parameter is aligned > on a 64 bits boundary. But while using a block cipher whose block size is > greater than 64 bits (e.g., 128 bits for AES), additional padding might be > needed while encrypting. So are we supposed to: > > (i) let the encryption routines (like openssl's ones) add padding to the > parameter? > > OR > > (ii) pad ourself the parameter TLV up to the nearest block size boundary, so > that no additional padding is needed? > > I am guessing that the two above are functionnaly equivalent, but I'm not > sure. > > Perhaps we can further clarify section 6.2.15 ENCRYPTED with something like: > > If necessary, an implementation MUST append any TLV parameter that is to be > encrypted with an additional padding, so that the length of the resulting > cleartext is a multiple of the cipher block size length. > > Or is this clear for everybody except me ? ;-) This goes beyond my expertese. Hence, I am willing to put into the draft whatever you folks think is good. The text proposed by Julien sounds good to me. Do we accept it? Any opinions or alternatives? --Pekka Nikander From andrew@indranet.co.nz Mon Oct 6 06:41:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Oct 6 05:41:01 2003 Subject: [Hipsec] Issue 19: Issue on IV In-Reply-To: <3F810A13.4090807@nomadiclab.com> References: <3F5C7FA9.8070609@nomadiclab.com> <3F7A8E6F.5000500@nomadiclab.com> <200310031432.41145.julien.laganier@sun.com> <3F810A13.4090807@nomadiclab.com> Message-ID: <486820000.1065434876@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Monday, October 06, 2003 09:22:11 AM +0300 Pekka Nikander wrote: > Julien Laganier wrote: > >> It seems that draft-moskowitz-hip indicate an IV length of 64 bits >> (original text at the end of the mail). > > So it does. > >> But while using AES_128_CBC, isn't the IV length 128 bits long? > > I have to confess that I don't know. In CBC modes, the IV is always one cipher block, therefore it is 128 bits for AES-CBC (with any key length). > >> Perhaps the IV field should be 128 bits long? Or use a variable length >> field, using the HIP_TRANSFORM suite_id to infer it. > > Using a variable length field, the length being inferred from > the HIP_TRANSFORM suite, sounds OK to me. This is the right thing, since cipher blocks and IVs are not required to be any particular size, but will always be uniquely determined by the selected suite (if not, we didn't specify the suite well enough). > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IV / >> / / >> / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / >> / Encrypted data / >> / | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Looks good. > >> What do you think? > > Opinions, others? Petri, I think you did the original ENCRYPTED > format used in the current draft. Do you remember the rationale > back then? I vaguely recall an older draft actually stating that the IV field was intended to be the correct size for the cipher (it can hardly be anything else, after all). Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP4E+/1GmVIGYWzvRAQE0TAP/aEhS9vJJHLRwvWMfHzpJ8XUqX8VQyA57 c8PW8j0KqDMZExI46YAg6uqXr98WZHgkMmDAZ/P+9lJlAUJwayTwMBqT/AG0nzi2 x0bN+sEIM0FC0qtb+D3lohLVRVT/9X9F5/8lShkc9x7EnzrsgvBZNqFR5ZFvB4S1 OjYTX5zmzB4= =IZPO -----END PGP SIGNATURE----- From andrew@indranet.co.nz Mon Oct 6 06:46:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Oct 6 05:46:01 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <3F810AC1.90409@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> <200310031017.02040.julien.laganier@sun.com> <3F810AC1.90409@nomadiclab.com> Message-ID: <490700000.1065435252@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Monday, October 06, 2003 09:25:05 AM +0300 Pekka Nikander wrote: > Julien Laganier wrote: >> I am a bit confused by the parameter encryption process. >> >> While having to encrypt a parameter in TLV format, this parameter is >> aligned on a 64 bits boundary. But while using a block cipher whose >> block size is greater than 64 bits (e.g., 128 bits for AES), additional >> padding might be needed while encrypting. So are we supposed to: >> >> (i) let the encryption routines (like openssl's ones) add padding to the >> parameter? >> >> OR >> >> (ii) pad ourself the parameter TLV up to the nearest block size >> boundary, so that no additional padding is needed? >> >> I am guessing that the two above are functionnaly equivalent, but I'm >> not sure. They are indeed functionally equivalent from an implementation point of view, but HIP should specify that padding must exist (and it's cleaner to supply the encryption routines with known correct padding). >> Perhaps we can further clarify section 6.2.15 ENCRYPTED with something >> like: >> >> If necessary, an implementation MUST append any TLV parameter that is >> to be encrypted with an additional padding, so that the length of >> the resulting cleartext is a multiple of the cipher block size >> length. >> >> Or is this clear for everybody except me ? ;-) > > This goes beyond my expertese. Hence, I am willing to put into the > draft whatever you folks think is good. The text proposed by Julien > sounds good to me. > > Do we accept it? Any opinions or alternatives? I suspect we should adopt the same sort of wording as RFC2406 section 2.4, which specifies this for ESP (as a matter of interest, my code does exactly this). Yes, it's quite wordy, but as you will see, it covers all the bases. Andrew - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP4FAd1GmVIGYWzvRAQGrTQP9GIGAjYlX5QFu/OmoyQV7j66vFuMy3XU1 TaiGr2vWSa6sm+fW4Gl7YcwEKiBxzQeKAj5quryYbD1o0mMsyGLUQF+QwLmV+jEF ba1TcWND//pqZfZr3r7lxzaxNsHbYcHuTsCVE9XIfu2JID0iWpZFxOvXq2J/JXGi mM07J4w0kyM= =hDa5 -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Mon Oct 6 07:18:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 06:18:00 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <490700000.1065435252@ijir> References: <3F7AB147.3060306@nomadiclab.com> <200310031017.02040.julien.laganier@sun.com> <3F810AC1.90409@nomadiclab.com> <490700000.1065435252@ijir> Message-ID: <3F8147F0.9000706@nomadiclab.com> Andrew McGregor wrote: > I suspect we should adopt the same sort of wording as RFC2406 section > 2.4, which specifies this for ESP (as a matter of interest, my code > does exactly this). Yes, it's quite wordy, but as you will see, it > covers all the bases. > How about the following text, based on Julien's suggestion: If the data to be encrypted is not a multiple of the encryption algorithm block size, thereby necessitating padding, and if the encryption algorithm does not specify the padding contents, then an implementation MUST append the TLV parameter that is to be encrypted with an additional padding, so that the length of the resulting cleartext is a multiple of the cipher block size length. Such a padding MUST be constructed as specified in [RFC2406] Section 2.4. On the other hand, if the data to be encrypted is already a multiple of the block size, or if the encryption algorithm does specify padding as per [RFC2406] Section 2.4, then additional padding SHOULD NOT be added. The Length field in the inside, to be encrypted TLV does not include the padding. The Length field in the outside, ENCRYPTED TLV includes all encrypted bytes, and thereby it conceptually covers also the padding. The ENCRYPTED payload may contain additional padding, if the result of encryption, the TLV header and the IV is not a multiple of 8 bytes. The contents of this padding MUST follow the rules given in Section "TLV format". Ok? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 6 07:23:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 06:23:00 2003 Subject: [Hipsec] Closing Issue 19: Issue on IV In-Reply-To: <486820000.1065434876@ijir> References: <3F5C7FA9.8070609@nomadiclab.com> <3F7A8E6F.5000500@nomadiclab.com> <200310031432.41145.julien.laganier@sun.com> <3F810A13.4090807@nomadiclab.com> <486820000.1065434876@ijir> Message-ID: <3F814905.5060108@nomadiclab.com> Andrew McGregor wrote: >>> Perhaps the IV field should be 128 bits long? Or use a variable length >>> field, using the HIP_TRANSFORM suite_id to infer it. >> >> Using a variable length field, the length being inferred from >> the HIP_TRANSFORM suite, sounds OK to me. > > This is the right thing, since cipher blocks and IVs are not required to be > any particular size, but will always be uniquely determined by the selected > suite (if not, we didn't specify the suite well enough). > ... > I vaguely recall an older draft actually stating that the IV field was > intended to be the correct size for the cipher (it can hardly be anything > else, after all). I changed the text to make the IV a variable length field, and non-existing if the encryption algorithm does not need an IV. Issue closed. --Pekka Nikander From Julien.Laganier@Sun.COM Mon Oct 6 07:48:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 6 06:48:01 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <3F8147F0.9000706@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> <490700000.1065435252@ijir> <3F8147F0.9000706@nomadiclab.com> Message-ID: <200310061315.40307.julien.laganier@sun.com> On Monday 06 October 2003 12:46, Pekka Nikander wrote: > Andrew McGregor wrote: > > I suspect we should adopt the same sort of wording as RFC2406 section > > 2.4, which specifies this for ESP (as a matter of interest, my code > > does exactly this). Yes, it's quite wordy, but as you will see, it > > covers all the bases. > > How about the following text, based on Julien's suggestion: > > If the data to be encrypted is not a multiple of the encryption > algorithm block size, thereby necessitating padding, and if the > encryption algorithm does not specify the padding contents, then > an implementation MUST append the TLV parameter that is to be > encrypted with an additional padding, so that the length of the > resulting cleartext is a multiple of the cipher block size > length. Such a padding MUST be constructed as specified in > [RFC2406] Section 2.4. On the other hand, if the data to be > encrypted is already a multiple of the block size, or if the > encryption algorithm does specify padding as per [RFC2406] > Section 2.4, then additional padding SHOULD NOT be added. > > The Length field in the inside, to be encrypted TLV does not > include the padding. The Length field in the outside, ENCRYPTED > TLV includes all encrypted bytes, and thereby it conceptually > covers also the padding. > > The ENCRYPTED payload may contain additional padding, if the > result of encryption, the TLV header and the IV is not a multiple > of 8 bytes. The contents of this padding MUST follow the rules > given in Section "TLV format". > > Ok? Pekka, The new text seems fine to me; Perhaps only rewording the first sentence in: > If the encryption algorithm requires the length of the data to be > encrypted to be multiple of the encryption algorithm block size ... instead of > If the data to be encrypted is not a multiple of the encryption > algorithm block size ... Thanks, --julien From mkousa@cc.hut.fi Mon Oct 6 08:11:00 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Mon Oct 6 07:11:00 2003 Subject: [Hipsec] New Issue 17: Need example checksums as an appendix In-Reply-To: <3F780366.1060702@nomadiclab.com> References: <3F780366.1060702@nomadiclab.com> Message-ID: On Mon, 29 Sep 2003, Pekka Nikander wrote: -> Tom reminded me that HIP checksums have been a very -> hard part to get right in the past. Hence, we need -> to have checksum examples in an appendix. More specifically, -> we need to have at least the following examples: -> -> ... -> - a simple HIP packet carried over IPv6 (an I1, for example) Configuration used: Initiator: IPv6 address 2001:db8::1, HIT 4000::1 Responder: IPv6 address 2001:db8::2, HIT 4000::2 tcpdump (with HIP patch) shows: 14:17:27.021589 2001:db8::1 > 2001:db8::2: HIP 4000::1 > 4000::2: len=4,type=1,ver_res=0x10,control=0x0,checksum=59367 I1 (len 40, hlim 255) Dump of the whole IPv6 packet: 0x0000 6000 0000 0028 63ff 2001 0db8 0000 0000 0x0010 0000 0000 0000 0001 2001 0db8 0000 0000 0x0020 0000 0000 0000 0002 3b04 0110 0000 e7e7 0x0030 4000 0000 0000 0000 0000 0000 0000 0001 0x0040 4000 0000 0000 0000 0000 0000 0000 0002 -- printk(KERN_ERR "happy meal: Transceiver BigMac ATTACK!"); -- linux/drivers/net/sunhme.c From mkomu@niksula.hut.fi Mon Oct 6 08:21:01 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Mon Oct 6 07:21:01 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis In-Reply-To: <376310000.1065136584@ijir> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B30@xch-nw-27.nw.nos.boein g.com> <376310000.1065136584@ijir> Message-ID: On Fri, 3 Oct 2003, Andrew McGregor wrote: > >> The question is now: Shall we try base our interop tests > >> (and possible BOF demos) in Minneapolis on -07 or -08? > >> > >> Personally I would prefer -08, even if it would require some > >> more work from us. However, if nobody else has time to update > >> their implementation to -08, we would be happy with -07, too. > >> Our current code is (mostly) based on -07. > >> > > Considering that there is a push to take -08 forward in the > > near future, I think it would be wise to try to achieve > > interoperability on the basis of that draft. > > I agree. I suspect I will have my hands full just getting up to -08, so I > probably won't get mobility working any better. -08 does give us a > workable rekey procedure, so we are still increasing the interoperability > coverage. We will also update our implementation to the 08 draft. Our implementation supports mobility and multihoming in an experimental level. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 6 08:25:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 07:25:01 2003 Subject: [Hipsec] Issue 21: Forced ESP sending upon receiving a reply NES Message-ID: <3F81578F.4090201@nomadiclab.com> I added the following paragraph towards the end of Section 8.9.2, Processing a reply NES packet: 5. If the system has no data to send for 500ms, it SHOULD send an ESP packet anyway. The purpose of this packet is to acknowledge the other party that the NES reply came through, and to allow the other party to switch over to the new outgoing SA. It is RECOMMENDED that the system sends an empty ESP packet, i.e., one where the Next Header field is IPPROTO_NONE (decimal 59). A SHOULD instead of a MUST since this can be hard to implement in some systems. OK to everybody? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 6 08:28:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 6 07:28:00 2003 Subject: [Hipsec] Closing Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <200310061314.55570.julien.laganier@sun.com> References: <3F7AB147.3060306@nomadiclab.com> <490700000.1065435252@ijir> <3F8147F0.9000706@nomadiclab.com> <200310061314.55570.julien.laganier@sun.com> Message-ID: <3F815848.1060108@nomadiclab.com> >>How about the following text, based on Julien's suggestion: >> >> If the data to be encrypted is not a multiple of the encryption >> algorithm block size, thereby necessitating padding, and if the >> encryption algorithm does not specify the padding contents, then >> an implementation MUST append the TLV parameter that is to be >> encrypted with an additional padding, so that the length of the >> resulting cleartext is a multiple of the cipher block size >> length. Such a padding MUST be constructed as specified in >> [RFC2406] Section 2.4. On the other hand, if the data to be >> encrypted is already a multiple of the block size, or if the >> encryption algorithm does specify padding as per [RFC2406] >> Section 2.4, then additional padding SHOULD NOT be added. >> >> The Length field in the inside, to be encrypted TLV does not >> include the padding. The Length field in the outside, ENCRYPTED >> TLV includes all encrypted bytes, and thereby it conceptually >> covers also the padding. >> >> The ENCRYPTED payload may contain additional padding, if the >> result of encryption, the TLV header and the IV is not a multiple >> of 8 bytes. The contents of this padding MUST follow the rules >> given in Section "TLV format". Julien Laganier wrote: > The new text seems fine to me; Perhaps only rewording the first sentence in: > > If the encryption algorithm requires the length of the data to be > encrypted to be multiple of the encryption algorithm block size ... > > instead of > >> If the data to be encrypted is not a multiple of the encryption >> algorithm block size ... Ok, I placed the text to the draft. I think this issue is now closed. --Pekka Nikander From andrew@indranet.co.nz Mon Oct 6 16:36:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Mon Oct 6 15:36:01 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <3F8147F0.9000706@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> <200310031017.02040.julien.laganier@sun.com> <3F810AC1.90409@nomadiclab.com> <490700000.1065435252@ijir> <3F8147F0.9000706@nomadiclab.com> Message-ID: <496130000.1065470625@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Monday, October 06, 2003 01:46:08 PM +0300 Pekka Nikander wrote: > Andrew McGregor wrote: >> I suspect we should adopt the same sort of wording as RFC2406 section >> 2.4, which specifies this for ESP (as a matter of interest, my code >> does exactly this). Yes, it's quite wordy, but as you will see, it >> covers all the bases. >> > > How about the following text, based on Julien's suggestion: > > If the data to be encrypted is not a multiple of the encryption > algorithm block size, thereby necessitating padding, and if the > encryption algorithm does not specify the padding contents, then > an implementation MUST append the TLV parameter that is to be > encrypted with an additional padding, so that the length of the > resulting cleartext is a multiple of the cipher block size > length. Such a padding MUST be constructed as specified in > [RFC2406] Section 2.4. On the other hand, if the data to be > encrypted is already a multiple of the block size, or if the > encryption algorithm does specify padding as per [RFC2406] > Section 2.4, then additional padding SHOULD NOT be added. > > The Length field in the inside, to be encrypted TLV does not > include the padding. The Length field in the outside, ENCRYPTED > TLV includes all encrypted bytes, and thereby it conceptually > covers also the padding. 'The Length field in the outside ENCRYPTED TLV is the length of the data after encryption (including padding and any other output from the encryption process specified for that suite).' It needs to say this since there are algorithms which change the length, independant of padding, and we may have a compressed suite one day. > > The ENCRYPTED payload may contain additional padding, if the > result of encryption, the TLV header and the IV is not a multiple > of 8 bytes. The contents of this padding MUST follow the rules > given in Section "TLV format". > > Ok? > > --Pekka Nikander > > - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP4HKpFGmVIGYWzvRAQHi/wQAoGveuH18ntm8uHdFcdZuNn9X99yEOziU yOTSLPrdUc60OksW8bTUUfFGprRKhdIuiquUu3LQ7c3EA0FzUz5MiqJ1RwPRAF0Y Feh7CHuvul7yeX1GNGMJTh1GJZUUpviZin0PEREqUrVf2adXu6k1s/XETv2u24rK 71RORbkwVbU= =6Opd -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Tue Oct 7 03:36:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 7 02:36:00 2003 Subject: [Hipsec] Issue 20: Padding of ENCRYPTED TLV In-Reply-To: <496130000.1065470625@ijir> References: <3F7AB147.3060306@nomadiclab.com> <200310031017.02040.julien.laganier@sun.com> <3F810AC1.90409@nomadiclab.com> <490700000.1065435252@ijir> <3F8147F0.9000706@nomadiclab.com> <496130000.1065470625@ijir> Message-ID: <3F826173.1000708@nomadiclab.com> >> The Length field in the inside, to be encrypted TLV does not >> include the padding. The Length field in the outside, ENCRYPTED >> TLV includes all encrypted bytes, and thereby it conceptually >> covers also the padding. > > 'The Length field in the outside ENCRYPTED TLV is the length of the data > after encryption (including padding and any other output from the > encryption process specified for that suite).' > > It needs to say this since there are algorithms which change the length, > independant of padding, and we may have a compressed suite one day. Thanks, Andrew! I changed the text so that it now reads as follows. The Length field in the inside, to be encrypted TLV does not include the padding. The Length field in the outside ENCRYPTED TLV is the length of the data after encryption (including the Reserved field, the IV field, and the output from the encryption process specified for that suite, but not any external padding). Note that the length of the cipher suite output may be smaller or larger than the length of the data to be encrypted, since the encryption process may compress the data or add additional padding to the data. --Pekka From Julien.Laganier@Sun.COM Tue Oct 7 06:00:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Oct 7 05:00:01 2003 Subject: [Hipsec] Unifying SIGNATURE and HMAC processing ? In-Reply-To: <3F826173.1000708@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> <496130000.1065470625@ijir> <3F826173.1000708@nomadiclab.com> Message-ID: <200310071127.16788.julien.laganier@sun.com> Hi Folks, While reading the draft, it appears to me that the header length calculation of HMAC differs from the SIGNATURE's one: The HMAC is computed over the header including the HMAC TLV (with HMAC field zeroed) parameter, while the SIGNATURE is computed over the header excluding the SIGNATURE TLV parameter. It's OK because the HMAC TLV has a fixed length. Perhaps it might be good to have similar rules for the two, i.e. computing a given authenticator (being either HMAC or SIGNATURE) over the packet without actually appending it to the packet. This would requires to rewrite sender/receiver HMAC processing using the SIGNATURE text: Packet sender: 1. Create the HIP packet without the HMAC and possibly following HIP_SIGNATURE or HIP_SIGNATURE2 TLVs. 2. Calculate the length field in the HIP header. 3. Compute the HMAC. 4. Add the HMAC TLV to the packet. 5. Recalculate the length field in the HIP header. Packet receiver: 1. Verify the HIP header length field. 2. Save the contents of the HIP_HMAC TLV and remove it from the packet. If the packet contains any HIP_SIGNATURE or HIP_SIGNATURE2 fields, remove them as well, saving the contents if they will be needed later. Recalculate the HIP packet length in the HIP header. 3. Extract the HMAC value from its field. 4. Clear the checksum field (set it to all zeros) in the HIP header. 5. Compute the HMAC and verify it against the received HMAC. What do you folks think? Thanks, --julien From andrew@indranet.co.nz Tue Oct 7 06:57:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Tue Oct 7 05:57:01 2003 Subject: [Hipsec] Unifying SIGNATURE and HMAC processing ? In-Reply-To: <200310071127.16788.julien.laganier@sun.com> References: <3F7AB147.3060306@nomadiclab.com> <496130000.1065470625@ijir> <3F826173.1000708@nomadiclab.com> <200310071127.16788.julien.laganier@sun.com> Message-ID: <525470000.1065522301@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Tuesday, October 07, 2003 11:27:16 AM +0200 Julien Laganier wrote: > Hi Folks, > > While reading the draft, it appears to me that the header length > calculation of HMAC differs from the SIGNATURE's one: The HMAC is > computed over the header including the HMAC TLV (with HMAC field zeroed) > parameter, while the SIGNATURE is computed over the header excluding the > SIGNATURE TLV parameter. It's OK because the HMAC TLV has a fixed length. > > Perhaps it might be good to have similar rules for the two, i.e. > computing a given authenticator (being either HMAC or SIGNATURE) over > the packet without actually appending it to the packet. > What do you folks think? I think it's an excellent idea. I had not noticed the difference last time I read the draft, but I would have suggested this if I had :-) - -------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet.co.nz/ Office: +64 3 3656485 Mobile: +64 21 898856 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP4KUfVGmVIGYWzvRAQFkrQP/e8Jotmpu0Cd1G2M3K1BvSdJ9eHA7Yc1m FBpiIJIvv0dFmNMA7+Em0aPKSY2IZRXqgF/XdBNLvAqipa2gQGEKm78mJGZgB5HN voV822GFhMf63svnwCUpFs47C9MVGByA6TMm+YEwiIq23JgfOsde5+X1DHP4Me+C Wjkk7nKmprQ= =sh8t -----END PGP SIGNATURE----- From thomas.r.henderson@boeing.com Tue Oct 7 22:40:02 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Oct 7 21:40:02 2003 Subject: [Hipsec] example checksums Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B9C@xch-nw-27.nw.nos.boeing.com> Here are some examples that I came up with based on our checksumming=20 code. These are for HIP I1 packets only-- not for TCP/UDP. - IPv4 I1=20 - IPv4 I1 using alternate UDP format - IPv6 I1 I'm happy to share the test program I used to generate these, but I'm interested in some other people independently verifying these. I used the same v4 addresses in v6 (works out to same checksums) but could easily generate other v6 addresses if desired. src IP addresss: 192.0.2.1 (or ::FFFF:192.0.2.1) dst IP address: 192.0.2.2 (or ::FFFF:192.0.2.2) sender's HIT: 4000::1 receiver's HIT: 4000::2=20 IP protocol: 99 (decimal) HIP controls: 0 HIP packet: I1 IPv4 I1 with pseudoheader (first 12 bytes) and corresponding checksum: c0000201 c0000202 00630028 3b040110 000058bf 40000000 00000000 00000000 00000001 40000000 00000000 00000000 00000002 IPv4 UDP I1 with pseudoheader (first 12 bytes) and corresponding = checksum: c0000201 c0000202 0063002c 01100110 002c0cf8 00000110 40000000 00000000 00000000 00000001 40000000 00000000 00000000 00000002 IPv6 I1 with pseudoheader (first 40 bytes) and corresponding checksum: 00000000 00000000 0000ffff c0000201 00000000 00000000 0000ffff c0000202 00000028 00000063 3b040110 000058bf 40000000 00000000 00000000 00000001 40000000 00000000 00000000 00000002 From mkousa@cc.hut.fi Wed Oct 8 10:02:00 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Oct 8 09:02:00 2003 Subject: [Hipsec] example checksums In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B9C@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5B9C@xch-nw-27.nw.nos.boeing.com> Message-ID: On Tue, 7 Oct 2003, Henderson, Thomas R wrote: -> Here are some examples that I came up with based on our checksumming -> code. These are for HIP I1 packets only-- not for TCP/UDP. -> - IPv4 I1 -> - IPv4 I1 using alternate UDP format -> - IPv6 I1 -> ... We (HIPL) can currently calculate the checksum only for IPv6 I1. Using the same test data our checksumming code gets the same (0x58bf) checksum as your code. -- "Real programmers don't comment their code. It was hard to write, it should be hard to understand." From pekka.nikander@nomadiclab.com Wed Oct 8 10:46:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 09:46:00 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies Message-ID: <3F841B9B.5060306@nomadiclab.com> Tom Henderson (thanks Tom) has privately raised the question on how we should interpret the HIP exchange wrt. IPsec SAs. He writes: > The state machine currently seems to permit at most one HIP > association/SA between two given host identities. ... > Is this an intentional restriction? I don't know enough > about current IPsec policy rules to answer that question > (whether you might want multiple SAs between hosts). My personal opinion is that yes, this is intentional. In theory, one could have multiple parallel SAs between a pair of HITs, and then use e.g. ports to make the choice of which SA to use. However, HIP lacks the ability to negotiate the required policies. I would suppose that the right way of having several parallel SAs for policy purposes would be to define an extension to HIP, allowing the required policy negotiation. The only restriction would be that all the SAs share the same KEYMAT. If there is a need to have several sets of KEYMAT between a pair of two hosts, there would need to be several HITs, in parallel. My suggestion is that we move the current Section 11 of the base protocol draft, > 11. ESP with HIP > > HIP sets up a pair of Security Associations (SA) to enable ESP in an > end-to-end manner that can span addressing realms (i.e. across NATs). > ... to the architecture draft, and modify it appropriately. The section is already now architectural in nature, and doesn't really add anything to the actual base protocol specification. Almost all of the issues in the section have been explained elsewhere, too, and the few that haven't can be easily moved to better locations, e.g. into Section 8. Packet processing. Once the section is moved, I could add a new subsection explaining the issue with policies, and the possibility of new extensions that allow policy negotiation. Opinions? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 8 11:00:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:00:01 2003 Subject: [Hipsec] Issue 22: NES ID Initialization and conceptual state Message-ID: <3F841EE7.1040504@nomadiclab.com> Tom Hendersson (thanks!) writes privately: > What is NES ID initialized to? I suppose it a "don't care" but maybe > should be specified as such? I think it is best to initialize the NES ID counter to zero. This allows the peers to keep track of the NES packets they have received, and to easily reject replayed ones. I propose the following modifications: Section 6.2.14 NES_INFO Old text: NES ID Packet identifier. Used to tie NES packets into pairs. New text NES ID Packet identifier. Used to tie NES packets into pairs. Initialized to zero and incremented for each NES. Section 7.5 NES Old text: The NES packet is a HIP packet with NES_INFO and optional DIFFIE_HELLMAN and in the HIP payload. The NES_INFO parameter contains the old and new SPI values. It also contains a packet ID and HMAC to provide DoS and replay protection. New text: The NES packet is a HIP packet with NES_INFO and optional DIFFIE_HELLMAN and in the HIP payload. The NES_INFO parameter contains the old and new SPI values. It also contains a NES ID and HMAC to provide DoS and replay protection. Each system must have a NES ID counter, initialized to zero and incremented on each NES. Section 8.5 Processing incoming R1 packets Addition of a new step between steps 13 and 14: 13'. The system initialized the remaining variables in the associated state, including NES ID counters. Section 8.6 Processing incoming I2 packets Addition of a new step between steps 17 and 18: 17'. The system initialized the remaining variables in the associated state, including NES ID counters. Ok to everyone? A related issue: Should we have a section describing the variables in the conceptual HIP state, created per HIP connection? I think one would be good. It would be great if someone could send some raw text for that. --Pekka Nikander From jari.arkko@piuha.net Wed Oct 8 11:01:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Oct 8 10:01:01 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3F841B9B.5060306@nomadiclab.com> References: <3F841B9B.5060306@nomadiclab.com> Message-ID: <3F841E3E.7080606@piuha.net> Pekka Nikander wrote: > Tom Henderson (thanks Tom) has privately raised the question > on how we should interpret the HIP exchange wrt. IPsec SAs. > He writes: > >> The state machine currently seems to permit at most one HIP >> association/SA between two given host identities. ... >> Is this an intentional restriction? I don't know enough >> about current IPsec policy rules to answer that question >> (whether you might want multiple SAs between hosts). > > > My personal opinion is that yes, this is intentional. > In theory, one could have multiple parallel SAs between > a pair of HITs, and then use e.g. ports to make the > choice of which SA to use. However, HIP lacks the > ability to negotiate the required policies. > > I would suppose that the right way of having several > parallel SAs for policy purposes would be to define an > extension to HIP, allowing the required policy negotiation. > The only restriction would be that all the SAs share the > same KEYMAT. If there is a need to have several sets of > KEYMAT between a pair of two hosts, there would need to > be several HITs, in parallel. In IPsec, I believe, the multiple SA pairs between two hosts can appear for three reasons: 1) Policy is different per flow, e.g., per port. 2) Colliding negotiations may result in two SA pairs for the same purpose. That is, when both parties initiate at the same time, they would normally both succeed and result in different SAs. 3) Re-key can result in parallelly existing SAs for the same purpose, at least for a short period of time. For #1, I think we should avoid having such a policy. No policy is good policy, and simplies the usage of the system. But how are #2 and #3 handled in HIP? What happens if two hosts initiate at the same time? --Jari From pekka.nikander@nomadiclab.com Wed Oct 8 11:10:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:10:03 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3F841E3E.7080606@piuha.net> References: <3F841B9B.5060306@nomadiclab.com> <3F841E3E.7080606@piuha.net> Message-ID: <3F84216E.9000108@nomadiclab.com> Jari Arkko wrote: > In IPsec, I believe, the multiple SA pairs between two > hosts can appear for three reasons: > > 1) Policy is different per flow, e.g., per port. > > 2) Colliding negotiations may result in two SA pairs > for the same purpose. That is, when both parties > initiate at the same time, they would normally both > succeed and result in different SAs. > > 3) Re-key can result in parallelly existing > SAs for the same purpose, at least for a short > period of time. > > For #1, I think we should avoid having such a policy. Agreed. If someone wants to have some per port policy, they can define a HIP extension for that. > But how are #2 and #3 handled in HIP? > What happens if two hosts initiate at the same time? The state machine has been designed in such a way that if two hosts initiate at the same time, it should result in only one state and one pair of SAs. However, I think that it has never been tested in practise. I think that Kimmo Nieminen has been doing some simulations on the state machines. Kimmo, do you remember the results of this from your simulations? With regard to re-keying, I have tried to design the NES procedure so that it will always lead to replacing the SAs in rough synchrony, even if both ends initiate re-keying at the same time. However, I think that nobody has studied what happens in practise, i.e., there may be packet sequences that I haven't considered. For natural, reasons there must exist two incoming SAs for a brief period of time, but there should always be only one active outgoing SA. The situation becomes more complicated when multi-homing is introduced, but that is a subject for another thread. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 8 11:19:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:19:01 2003 Subject: [Hipsec] Arch Issue #2: Editorial comments from Tom Hendersson Message-ID: <3F84235C.3060304@nomadiclab.com> Tom has sent the following editorial comments. I agree with them, and will apply them unless someone objects or has better suggestions. Section 5.1 Old text: HIP need not rely on Dynamic DNS for this function, but uses a rendezvous server New text: Although Dynamic DNS could be used for this function for infrequently moving nodes, an alternative to using DNS in this fashion is to use a piece of static infrastructure called a HIP rendezvous server. Section 8.1, question 6: Old text: It is possible to use HIP opportunistically, without any infrastructure. However, to gain full benefit from HIP, the Host Identifiers must be stored in the DNS, ... New text: It is possible to use HIP opportunistically, without any infrastructure. However, to gain full benefit from HIP, the Host Identifiers must be stored in the DNS or a PKI, ... (the phrase "or a PKI" was added) Section 9, paragraph 3: Old text: HIP both allows to increase the cost... New text: HIP allows a responder to increase the cost... --Pekka Nikander From shep@alum.mit.edu Wed Oct 8 11:21:01 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Oct 8 10:21:01 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: Your message of Wed, 08 Oct 2003 17:13:47 +0300. <3F841B9B.5060306@nomadiclab.com> Message-ID: <200310081448.h98EmlWB028600@ginger.lcs.mit.edu> While I could be convinced otherwise, I think leaving HIP with the limitation of only supporting a single pair of security associations (one in each direction) is OK becasue host identities can be created as needed. If multiple IPSEC security association pairs are needed between the same computers, they can do it using multiple identities. Identities in HIP can be created as needed and can be ephemeral. If an application using one of these ephemeral identities needs to tie it to some other longer-term identity, I suppose it could do so. But I expect in many situations, either the single security association pair between identities will be sufficient, or if a single security association is not enough, ephemeral use-once-and-forget identities will be sufficient. Any other situation will be complicated enough that the overhead of having to explicitly handle multiple HIP identities and tie them together at the application layer (perhaps by one issuing a certificate for the other) will not be a big deal. Perhaps it would have been better to take what we call a host identity and name it something that doesn't have the word host in it. We could imagine using identities in HIP that are identified with particular services that remain tied with the services and not the hosts that they are implemented on, or even identities that are associated with individual users. But changing the name now is probably not worth it, and the one-to-one mapping between computers and HIP identities will probably be a very common case. -Tim Shepard shep@alum.mit.edu From jari.arkko@piuha.net Wed Oct 8 11:22:04 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Oct 8 10:22:04 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3F84216E.9000108@nomadiclab.com> References: <3F841B9B.5060306@nomadiclab.com> <3F841E3E.7080606@piuha.net> <3F84216E.9000108@nomadiclab.com> Message-ID: <3F84233E.8030205@piuha.net> Pekka Nikander wrote: > Jari Arkko wrote: > >> In IPsec, I believe, the multiple SA pairs between two >> hosts can appear for three reasons: >> >> 1) Policy is different per flow, e.g., per port. >> >> 2) Colliding negotiations may result in two SA pairs >> for the same purpose. That is, when both parties >> initiate at the same time, they would normally both >> succeed and result in different SAs. >> >> 3) Re-key can result in parallelly existing >> SAs for the same purpose, at least for a short >> period of time. >> >> For #1, I think we should avoid having such a policy. > > > Agreed. If someone wants to have some per port policy, > they can define a HIP extension for that. > >> But how are #2 and #3 handled in HIP? >> What happens if two hosts initiate at the same time? > > > The state machine has been designed in such a way that > if two hosts initiate at the same time, it should > result in only one state and one pair of SAs. However, > I think that it has never been tested in practise. > > I think that Kimmo Nieminen has been doing some simulations > on the state machines. Kimmo, do you remember the results > of this from your simulations? A simple (?) state exploration of two machines running together should expose such bugs, if any? Has anyone done that? > With regard to re-keying, I have tried to design the > NES procedure so that it will always lead to replacing > the SAs in rough synchrony, even if both ends initiate > re-keying at the same time. However, I think that nobody > has studied what happens in practise, i.e., there may be > packet sequences that I haven't considered. For natural, > reasons there must exist two incoming SAs for a brief > period of time, but there should always be only one active > outgoing SA. Yes, that's the thing. There may be packets in flight even if you succeed in making a synchronous change at the peers. But when you say there can be two incoming SAs for a brief period of time, how exactly do we handle that if we don't allow more than one SA pair between two HITs? > The situation becomes more complicated when multi-homing > is introduced, but that is a subject for another thread. Interesting. --Jari From pekka.nikander@nomadiclab.com Wed Oct 8 11:32:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:32:00 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3F84233E.8030205@piuha.net> References: <3F841B9B.5060306@nomadiclab.com> <3F841E3E.7080606@piuha.net> <3F84216E.9000108@nomadiclab.com> <3F84233E.8030205@piuha.net> Message-ID: <3F842669.9080102@nomadiclab.com> [A side note: I completely agree with what Tim wrote in his message. The current architecture draft RECOMMENDS that hosts do have multiple identities.] Pekka Nikander wrote: >>... For natural, >> reasons there must exist two incoming SAs for a brief >> period of time, but there should always be only one active >> outgoing SA. Jari Arkko wrote: > Yes, that's the thing. There may be packets in flight > even if you succeed in making a synchronous change at the > peers. But when you say there can be two incoming SAs > for a brief period of time, how exactly do we handle that > if we don't allow more than one SA pair between two HITs? Well, the restriction is a *conceptual* one. During the re-keying transition, there are two incarnations of the same SA. One is the old one and the other one is the new one. In the IPsec level, these two SAs are most probably two completely separate SAs, and IPsec doesn't have any idea that they actually "represent" the same conceptual SA at the HIP level. --Pekka Nikander From swb@employees.org Wed Oct 8 11:36:01 2003 From: swb@employees.org (Scott W Brim) Date: Wed Oct 8 10:36:01 2003 Subject: [Hipsec] Arch Issue #2: Editorial comments from Tom Hendersson In-Reply-To: <3F84235C.3060304@nomadiclab.com>; from pekka.nikander@nomadiclab.com on Wed, Oct 08, 2003 at 05:46:52PM +0300 References: <3F84235C.3060304@nomadiclab.com> Message-ID: <20031008110352.D2492@sbrim-w2k01> Much better all around imho. ...Scott From pekka.nikander@nomadiclab.com Wed Oct 8 11:38:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:38:01 2003 Subject: [Hipsec] Issue 23: New substate to handle ICMP attacks Message-ID: <3F8427F8.3020504@nomadiclab.com> As a part of his arch doc review, Tom Henderson writes: > - in reading Section 9, it reminded me that we probably want yet > another state to linger after ICMP messages (wait for a while to see > if legitimate R1 comes in before dropping back to E0). In my opinion, we most probably do not want to complicate the conceptual state machine with such an additional state. (The implementations are free to add such a state, of course). Instead, I suggest that we add a new section before the current Section 8.5, Processing incoming R1 packets. Here is a proposal for the text:
A host may receive an ICMP Destination Protocol Unreachable message as a response to sending an HIP I1 packet. Such a packet may be an indication that the peer does not support HIP, or it may be an attempt to launch an attack by making the Initiator to believe that the Responder does not support HIP. When a system receives an ICMP Destination Protocol Unreachable message while it is waiting for an R1, it MUST NOT terminate the wait. It MAY continue as if it had not received the ICMP message, and send a few more I1s. Alternatively, it MAY take the ICMP message as a hint that the peer most probably does not support HIP, and return to state E0 earlier than otherwise. However, at minimum, it MUST continue waiting for an R1 for a reasonable time before returning to E0.
Is this OK? --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 8 11:50:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 10:50:01 2003 Subject: [Hipsec] Issue 24: Unifying SIGNATURE and HMAC processing ? In-Reply-To: <525470000.1065522301@ijir> References: <3F7AB147.3060306@nomadiclab.com> <496130000.1065470625@ijir> <3F826173.1000708@nomadiclab.com> <200310071127.16788.julien.laganier@sun.com> <525470000.1065522301@ijir> Message-ID: <3F842AB0.1040702@nomadiclab.com> >> While reading the draft, it appears to me that the header length >> calculation of HMAC differs from the SIGNATURE's one: The HMAC is >> computed over the header including the HMAC TLV (with HMAC field zeroed) >> parameter, while the SIGNATURE is computed over the header excluding the >> SIGNATURE TLV parameter. It's OK because the HMAC TLV has a fixed length. >> >> Perhaps it might be good to have similar rules for the two, i.e. >> computing a given authenticator (being either HMAC or SIGNATURE) over >> the packet without actually appending it to the packet. > > > >> What do you folks think? > > I think it's an excellent idea. I had not noticed the difference last time > I read the draft, but I would have suggested this if I had :-) I'm giving this Issue number 24. I will close this in a couple of days, as per your suggestion, unless there is more discussion that warrants otherwise. --Pekka Nikander From pekka.nikander@nomadiclab.com Wed Oct 8 12:17:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 8 11:17:00 2003 Subject: [Hipsec] A web page for issues Message-ID: <3F8430FC.1060706@nomadiclab.com> I'm starting to have difficulties in keeping track of all the issues, and therefore I created a simple web page, mainly to help myself. (Do not take this as a complain -- I think the ongoing discussion and issue resolving is very valuable.) The web page is available at http://www.tml.hut.fi/~pnr/HIP/issues.html I'll probably add a fourth column (the resolution), but I don't have time for it right now. --Pekka Nikander From mkousa@cc.hut.fi Wed Oct 8 12:30:02 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Oct 8 11:30:02 2003 Subject: [Hipsec] Issue 23: New substate to handle ICMP attacks In-Reply-To: <3F8427F8.3020504@nomadiclab.com> References: <3F8427F8.3020504@nomadiclab.com> Message-ID: On Wed, 8 Oct 2003, Pekka Nikander wrote: -> Here is a proposal for the text: -> ->
-> -> .... -> -> When a system receives an ICMP Destination Protocol -> Unreachable message while it is waiting for an R1, it MUST NOT -> terminate the wait. It MAY continue as if it had not received -> the ICMP message, and send a few more I1s. Alternatively, it -> MAY take the ICMP message as a hint that the peer most -> probably does not support HIP, and return to state E0 earlier -> than otherwise. However, at minimum, it MUST continue waiting -> for an R1 for a reasonable time before returning to E0. -> ->
-> -> Is this OK? Looks good to me. I think we need not to define the exact maximum waiting time in the text because the needed waiting time depends on many issues such as RTT and such. So, the interpretation of "a reasonable time" can be left implementation specific. From kimmo.nieminen@tut.fi Wed Oct 8 13:56:00 2003 From: kimmo.nieminen@tut.fi (Kimmo Nieminen) Date: Wed Oct 8 12:56:00 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3F84216E.9000108@nomadiclab.com> References: <3F841B9B.5060306@nomadiclab.com> <3F841E3E.7080606@piuha.net> <3F84216E.9000108@nomadiclab.com> Message-ID: > The state machine has been designed in such a way that > if two hosts initiate at the same time, it should > result in only one state and one pair of SAs. However, > I think that it has never been tested in practise. > > I think that Kimmo Nieminen has been doing some simulations > on the state machines. Kimmo, do you remember the results > of this from your simulations? I have been simulating the state machines, but unfortunately I cannot help you with this thing. The tool (http://www.cs.tut.fi/ohj/VARG/TVT/) which I used was not able to handle such a huge state space even though the level of abstraction was rather high. By using partial parallel composition, the problem could possibly be solved, but that is quite complicated. I had modelled all the basic state machine features but I had to limit the model so that only one host can act as an initiator and the other has to be the responder. Even at this case, the state space included more than 100 000 states in some cases... Actually, this was the biggest restriction in my work. Otherwise, based on my simulations the protocol seemed to be working well. -- kimmo.nieminen@tut.fi www.kimmo.nieminen.org From thomas.r.henderson@boeing.com Wed Oct 8 15:22:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 8 14:22:00 2003 Subject: [Hipsec] example checksums Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5BAB@xch-nw-27.nw.nos.boeing.com> One other minor nit about the checksums is that it is inaccurate to describe them as CRCs. I suggest a global change in the draft -08: "CRC" -> "checksum" =20 From pekka.nikander@nomadiclab.com Thu Oct 9 02:15:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 9 01:15:01 2003 Subject: [Hipsec] example checksums In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C026B5BAB@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C026B5BAB@xch-nw-27.nw.nos.boeing.com> Message-ID: <3F84EB89.3020900@nomadiclab.com> Henderson, Thomas R wrote: > One other minor nit about the checksums is that it is inaccurate to > describe them as CRCs. I suggest a global change in the draft -08: > "CRC" -> "checksum" Ok, fixed. (No need to open a numbered issue on this, I think.) --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 9 02:49:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 9 01:49:00 2003 Subject: [Hipsec] Arch Issue #3: Clarifying the role of HITs in ACLs Message-ID: <3F84FD82.4070805@nomadiclab.com> Yet another excellent issue from Tom Henderson: In Section 9.1, the draft currently states the following: It is expected that HITs will be used in ACLs. Future firewalls can use HITs to control egress and ingress to networks, with an assurance difficult to achieve today. However, it doesn't describe how one can snoop the initial base exchange, and subsequent NES packets, and keep track of the SPI values. This has lead some people to have a desire to to have HITs explicitly in every packet. While this is possible if one uses the optional PAYLOAD packet type, using the PAYLOAD imposes unnecessary header overhead. As we have discusses earlier, it is possible to snoop the HIP exchanges to find SPIs and IP addresses, and use those as indirect handles to the HIT. One can also at that time authenticate the senders of the HIP messages based on their signatures, if desired. Hence, perhaps the first paragraph should be clarified to describe how firewalls use HITs when the HITs are not present in every packet. I am still thinking about whether it might be more convenient to optionally expose HITs in a packet. -------------- Personally, I agree with Tom, and I think we should add new text. I also think that this is related to Arch Issue #1; we really should explain better in the arch document how HIP uses ESP. Assuming that we move the ESP section over from the base spec (Section 11) to the arch doc (before current Section 9), here is my proposal for the new text to be placed in 9.1: It is expected that HITs will be used in ACLs. Future firewalls can use HITs to control egress and ingress to networks, with an assurance difficult to achieve today. As discussed above in , once a HIP session has been established, the SPI value in an ESP packet may be used as an index, indicating the HITs. In practise, the firewalls can inspect the HIP packets and learn the SPI values from there. They can even explicitly control ESP usage, opening ESP only for specific SPI values and IP addresses. The signatures in the HIP packets allow a capable firewall to make sure that the HIP exchange is indeed happening between two known hosts. This may increase firewall security. Ok? Better wording anyone? --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 9 05:14:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 9 04:14:00 2003 Subject: [Hipsec] Closing issue 17: Unifying crypto suites for HIP and ESP SAs In-Reply-To: <3F7A918A.5080902@nomadiclab.com> References: <3F7A918A.5080902@nomadiclab.com> Message-ID: <3F851F58.2070805@nomadiclab.com> Pekka Nikander wrote: > Since we added the HMAC parameter, we now need separate > integrity and encryption keys in the HIP SAs. To facilitate > this, -08-pre defines the HIP transform crypto parameters > differently from -07 > The relevant sections: > > 6.3.4 HIP_TRANSFORM > 6.3.5 ESP_TRANSFORM > 9. HIP KEYMAT One more minor nit: In 6.3.4, the max number of transforms is three. In 6.3.5, the max number of transforms is six. Fixed now so that it is six (6) in both cases. (Yes, we implemented this today, cutting again our line count :-) --Pekka Nikander From mkousa@cc.hut.fi Thu Oct 9 05:33:00 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Oct 9 04:33:00 2003 Subject: [Hipsec] Web page for HIP checksum calculation Message-ID: Now that there is discussion about example checksums, I made a web page (http://kludge.tky.hut.fi/~mika/csum.cgi) for quick testing of HIP checksum calculation. Currently we support only IPv6, and I1 packet is used. Given src/dst IPv6/HIT addresses, the page shows the checksum value what our (HIPL) current implementation calculates. -- "Do not underestimate the value of print statements for debugging." From thomas.r.henderson@boeing.com Thu Oct 9 11:14:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 9 10:14:01 2003 Subject: [Hipsec] RE: Arch Issue #3: Clarifying the role of HITs in ACLs Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5BBD@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Wednesday, October 08, 2003 11:18 PM > To: hipsec@honor.trusecure.com > Cc: Henderson, Thomas R > Subject: Arch Issue #3: Clarifying the role of HITs in ACLs >=20 >=20 > Assuming that we move the ESP section over from > the base spec (Section 11) to the arch doc (before > current Section 9), here is my proposal for the > new text to be placed in 9.1: >=20 > It is expected that HITs will be used in ACLs. Future > firewalls can use HITs to control egress and ingress to > networks, with an assurance difficult to achieve today. As > discussed above in , once a HIP = session > has been established, the SPI value in an ESP packet may be > used as an index, indicating the HITs. In practise, the > firewalls can inspect the HIP packets and learn the=20 > SPI values > from there. They can even explicitly control ESP usage, > opening ESP only for specific SPI values and IP addresses. > The signatures in the HIP packets allow a capable firewall to > make sure that the HIP exchange is indeed happening between > two known hosts. This may increase firewall security. >=20 > Ok? Better wording anyone? >=20 > I suggest changing one of the middle sentences to: "In practise, the firewalls can inspect the HIP packets to learn of the bindings between HITs, SPI values, and IP addresses."=20 Otherwise, this is what I had in mind. Thanks, Tom From pekka.nikander@nomadiclab.com Thu Oct 9 15:16:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 9 14:16:00 2003 Subject: [Hipsec] Arch Issue #4: The document does not explain IPsec usage Message-ID: <3F85AC95.9060102@nomadiclab.com> The current architecture document doesn't really explain how HIP uses IPsec to protect the actual payload traffic. This may lead a new reader to complete confusion. Proposal: Add the following text to the end of the Introduction section. When HIP is used, the actual payload traffic between two HIP hosts is typically protected with IPsec. HIP Host Identifiers are used to create the needed IPsec Security Associations (SA) and to authenticate the hosts. The actual payload IP packets do not differ in any way from standard IPsec protected IP packets. Additionally, a number of occasions where the document talks about ESP, it is apparently better to talk about IPsec in general. That is, architecturally there is not so much difference between in some of the places. I've placed a snapshot on my web site. It is easiest to see the changes from the diff document: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct09-diff.html Below is also a diff. --Pekka Nikander *** draft-moskowitz-hip-arch-05.xml.~1.3.~ Thu Oct 9 09:15:44 2003 --- draft-moskowitz-hip-arch-05.xml Thu Oct 9 21:32:26 2003 *************** *** 96,101 **** --- 96,108 ---- multi-homing and dynamic IP renumbering, aid in protocol translation / transition, and greatly reduce denial of service (DoS) attacks. + + When HIP is used, the actual payload traffic between two HIP + hosts is typically protected with IPsec. HIP Host Identifiers + are used to create the needed IPsec Security Associations (SA) + and to authenticate the hosts. The actual payload IP packets do + not differ in any way from standard IPsec protected IP + packets.
*************** *** 453,467 **** When a node moves while communication is already on-going, address changes are rather straightforward. The peer of the ! mobile node can just accept a HIP or an ESP packet from any ! address and totally ignore the source address. As discussed in ! below, a mobile node must send a ! HIP readdress packet to inform the peer of the new address(es), ! and the peer must verify that the new mobile node is reachable ! through these addresses. This is especially helpful for those ! situations where the peer node is sending data periodically to ! the mobile node (that is re-starting a connection after the ! initial connection).
--- 460,474 ---- When a node moves while communication is already on-going, address changes are rather straightforward. The peer of the ! mobile node can just accept a HIP or an integrity protected ! IPsec packet from any address and totally ignore the source ! address. As discussed in below, ! a mobile node must send a HIP readdress packet to inform the ! peer of the new address(es), and the peer must verify that the ! new mobile node is reachable through these addresses. This is ! especially helpful for those situations where the peer node is ! sending data periodically to the mobile node (that is ! re-starting a connection after the initial connection).
*************** *** 557,569 **** may be changed freely during packet traversal. For a HIP based flow, a NAT or NAT-PT system needs only track ! the mapping of the HIT or SPI to an IP address. Many HITs can ! map to a single IP address on a NAT, simplifying connections on ! address poor NAT interfaces. The NAT can gain much of its ! knowledge from the HIP packets themselves; however some NAT ! configuration may be necessary. ! The NAT systems cannot touch the datagrams within the ESP envelope, thus application specific address translation must be done in the end systems. HIP provides for 'Distributed NAT', and uses the HIT or the LSI as a place holder for embedded IP --- 564,576 ---- may be changed freely during packet traversal. For a HIP based flow, a NAT or NAT-PT system needs only track ! the mapping of the HIT or IPsec Security Parameter Index (SPI) to ! an IP address. Many HITs can map to a single IP address on a ! NAT, simplifying connections on address poor NAT interfaces. ! The NAT can gain much of its knowledge from the HIP packets ! themselves; however some NAT configuration may be necessary. ! The NAT systems cannot touch the datagrams within the IPsec envelope, thus application specific address translation must be done in the end systems. HIP provides for 'Distributed NAT', and uses the HIT or the LSI as a place holder for embedded IP *************** *** 817,837 **** HIP takes advantage of the new Host Identity paradigm to provide secure authentication of hosts and provide a fast key ! exchange for IPsec ESP. HIP also attempts to limit the exposure of the host to various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. In so doing, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual. ! The Security Association for ESP is indexed by the SPI; the source address is always ignored, and the destination address ! may be ignored as well. Therefore, HIP enabled ESP is IP ! address independent. This might seem to make it easier for an ! attacker, but ESP with replay protection is already as well ! protected as possible, and the removal of the IP address as a ! check should not increase the exposure of ESP to DoS ! attacks. Denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to --- 824,844 ---- HIP takes advantage of the new Host Identity paradigm to provide secure authentication of hosts and provide a fast key ! exchange for IPsec. HIP also attempts to limit the exposure of the host to various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. In so doing, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual. ! The Security Association for IPsec is indexed by the SPI; the source address is always ignored, and the destination address ! may be ignored as well. Therefore, HIP enabled IPsec ! Encapsulated Security Payload (ESP) is IP address independent. ! This might seem to make it easier for an attacker, but ESP with ! replay protection is already as well protected as possible, and ! the removal of the IP address as a check should not increase the ! exposure of IPsec ESP to DoS attacks. Denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to *************** *** 898,912 **** It is expected that HITs will be used in ACLs. Future firewalls can use HITs to control egress and ingress to networks, with an assurance difficult to achieve today. As ! discussed above in , once a HIP session ! has been established, the SPI value in an ESP packet may be used as an index, indicating the HITs. In practise, the ! firewalls can inspect the HIP packets and learn the SPI values ! from there. They can even explicitly control ESP usage, ! opening ESP only for specific SPI values and IP addresses. ! The signatures in the HIP packets allow a capable firewall to ! make sure that the HIP exchange is indeed happening between ! two known hosts. This may increase firewall security. --- 905,920 ---- It is expected that HITs will be used in ACLs. Future firewalls can use HITs to control egress and ingress to networks, with an assurance difficult to achieve today. As ! discussed above in , once a HIP session ! has been established, the SPI value in an IPsec packet may be used as an index, indicating the HITs. In practise, the ! firewalls can inspect the HIP packets to learn of the bindings ! between HITs, SPI values, and IP addresses. They can even ! explicitly control IPsec usage, opening IPsec ESP only for ! specific SPI values and IP addresses. The signatures in the ! HIP packets allow a capable firewall to make sure that the HIP ! exchange is indeed happening between two known hosts. This ! may increase firewall security. From jari.arkko@piuha.net Thu Oct 9 15:39:01 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu Oct 9 14:39:01 2003 Subject: [Hipsec] Arch Issue #4: The document does not explain IPsec usage In-Reply-To: <3F85AC95.9060102@nomadiclab.com> References: <3F85AC95.9060102@nomadiclab.com> Message-ID: <3F85B0E3.406@piuha.net> Pekka Nikander wrote: > The current architecture document doesn't really > explain how HIP uses IPsec to protect the actual > payload traffic. This may lead a new reader to > complete confusion. > > Proposal: Add the following text to the end of > the Introduction section. > > When HIP is used, the actual payload traffic between two HIP > hosts is typically protected with IPsec. HIP Host Identifiers Wouldn't the draft be more specific if it said instead "is protected with IPsec"? > are used to create the needed IPsec Security Associations (SA) > and to authenticate the hosts. The actual payload IP packets do > not differ in any way from standard IPsec protected IP > packets. > > Additionally, a number of occasions where the document > talks about ESP, it is apparently better to talk about > IPsec in general. That is, architecturally there is Hmm... if you talk about ESP then its again more specific, less room for interpretation, less options, less interoperability problems...? --Jari From pekka.nikander@nomadiclab.com Fri Oct 10 03:40:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 10 02:40:01 2003 Subject: [Hipsec] [Fwd: I-D ACTION:draft-nikander-esp-beet-mode-00.txt] Message-ID: <3F865AFB.9060502@nomadiclab.com> This is a multi-part message in MIME format. --------------090405080304030201080700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This draft proposes some small modifications to ESP. It would allow a completely user level HIP implementation, without needing any changes to the ESP. The drawback is that the same functionality can be implemented with standard transport mode ESP and a separate hostNAT. There is some discussion about that in the draft. Personally, I do believe that an integrated method, described in the draft, would be much better than relying on a separate ESP and hostNAT implementations. The draft has been proposed as a starting point in the proposed hip wg charter. I expect strong opposition from a number of IPsec WG members, including Steven Kent. Hence, if you think that BEET is a good idea, you may want to wield your harness and prepare to defend the idea at the IPsec WG mailing list, as long as the WG exists. --Pekka Nikander --------------090405080304030201080700 Content-Type: message/rfc822; name="[Mip6] I-D ACTION:draft-nikander-esp-beet-mode-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[Mip6] I-D ACTION:draft-nikander-esp-beet-mode-00.txt" X-Sieve: cmu-sieve 2.0 Return-Path: Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n97.nomadiclab.com (Postfix) with ESMTP id 060A31C for ; Thu, 9 Oct 2003 22:52:38 +0300 (EEST) Received: by n2.nomadiclab.com (Postfix) id 4BCDFCBA65; Thu, 9 Oct 2003 22:39:21 +0300 (EEST) Delivered-To: pnr@nomadiclab.com Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 33FB5CBA64; Thu, 9 Oct 2003 22:39:21 +0300 (EEST) Received: from optimus.ietf.org (unknown [132.151.6.22]) by outside.nomadiclab.com (Postfix) with ESMTP id 7DB95113E09; Thu, 9 Oct 2003 22:39:15 +0300 (EEST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcm-0002jH-No; Thu, 09 Oct 2003 15:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcT-0002is-Ej for mip6@optimus.ietf.org; Thu, 09 Oct 2003 15:38:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06648; Thu, 9 Oct 2003 15:38:29 -0400 (EDT) Message-Id: <200310091938.PAA06648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ipsec@lists.tislabs.com, multi6@ops.ietf.org, mip6@ietf.org, mip4@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 09 Oct 2003 15:38:28 -0400 Subject: [Mip6] I-D ACTION:draft-nikander-esp-beet-mode-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-9142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142307.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 --------------090405080304030201080700-- From pekka.nikander@nomadiclab.com Fri Oct 10 04:48:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 10 03:48:02 2003 Subject: [Hipsec] Arch Issue #4: The document does not explain IPsec usage In-Reply-To: <3F85B0E3.406@piuha.net> References: <3F85AC95.9060102@nomadiclab.com> <3F85B0E3.406@piuha.net> Message-ID: <3F866ABF.6090805@nomadiclab.com> Jari, Jari Arkko wrote: >> Proposal: Add the following text to the end of >> the Introduction section. >> >> When HIP is used, the actual payload traffic between two HIP >> hosts is typically protected with IPsec. HIP Host Identifiers > > Wouldn't the draft be more specific if it said instead "is protected > with IPsec"? There is a desire to make HIP to work without IPsec. In fact, we know how to do that if we could get one bit allocated in the IP header. Such practise would be fairly insecure, though, and nobody has had time to really analyze the potential consequences. Hence, nobody has not really proposed anything concrete in that arena. On the other hand, I'd like to keep the architecture spec open in this respect. That is, while HIP currently relies pretty heavily on ESP, the situation does not need to be so in the future. I'd like the architecture spec to reflect this view somehow. >> Additionally, a number of occasions where the document >> talks about ESP, it is apparently better to talk about >> IPsec in general. That is, architecturally there is > > Hmm... if you talk about ESP then its again more specific, > less room for interpretation, less options, less interoperability > problems...? Remember that this is an *architecture* document. It is desirable that architectures are open ended. It is a different case with the actual protocol spec. It should be as specific as possible, to ensure interoperability and simplicity. --Pekka From pekka.nikander@nomadiclab.com Fri Oct 10 05:00:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 10 04:00:00 2003 Subject: [Hipsec] An official HIP BOF request has been sent Message-ID: <3F866D9C.6050807@nomadiclab.com> [Apologies for cross-posting. Please trim the CC: on replies.] Folks, I sent an official BOF request for a Host Identity Protocol BOF a few moments ago. Based on the discussions with the INT area ADs, it looks fairly probable that a BOF will be scheduled. The latest version of the proposed BOF agenda is available at http://www.tml.hut.fi/~pnr/HIP/hipbof.txt The latest version of the proposed WG charter is available at http://www.tml.hut.fi/~pnr/HIP/hip_charter_proposal.txt Note to the IPsec WG: The charter proposal suggest that the new WG would specify a small addition to ESP, basing on draft-nikander-esp-beet-mode-00.txt. Folks at the IPsec WG may have strong opinions on this. The most appropiate place to discuss the BOF and charter proposals is the hipsec mailing list. See the bof agenda and/or charter proposal for details on how to join to the mailing list. The list policy requires non-member postings to be explicitly approved by the list admins. --Pekka Nikander From mcr@sandelman.ottawa.on.ca Sat Oct 11 02:07:01 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Sat Oct 11 01:07:01 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: Your message of "Wed, 08 Oct 2003 17:38:38 +0300." <3F84216E.9000108@nomadiclab.com> Message-ID: <3069.1065788933@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- In general, my suggestion is that HIP permit multiple SAs between two hosts. The key reason is people who want to do differing QoS. My opinion is that HIP will become popular in SAN. Sharing KEYMAT is okay for this. >>>>> "Pekka" == Pekka Nikander writes: >> 1) Policy is different per flow, e.g., per port. There are lots of other things other than per-port, but they may essentially be equivalent to that. Pekka> The state machine has been designed in such a way that if two Pekka> hosts initiate at the same time, it should result in only one Pekka> state and one pair of SAs. However, I think that it has never Pekka> been tested in practise. Okay, that's good. Pekka> With regard to re-keying, I have tried to design the NES procedure Pekka> so that it will always lead to replacing the SAs in rough Pekka> synchrony, even if both ends initiate re-keying at the same time. Pekka> However, I think that nobody has studied what happens in practise, Pekka> i.e., there may be packet sequences that I haven't considered. Please look at draft-spencer-ipsec-ike-implementation.txt. Expired right now, but it is in any freeswan release (ftp.xs4all.nl/pub/crypto/freeswan) in doc/ dir. I'll find a URL for you when I'm back online. oh... why not, I'll just paste the section in here. 4. Basic Keying and Rekeying 4.1. When to Create SAs As Tim Jenkins [REKEY] pointed out, there is a potential race condition in Quick Mode: a fast lightly-loaded Initiator might start using IPsec SAs very shortly after sending QM3 (the third and last message of Quick Mode), while a slow heavily-loaded Responder might not be ready to receive them until after spending a significant amount of time creating its inbound SAs. The problem is even worse if QM3 gets delayed or lost. FreeS/WAN's approach to this is what Jenkins called "Responder Pre- Setup": the Responder creates its inbound IPsec SAs before it sends QM2, so they are always ready and waiting when the Initiator sends QM3 and begins sending traffic. This approach is simple and reliable, and in our experience it interoperates with everybody. (There is potentially still a problem if FreeS/WAN is the Initiator and the Responder does not use Responder Pre-Setup, but no such problems have been seen.) The only real weakness of Responder Pre- Setup is the possibility of replay attacks, which we have eliminated by other means (see section 3.3). With this approach, the Commit Bit is useless, and we ignore it. In fact, until quite recently we discarded any IKE message containing it, and this caused surprisingly few interoperability problems; apparently it is not widely used. We have recently been persuaded Spencer & Redelmeier [Page 7] Internet Draft IKE Implementation Issues 26 Feb 2002 that simply ignoring it is preferable; preliminary experience with this indicates that the result is successful interoperation with implementations which set it. 4.2. When to Rekey To preserve connectivity for user traffic, rekeying of a connection (that is, creation of new IPsec SAs to supersede the current ones) must begin before its current IPsec SAs expire. Preferably one end should predictably start rekeying negotiations first, to avoid the extra overhead of two simultaneous negotiations, although either end should be prepared to rekey if the other does not. There is also a problem with "convoys" of keying negotiations: for example, a "hub" gateway with many IPsec connections can be inundated with rekeying negotiations exactly one connection-expiry time after it reboots, and the massive overload this induces tends to make this situation self- perpetuating, so it recurs regularly. (Convoys can also evolve gradually from initially-unsynchronized negotiations.) FreeS/WAN has the concept of a "rekeying margin", measured in seconds. If FreeS/WAN was the Initiator for the previous rekeying (or the startup, if none) of the connection, it nominally starts rekeying negotiations at expiry time minus one rekeying margin. Some random jitter is added to break up convoys: rather than starting rekeying exactly at minus one margin, it starts at a random time between minus one margin and minus two margins. (The randomness here need not be cryptographic in quality, so long as it varies over time and between hosts. We use an ordinary PRNG seeded with a few bytes from a cryptographic randomness source. The seeding mostly just ensures that the PRNG sequence is different for different hosts, even if they start up simultaneously.) If FreeS/WAN was the Responder for the previous rekeying/startup, and nothing has been heard from the previous Initiator at expiry time minus one-half the rekeying margin, FreeS/WAN will initiate rekeying negotiations. No jitter is applied; we now believe that it should be jittered, say between minus one-half margin and minus one-quarter margin. Having the Initiator lead the way is an obvious way of deciding who should speak first, since there is already an Initiator/Responder asymmetry in the connection. Moreover, our experience has been that Initiator lead gives a significantly higher probability of successful negotiation! The negotiation process itself is asymmetric, because the Initiator must make a few specific proposals which the Responder can only accept or reject, so the Initiator must try to guess where its "acceptable" region (in parameter space) might overlap with the Responder's. We have seen situations where negotiations would Spencer & Redelmeier [Page 8] Internet Draft IKE Implementation Issues 26 Feb 2002 succeed or fail depending on which end initiated them, because one end was making better guesses. Given an existing connection, we KNOW that the previous Initiator WAS able to initiate a successful negotiation, so it should (if at all possible) take the lead again. Also, the Responder should remember the Initiator's successful proposal, and start from that rather than from his own default proposals if he must take the lead; we don't currently implement this completely but plan to. FreeS/WAN defaults the rekeying margin to 9 minutes, although this can be changed by configuration. There is also a configuration option to alter the permissible range of jitter. The defaults were chosen somewhat arbitrarily, but they work extremely well and the configuration options are rarely used. 4.3. Choosing an SA Once rekeying has occurred, both old and new IPsec SAs for the connection exist, at least momentarily. FreeS/WAN accepts incoming traffic on either old or new inbound SAs, but sends outgoing traffic only on the new outbound ones. This approach appears to be significantly more robust than using the old ones until they expire, notably in cases where renegotiation has occurred because something has gone wrong on the other end. It avoids having to pay meticulous attention to the state of the other end, state which is difficult to learn reliably given the limitations of IKE. This approach has interoperated successfully with ALMOST all other implementations. The only (well-characterized) problem cases have been implementations which rely on receiving a Delete message for the old SAs to tell them to switch over to the new ones. Since delivery of Delete is unreliable, and support for Delete is optional, this reliance seems like a serious mistake. This is all the more true because Delete announces that the deletion has already occurred [ISAKMP, section 3.15], not that it is about to occur, so packets already in transit in the other direction could be lost. Delete should be used for resource cleanup, not for switchover control. (These matters are discussed further in section 5.) 4.4. Why to Rekey FreeS/WAN currently implements only time-based expiry (life in seconds), although we are working toward supporting volume-based expiry (life in kilobytes) as well. The lack of volume-based expiry has not been an interoperability problem so far. Volume-based expiry does add some minor complications. In particular, it makes explicit Delete of now-disused SAs more Spencer & Redelmeier [Page 9] Internet Draft IKE Implementation Issues 26 Feb 2002 important, because once an SA stops being used, it might not expire on its own. We believe this lacks robustness and is generally unwise, especially given the lack of a reliable Delete, and expect to use volume-based expiry only as a supplement to time-based expiry. However, Delete support (see section 5) does seem advisable for use with volume-based expiry. We do not believe that volume-based expiry alters the desirability of switching immediately to the new SAs after rekeying. Rekeying margins are normally a small fraction of the total life of an SA, so we feel there is no great need to "use it all up". 4.5. Rekeying ISAKMP SAs The above discussion has focused on rekeying for IPsec SAs, but FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs, with similar success. One issue which we have noticed, but not explicitly dealt with, is that difficulties may ensue if an IPsec-SA rekeying negotiation is in progress at the time when the relevant ISAKMP SA gets rekeyed. The IKE specification [IKE] hints, but does not actually say, that a Quick Mode negotiation should remain on a single ISAKMP SA throughout. A reasonable rekeying margin will generally prevent the old ISAKMP SA from actually expiring during a negotiation. Some attention may be needed to prevent in-progress negotiations from being switched to the new ISAKMP SA. Any attempt at pre-expiry deletion of the ISAKMP SA must be postponed until after such dangling negotiations are completed, and there should be enough delay between ISAKMP-SA rekeying and a deletion attempt to (more or less) ensure that there are no negotiation-starting packets still in transit from before the rekeying. At present, FreeS/WAN does none of this, and we don't KNOW of any resulting trouble. With normal lifetimes, the problem should be uncommon, and we speculate that an occasional disrupted negotiation simply gets retried. 4.6. Bulk Negotiation Quick Mode nominally provides for negotiating possibly-large numbers of similar but unrelated IPsec SAs simultaneously [IKE, section 9]. Nobody appears to do this. FreeS/WAN does not support it, and its absence has caused no problems. Spencer & Redelmeier [Page 10] Internet Draft IKE Implementation Issues 26 Feb 2002 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP4amBIqHRg3pndX9AQEwvQQA1/xyBu+GAh9feNBVlW+DWDrd8YRrl2Jp InxkXvIyQOaz/TDExT4XKQ8ckzOfhtG/NLhEhHYuEI43Lu+mGroxwXHc+8TdlSKy 8WcI31zE2iPu9GqJXf8O26H5c5XPLG7HZjX84hj7FG2LxCQnLCvo+69Sqeqnyy4N hwDIeuPfUio= =0nu9 -----END PGP SIGNATURE----- From Julien.Laganier@Sun.COM Mon Oct 13 03:56:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 13 02:56:01 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3069.1065788933@marajade.sandelman.ottawa.on.ca> References: <3069.1065788933@marajade.sandelman.ottawa.on.ca> Message-ID: <200310130924.40396.julien.laganier@sun.com> On Friday 10 October 2003 14:28, Michael Richardson wrote: > Pekka Nikander wrote: > > With regard to re-keying, I have tried to design the NES procedure > > so that it will always lead to replacing the SAs in rough > > synchrony, even if both ends initiate re-keying at the same time. > > However, I think that nobody has studied what happens in practise, > > i.e., there may be packet sequences that I haven't considered. > > Please look at draft-spencer-ipsec-ike-implementation.txt. Expired right > now, but it is in any freeswan release (ftp.xs4all.nl/pub/crypto/freeswan) > in doc/ dir. I'll find a URL for you when I'm back online. BTW, folks, whatever expired I-D is archived at --julien From petri.jokela@nomadiclab.com Tue Oct 14 08:37:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Tue Oct 14 07:37:01 2003 Subject: [Hipsec] Comments on architecture draft Message-ID: Hi, Some comments related to the architecture draft follows. They are more or less clarifications to the text. My text proposals may be awful, but I hope that they describe what I had in mind while writing those comments. /petri Section 3 ========= Paragraph 1 last sentence DNSSEC is a "SHOULD" implement authenticator for the Host Identity namespace. => The Host Identity namespace authentication SHOULD be implemented with DNSSEC. Paragraph 3 first sentence Too strong statement. ... a public key of a 'public key' pair makes the best Host Identifiers. => ... a public key of a 'public key' pair makes the best Host Identifiers from the current selection of possible identifiers. Not maybe with those words, but I hope it clarifies what I mean. However, maybe the rest of the paragraph makes this clarification already. Section 3.1 =========== Paragraph 2 last sentence "It the private key..." => "If the private key..." ^^ Last paragraph LSI part The advantage of the size of the LSI mentioned before there is any reference to the length of the LSI. This may be ok, but it just felt funny because the advantage was first mentioned before any knowledge about the size. "The advantage of this 32-bit long LSI over the HIT is its size; its disadvantage is its local scope." Section 3.3 =========== first paragraph Last sentence ".. presents a consistent format to the protocol..." => ".. presents a consistent format of the identity to the protocol independent of the underlying technology." Section 5.1 =========== first paragraph second sentence "... the mobile node is to start..." -> reformat the sentence (at least I read that sentence constantly in a wrong way) Section 6. ========== paragraph 3 NAT: Tracking between HIT (or SPI) and the IP address. If the NAT can allocate an external address for each of the nodes inside (IPv6 ok, IPv4, well, rarely), the NAT does require mapping only between the internal and external addresses. SPI nor HIT is not needed. I would suggest to make the paragraph less restrictive in wording. -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Thu Oct 16 14:48:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 16 13:48:01 2003 Subject: [Hipsec] Arch Issue #5: Comments on architecture draft In-Reply-To: References: Message-ID: <3F8E6FBA.6030405@nomadiclab.com> Petri, > Some comments related to the architecture draft follows. They are more > or less clarifications to the text. Thanks for these comments. Since these are minor one and haven't induced any discussion, I will simply add a new issue #5 for these, and address them in this message. I hope we can close this pretty soon. > Section 3, Paragraph 1, last sentence > > DNSSEC is a "SHOULD" implement authenticator for the Host Identity > namespace. Good catch. In fact, there is no use to use RFC2119 language in this kind of an architecture document. That was the last instance of RFC2119 language; thanks for pointing it out. I changed the text that it now reads as follows: It is expected that the Host Identifier namespace will initially be authenticated with DNSSEC and that all implementations will support DNSSEC as a minimal baseline. Ok? > Paragraph 3, first sentence > > Too strong statement. > > ... a public key of a 'public key' pair makes the best Host Identifiers. Well, this is certainly something that we could debate, and indeed should if we had a working group however. Fortunately :-), I am planning to submit the document to the IESG before a WG is formed, and therefore I revised the text so that it now reads as follows: In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifiers. Do you have an opinion on this? > Section 3.1, Paragraph 2, last sentence > > "It the private key..." => "If the private key..." Thanks, fixed. > Last paragraph, LSI part > > The advantage of the size of the LSI mentioned before there is any > reference to the length of the LSI. This may be ok, but it just felt > funny because the advantage was first mentioned before any knowledge > about the size. I moved the last sentence to the HIP section, but didn't change it. Ok? > Section 3.3, first paragraph, Last sentence > > ".. presents a consistent format to the protocol..." > => > ".. presents a consistent format of the identity to the protocol > independent of the underlying technology." Changed to Secondly, it presents the identity in a consistent format to the protocol independent of the whatever underlying technology is used. Ok? > Section 5.1, first paragraph, second sentence > > "... the mobile node is to start..." -> Changed to In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. Ok? > Section 6, paragraph 3 > > NAT: Tracking between HIT (or SPI) and the IP address. > > If the NAT can allocate an external address for each of the nodes inside > (IPv6 ok, IPv4, well, rarely), the NAT does require mapping only between > the internal and external addresses. SPI nor HIT is not needed. > > I would suggest to make the paragraph less restrictive in wording. Well, what you say is obvious to anyone who knows NATs. On the other hand, the ability to track HITs and SPIs is not. Furthermore, the paragraph ony talks about what a NAT can do (based on the protoco design), not really on what it should or must do (by protocol design). Hence, I don't see any real need to change the paragraph. Was there something particular that stroke you? --Pekka From pekka.nikander@nomadiclab.com Mon Oct 20 02:13:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 01:13:01 2003 Subject: [Hipsec] Arch Issue #1: Clarification on the role of the HIP exchange vs. ESP policies In-Reply-To: <3069.1065788933@marajade.sandelman.ottawa.on.ca> References: <3069.1065788933@marajade.sandelman.ottawa.on.ca> Message-ID: <3F9375C9.4030803@nomadiclab.com> Michael, > In general, my suggestion is that HIP permit multiple SAs between > two hosts. The key reason is people who want to do differing QoS. Well, there are at least three ways how we could do that. 1. One of the hosts can have multiple HIs. Each pair of HIs will have a different pair of SAs. That is already supported now. 2. We can extend the HIP base exchange to negotiate multiple SAs. 3. We can separately specify HIP extensions that permit multiple SAs between two hosts. Personally I am pretty reluctant to change the base exchange. I would like to keep the base exchange as simple as possible, and IMHO it is now fairly close to that ideal. Or at least it is complex enough; we shouldn't make it any more complex. Extensions for various purposes are a completely different business. For example, it looks like that the multi-homing part of the multi-homing and mobility solution will require multiple parallel SAs. > My opinion is that HIP will become popular in SAN. > Sharing KEYMAT is okay for this. If there are multiple needs that require several parallel SAs (all sharing the same KEYMAT), I think that we need to do some design and try to introduce a number of generic parameters that could be used in multiple solutions. That is, we could have a kind of "New SPI" parameter that could be used both for multi-homing and SAN QoS. Maybe the current NES_INFO fulfills that need already now? Anyway, I think that this aspect needs to be clarified in the architecture draft. So far nobody has really objected moving Section 11 from the protocol spec into of the architecture draft. Hence, I have now done that. The new version of the architecture draft is available at the following URLs. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-diff.html > Please look at draft-spencer-ipsec-ike-implementation.txt. > oh... why not, I'll just paste the section in here. I did read through the text (actually twice). Below are some comments. However, I don't think that any of this belongs to the architecture document. > 4.1. When to Create SAs > ... there is a potential race > condition in Quick Mode: a fast lightly-loaded Initiator might start > using IPsec SAs very shortly after sending QM3 (the third and last > message of Quick Mode), while a slow heavily-loaded Responder might > not be ready to receive them until after spending a significant > amount of time creating its inbound SAs. In the HIP base exchange, the Initiator computes KEYMAT and prepares the SAs before it sends I2. At this stage, the Responder doesn't even have a state -- it doesn't necessarily remember sending R1 to the Initiator. While the Initiator can and does prepare the incoming SA completely, it cannot complete the outgoing SA, since it doesn't have the Responders SPI. The Responder, on the other hand, creates both incoming and outgoing SAs as it receives I2. At this time the Initiator already has a ready-to-use incoming SA. Hence, the Responder can start sending traffic. Once the Responder has both of the SAs in place, it sends and R2 to the Initiator. That R2 carries the SPI, which allows the Initiator to complete the outgoing SA and start to use it. Obviously, the Responder has its corresponding incoming SA ready at that time. Of course, if an implementation decides to send the I2 or R2 before actually having the KEYMAT ready, then we could see this problem. Maybe there should be an appendix or some guidance in the protocol spec. Opinions? > 4.2. When to Rekey > > To preserve connectivity for user traffic, rekeying of a connection > must begin before its current IPsec SAs expire. ... FreeS/WAN has > the concept of a "rekeying margin" ... Some random jitter is added > to break up convoys... This is all interesting, but it really relates to configuration policy. Right now the architecture draft says next to nothing about policy, and the base protocol spec tries to leave all policy decisions to the actual implementations. Do you propose that we should change this, and include some discussion, perhaps in the base protocol spec? > Having the Initiator lead the way is an obvious way of deciding who > should speak first, since there is already an Initiator/Responder > asymmetry in the connection. Well, there shouldn't be any asymmetry in HIP after the base exchange. Indeed, the spec says that the systems should forget which one was the initiator and which one was the responder once the base exchange has been completed. > ... The negotiation process itself is asymmetric, because > the Initiator must make a few specific proposals which the Responder > can only accept or reject As far as I can see, there is no proposals, or no negotiation in that sense, in the HIP rekey procedure. All that a rekey does is to optionally replace the D-H KEYMAT, and in any case replace the keys in the ESP SAs. > 4.3. Choosing an SA > > Once rekeying has occurred, both old and new IPsec SAs for the > connection exist, at least momentarily. FreeS/WAN accepts incoming > traffic on either old or new inbound SAs, but sends outgoing traffic > only on the new outbound ones. This is (or at least should be) the case in HIP, too. However, I am not quite sure if the text expresses this clearly enough. I really wish that people would read the NES description, and would propose improvements. > 4.4. Why to Rekey HIP is completely open ended on when or why to rekey. The docs don't say anything specific other than that the hosts must rekey before the sequence number rolls over. > 4.5. Rekeying ISAKMP SAs As someone (Tom?) pointed out, the way a HIP SAs should be rekeyed is to simulate state loss, increment birthday, and send an I2. This will make the other end believe that the sender has lost state, makes it to generate the new KEYMAT and SAs, and send an R2. The current spec says that the old SAs should be dropped as a part of the I2 processing. Maybe this should be changed so that only the outgoing SA is dropped immediately, and that the incoming one is kept for some time. Opinions? Receiving an I2 while rekeying is going on will cause the host to immediately drop rekeying. Creating new HIP SAs implies creating new ESP SAs. Should we revise this? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 20 02:48:02 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 01:48:02 2003 Subject: [Hipsec] HIP BOF *tentatively* scheduled Message-ID: <3F937DEB.2010409@nomadiclab.com> The HIP BOF has been *tentatively* scheduled for Thursday afternoon. However, I haven't seen the official approval from the ADs yet, so it is possible that the BOF may still be cancelled. It is also more than possible that the BOF may be moved to a different slot. Indeed, this slot does not look too good -- there are a couple of potential conflicts. --Pekka Nikander DRAFT Agenda of the 58th IETF Meeting November 9-14, 2003 (As of October 17, 2003) THURSDAY, November 13, 2003 1300-1500 Afternoon Sessions I APP simple SIP for Instant Messaging ... INT hipbof Host Identity Protocol BOF OPS aaa Authentication, Authorization ... OPS entmib Entity MIB WG RTG idr Inter-Domain Routing WG SEC inch Extended Incident Handling WG TSV speechsc Speech Services Control WG From petri.jokela@nomadiclab.com Mon Oct 20 02:50:04 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Oct 20 01:50:04 2003 Subject: [Hipsec] Re: Arch Issue #5: Comments on architecture draft In-Reply-To: <3F8E6FBA.6030405@nomadiclab.com> Message-ID: On Thu, 16 Oct 2003, Pekka Nikander wrote: Hi, I think that the changes you propose are ok. The last point: > > Section 6, paragraph 3 > > > > NAT: Tracking between HIT (or SPI) and the IP address. > > > > If the NAT can allocate an external address for each of the nodes inside > > (IPv6 ok, IPv4, well, rarely), the NAT does require mapping only between > > the internal and external addresses. SPI nor HIT is not needed. > > > > I would suggest to make the paragraph less restrictive in wording. > > Well, what you say is obvious to anyone who knows NATs. On the > other hand, the ability to track HITs and SPIs is not. Furthermore, > the paragraph ony talks about what a NAT can do (based on the protoco > design), not really on what it should or must do (by protocol design). > Hence, I don't see any real need to change the paragraph. Was there > something particular that stroke you? I read it like "You have to use SPI for making the address translation.". For some reason, it looks now different :-). I suppose the text is ok. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Mon Oct 20 03:13:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 02:13:01 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR Message-ID: <3F9383CC.30809@nomadiclab.com> Folks, I am shortly planning to submit draft-moskowitz-hip-arch-05.txt directly to the RFC EDITOR to be published as an Informational RFC, as per RFC2026 Section 4.2.3. The current version of the draft is available at the URLs listed in the bottom of this message. As far as I can tell, I have taken care of all the issues that were noticed during our informal last call. I have marked Issues #2-#4 as Closed. Issues #1 and #5 are still as Proposal, since there *may* be additional discussion that needs to be closed. The planned schedule is as follows: Now: The pre-draft is available. Wait for corrections based on the version listed below. Close issues #1 and #5. Wed, Oct 22, 9am GMT+2: Submit the draft to the drafts repository. Announce the draft at ipsec, mipv6, miv4, multi6, and ietf-discuss. Wait for comments. I don't expect any substantial ones, but there may be editorial things that need to be clarified. There may also ensue discussion, but such discussion should not slow down the draft. Mon, Oct 27, morning: Submit the draft directly to the RFC Editor, CC:in the IESG. Per RFC2026 Section 4.2.3, the RFC editor will wait for two two weeks for comments, and consult the IESG. I have no idea how the IESG will react or how timely their reaction will be. However, if everything goes smoothly (which is possible but not very likely), the document might get an RFC number already during the Minneapolis meeting. The pre-draft is available at the following URLs. http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05-pre-Oct20-diff.html --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 20 03:19:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 02:19:01 2003 Subject: [Hipsec] Re: Arch Issue #5: Comments on architecture draft In-Reply-To: References: Message-ID: <3F93853D.8070201@nomadiclab.com> Petri Jokela wrote: > I think that the changes you propose are ok. > > The last point: >>>Section 6, paragraph 3 >>> >>>NAT: Tracking between HIT (or SPI) and the IP address. ... > > I read it like "You have to use SPI for making the address translation.". > For some reason, it looks now different :-). I suppose the text is ok. Ok. I have now marked the issue closed. --Pekka From pekkas@netcore.fi Mon Oct 20 03:33:01 2003 From: pekkas@netcore.fi (Pekka Savola) Date: Mon Oct 20 02:33:01 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR In-Reply-To: <3F9383CC.30809@nomadiclab.com> Message-ID: On Mon, 20 Oct 2003, Pekka Nikander wrote: > I am shortly planning to submit draft-moskowitz-hip-arch-05.txt > directly to the RFC EDITOR to be published as an Informational > RFC, as per RFC2026 Section 4.2.3. The current version of the > draft is available at the URLs listed in the bottom of this message. [...] Prior to going down that path, I should perhaps ask whether the folks have considered what is the intended outcome of this action? As the HIP protocol itself has been a bit of a moving target, I'm not 100% certain that publishing the document at this phase is really reasonable. What if there will be changes to the basic HIP operation e.g., based on the HIP BOF or otherwise? (At least the flooding attack considerations are reletively new..) The document, as an Informational RFC, could just cause more confusion than clarity (what it's publication is probably intended to achieve) if the HIP evolves somehow in the short term so that the document would need to be updated. Therefore, I'm concerned that publishing the document now might "end-run" the other work on HIP, and I'd certainly understand if the IESG (when passed on to the review from the RFC Editor) would feel the same way.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekka.nikander@nomadiclab.com Mon Oct 20 05:01:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 04:01:03 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR In-Reply-To: References: Message-ID: <3F939D14.8010201@nomadiclab.com> Pekka Savola wrote: > Prior to going down that path, I should perhaps ask whether the folks have > considered what is the intended outcome of this action? Well, for one, the RFC Editor has explicitly asked for a version of the HIP architecture document to be published, even if it would go historic soon. The second purpose is to create a stable starting point for the proposed working group. I am well aware that there are lots of people who would like to get their pet peeve to HIP. From my point of view, even discussing such pet peeves would be very premature and a completely waste of time at this point. Basically, we need to keep the HIP protocol as simple as possible for quite some time to be. Hence, one purpose of publishing the architecture document prior to creating the WG is to explicitly avoid turf wars. > As the HIP protocol itself has been a bit of a moving target, I'm not 100% > certain that publishing the document at this phase is really reasonable. Did you read the draft? The wording has changed somewhat; I have explicitly tried to make it fairly open ended so that it is able to incorporate changes to the actual protocol. Furthermore, this really is an architecture document, not the protocol document. > What if there will be changes to the basic HIP operation e.g., based on > the HIP BOF or otherwise? (At least the flooding attack considerations > are reletively new..) Honestly, I don't see any changes that would affect the architecture. In other words, if the architecture needs to be changed, that is not HIP any more. The actual protocol is a different issue. And a separate draft. > The document, as an Informational RFC, could just cause more confusion > than clarity if the HIP evolves somehow in the short term so that > the document would need to be updated. Well, the architecure has been basically stable now for over two years. The last change of any significance was a clarification on how to compute the checksums on regular data packets, and that happened in San Francisco. All the changes to the architecture have been due to implementation experience -- there has been no significant design issues in two or three years. Hence, I don't see how the formation of a WG would change the architecture so suddenly. --Pekka Nikander From pekkas@netcore.fi Mon Oct 20 05:25:01 2003 From: pekkas@netcore.fi (Pekka Savola) Date: Mon Oct 20 04:25:01 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR In-Reply-To: <3F939D14.8010201@nomadiclab.com> Message-ID: On Mon, 20 Oct 2003, Pekka Nikander wrote: > The second purpose is to create a stable starting point for the proposed > working group. [...] Hence, one purpose of publishing the architecture > document prior to creating the WG is to explicitly avoid turf wars. Agreed, as long as one realizes that blocking the work is a feature, not a bug. > > As the HIP protocol itself has been a bit of a moving target, I'm not 100% > > certain that publishing the document at this phase is really reasonable. > > Did you read the draft? The wording has changed somewhat; I have > explicitly tried to make it fairly open ended so that it is able > to incorporate changes to the actual protocol. Furthermore, this > really is an architecture document, not the protocol document. I glanced through it. It seemed pretty good to me, I just had these concerns I mentioned. > > The document, as an Informational RFC, could just cause more confusion > > than clarity if the HIP evolves somehow in the short term so that > > the document would need to be updated. > > Well, the architecure has been basically stable now for over two > years. I thought that e.g. the parts about allowing the IP address changes from about everywhere (resulting in potential flooding attacks) to a stricter model was changed rather recently? Of course, I haven't been following the work too closely.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mkomu@niksula.hut.fi Mon Oct 20 05:27:01 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Mon Oct 20 04:27:01 2003 Subject: [Hipsec] miscellaneous comments on the drafts Message-ID: Here are some miscellaneous comments on the drafts. They popped out mostly when we begun to update our implementation to be in sync with draft-08-pre. The value of SPI_LSI type is zero in draft-08-pre. I'd recommend to change this value non-zero, as zero is interpreted usually as "initialized but not used yet" in data structures in C-language. This was the most difficult type value to change in our implementation. Critical flag in section is specified as "Zero if this parameter is critical" in section 6.2.1 in 08-pre-Oct01. The natural way of generally using flags is "one if the parameter is foobar". There is a conflict in draft-08-pre and hip-mm-00. The type value for the HMAC parameter is different. I guess draft-08-pre contains the up-to-date value? draft-08-pre describes the maximum value for a HIP parameter length in section 6.1. Should the minimum value (zero?) specified also as a hint for the developers to avoid buffer overflow issues in their implementation ?) draft-08-pre state machine in section 5.4.2 specifies state transitions in the order "first send packet x and then change state". We had to do that in reverse order in our implementation in the case of E2 (Waiting to finish HIP) because the response packet was received before the state was changed! If we had followed the order of the draft, we would have had to wait for the timeout and retransmission of packets. Should the ordering be changed or are we doing something wrong (or too fast ;)? The drafts do not make a specific statement about loop back support of HIP. I mean about sending a packet from HIT1 to HIT2 where the HIT1 and HIT2 are the same. The loop back support may sound silly but TCP/IP supports it, so why shouldn't HIP? It is very useful for testing with a single host. However, the loopback HIP is a bit hard to implement, at least in our implementation. We are currently using the destination HIT as the key to the HIP database and obviously using the same HITs as source and destination addresses won't just work. As I recall, none of the other implementations does not support loopback HIP either? What about the integration with the rest of the TCP/IP stack? Should there be a explicit statement about this in arch-05-pre-Oct20? Here is a couple of things that popped up in our (kernel module) implementation: - Should TCP (or other transport layer) retransmissions be dropped by the implementation? HIP layer has seems to have its own timeouts. - May the implementation cache packets (e.g. SYNs) during the base exchange or other HIP packet exchange? If the implementation just drops the packets during base exchange, it is subject to transport layer retransmission timeouts. - If the implementation caches packets, should it cache them all? If it caches only one, should it cache only the first packet or the most recently sent? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 20 05:42:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 04:42:01 2003 Subject: [Hipsec] Issue 25: Renumber parameter values & critical flag (was: miscellaneous comments on the drafts) In-Reply-To: References: Message-ID: <3F93A6A6.4070201@nomadiclab.com> Miika Komu wrote: > The value of SPI_LSI type is zero in draft-08-pre. I'd recommend to change > this value non-zero, as zero is interpreted usually as "initialized but > not used yet" in data structures in C-language. This was the most > difficult type value to change in our implementation. > > Critical flag in section is specified as "Zero if this parameter is > critical" in section 6.2.1 in 08-pre-Oct01. The natural way of generally > using flags is "one if the parameter is foobar". I am really open ended with regard to this. If people feel that parameter type 0 should be reserved for implementation internal use, and that we should use odd parameters as critical instead of odd ones, I can make the changes. The reason for the current values was to minimize changes, making my editing easier :-) Opinions? If no other opions appear before Thursday, I guess we will adopt Miika's proposal. --Pekka From pekka.nikander@nomadiclab.com Mon Oct 20 05:51:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 04:51:01 2003 Subject: [Hipsec] miscellaneous comments on the drafts In-Reply-To: References: Message-ID: <3F93A8E1.8050203@nomadiclab.com> Miika Komu wrote: > There is a conflict in draft-08-pre and hip-mm-00. The type value for the > HMAC parameter is different. I guess draft-08-pre contains the up-to-date > value? Yes. Additionally, I'm afraid mm-01 will be considerably different from mm-00, once I get it out. > draft-08-pre state machine in section 5.4.2 specifies state transitions in > the order "first send packet x and then change state". We had to do that > in reverse order in our implementation in the case of E2 (Waiting to > finish HIP) because the response packet was received before the state was > changed! If we had followed the order of the draft, we would have had to > wait for the timeout and retransmission of packets. Should the ordering be > changed or are we doing something wrong (or too fast ;)? The state machine and processing rules are hints for implementors. I think Section 8 states this explicitly. I added the following statement to the beginning of Section 5. Implementors must understand that the state machine, as described here, is informational. Specific implementations are free to implement the actual functions differently. Ok? > The drafts do not make a specific statement about loop back support of > HIP. I mean about sending a packet from HIT1 to HIT2 where the HIT1 and > HIT2 are the same. The loop back support may sound silly but TCP/IP > supports it, so why shouldn't HIP? It is very useful for testing with a > single host. I think this is an implementation issue, and doesn't need to be discussed in the draft. > However, the loopback HIP is a bit hard to implement, at least in our > implementation. We are currently using the destination HIT as the key to > the HIP database and obviously using the same HITs as source and > destination addresses won't just work. As I recall, none of the other > implementations does not support loopback HIP either? Ours does, at least sort of, if I remember correctly. We are using the HITs as keys to a internal data structure too. I don't understand why it is hard to have both the src and dst equal? > What about the integration with the rest of the TCP/IP stack? Should there > be a explicit statement about this in arch-05-pre-Oct20? Here is a couple > of things that popped up in our (kernel module) implementation: > > - Should TCP (or other transport layer) retransmissions be dropped by the > implementation? HIP layer has seems to have its own timeouts. Do you mean during the base exchange? I think that is covered by Section 8.2 bullet 3, isn't it? > - May the implementation cache packets (e.g. SYNs) during the base > exchange or other HIP packet exchange? If the implementation just drops > the packets during base exchange, it is subject to transport layer > retransmission timeouts. I think that is covered by Section 8.2 bullet 3, too? > - If the implementation caches packets, should it cache them all? If it > caches only one, should it cache only the first packet or the most > recently sent? I think that is covered by Section 8.2 bullet 3. Basically, all the details are up to the implementation, at least currently. And they are definitely not architectural issues, IMHO. --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 20 05:54:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 04:54:00 2003 Subject: [Hipsec] Issue 26: Minimum value for HIP Parameters length field (was: miscellaneous comments on the drafts In-Reply-To: References: Message-ID: <3F93A995.2090807@nomadiclab.com> Miika Komu wrote: > draft-08-pre describes the maximum value for a HIP parameter length in > section 6.1. Should the minimum value (zero?) specified also as a hint for > the developers to avoid buffer overflow issues in their implementation ?) I don't really understand. What is the issue? From my point of view, it should be obvious (from the definition of I1) that the minimum length of the HIP Parameters field is zero. Why, exactly, should it be defined? What was the difficulty you encoutered? --Pekka Nikander From pekka.nikander@nomadiclab.com Mon Oct 20 06:09:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 05:09:01 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR In-Reply-To: References: Message-ID: <3F93ACFE.4010605@nomadiclab.com> >> The second purpose is to create a stable starting point for the proposed >> working group. [...] Hence, one purpose of publishing the architecture >> document prior to creating the WG is to explicitly avoid turf wars. > > Agreed, as long as one realizes that blocking the work is a feature, > not a bug. Sorry, but I don't understand your comment. Do you mean the IESG blocking a document? Yes, I know it is a feature. I did re-read RFC2026 prior to sending the announcement of my plan to the list. However, I also think that the RFC2026 wording more or less leaves the IESG only two options: - either they must accept the publication of the document as Informational (perhaps with their warning statement), or - they must charter the new proposed WG so that it produces standards track documents. The latter would not be very wise, IMHO. (Of course, they can decide not the charter the WG at all, and even block the BOF. However, that might receive some pretty angry reactions...) >> Well, the architecure has been basically stable now for over two >> years. > > I thought that e.g. the parts about allowing the IP address changes from > about everywhere (resulting in potential flooding attacks) to a stricter > model was changed rather recently? Well, yes and no. Two years back people in general didn't understand the dangers. Hence, I would not consider that as an architectural change. But sure, there are details that have changed during the last two years, and the last one (as far as I can remember) was the change to the TCP/UDP pseudo-header handling. The documents may have been behind the general agreement among the implementors. It is well possible that HIP contains other dangers (but flooding) that we just don't know of now. That is one more reason why the WG has been proposed to be chartered to produce mainly Experimental docs. But, IMHO, it is not a reason not to publish the architecture draft, as it is now. --Pekka Nikander From pekkas@netcore.fi Mon Oct 20 06:14:01 2003 From: pekkas@netcore.fi (Pekka Savola) Date: Mon Oct 20 05:14:01 2003 Subject: [Hipsec] Submitting draft-moskowitz-hip-arch-05 to the RFC EDITOR In-Reply-To: <3F93ACFE.4010605@nomadiclab.com> Message-ID: On Mon, 20 Oct 2003, Pekka Nikander wrote: > >> The second purpose is to create a stable starting point for the proposed > >> working group. [...] Hence, one purpose of publishing the architecture > >> document prior to creating the WG is to explicitly avoid turf wars. > > > > Agreed, as long as one realizes that blocking the work is a feature, > > not a bug. > > Sorry, but I don't understand your comment. Do you mean the IESG > blocking a document? No, I referred to the document blocking (more or less) *this* WG's output, or at least framing it. [...] > I also think that the RFC2026 wording more or less leaves the > IESG only two options: > > - either they must accept the publication of the document > as Informational (perhaps with their warning statement), or > > - they must charter the new proposed WG so that it produces > standards track documents. [...] (This is out of scope here, because I didn't phrase my concern properly above, but..) The latter is not accurate. They can refer the document as *input* to the standards track publication process; it does not require that the documents themselves need to progress anywhere. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Julien.Laganier@Sun.COM Mon Oct 20 08:03:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 20 07:03:01 2003 Subject: [Hipsec] miscellaneous comments on the drafts In-Reply-To: <3F93A8E1.8050203@nomadiclab.com> References: <3F93A8E1.8050203@nomadiclab.com> Message-ID: <200310201332.16416.julien.laganier@sun.com> On Monday 20 October 2003 11:20, Pekka Nikander wrote: > Miika Komu wrote: > > However, the loopback HIP is a bit hard to implement, at least in our > > implementation. We are currently using the destination HIT as the key to > > the HIP database and obviously using the same HITs as source and > > destination addresses won't just work. As I recall, none of the other > > implementations does not support loopback HIP either? > > Ours does, at least sort of, if I remember correctly. We are using > the HITs as keys to a internal data structure too. I don't understand > why it is hard to have both the src and dst equal? I guess it can be hard if the data structure storing the state associated with a given HITs pair doesn't record the {initiator|responder} quality of the node. If it is the case, while using loopbacks HITs, you end-up having only one state storing indeed two different states, one as an initiator and the other one as a responder. My implementation was doing this: It transitions to E3 after having sent R2 (to itself), causing the subsequently received (from itself) R2 to be discarded, as per the state machine diagram... So I need to put an {Initiator|Responder} flag in the state data structure and use it as a part of the key to the HIP database. Just my understanding... --julien From mkomu@niksula.hut.fi Mon Oct 20 09:17:00 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Mon Oct 20 08:17:00 2003 Subject: [Hipsec] miscellaneous comments on the drafts In-Reply-To: <3F93A8E1.8050203@nomadiclab.com> References: <3F93A8E1.8050203@nomadiclab.com> Message-ID: On Mon, 20 Oct 2003, Pekka Nikander wrote: > > draft-08-pre state machine in section 5.4.2 specifies state transitions in > > the order "first send packet x and then change state". We had to do that > > in reverse order in our implementation in the case of E2 (Waiting to > > finish HIP) because the response packet was received before the state was > > changed! If we had followed the order of the draft, we would have had to > > wait for the timeout and retransmission of packets. Should the ordering be > > changed or are we doing something wrong (or too fast ;)? > > The state machine and processing rules are hints for implementors. > I think Section 8 states this explicitly. I added the following > statement to the beginning of Section 5. > > Implementors must understand that the state machine, as > described here, is informational. Specific implementations > are free to implement the actual functions differently. > > Ok? Ok. > > What about the integration with the rest of the TCP/IP stack? Should there > > be a explicit statement about this in arch-05-pre-Oct20? Here is a couple > > of things that popped up in our (kernel module) implementation: > > > > - Should TCP (or other transport layer) retransmissions be dropped by the > > implementation? HIP layer has seems to have its own timeouts. > > Do you mean during the base exchange? I think that is covered by > Section 8.2 bullet 3, isn't it? You mean section 8.1. bullet 3? 3. If there no active HIP session with the given < source, destination > HIT pair, one must be created by running the base exchange. The implementation SHOULD queue at least one packet per a HIP session to be formed, and it MAY queue more than one. > > - May the implementation cache packets (e.g. SYNs) during the base > > exchange or other HIP packet exchange? If the implementation just drops > > the packets during base exchange, it is subject to transport layer > > retransmission timeouts. > > I think that is covered by Section 8.2 bullet 3, too? > > > - If the implementation caches packets, should it cache them all? If it > > caches only one, should it cache only the first packet or the most > > recently sent? > > I think that is covered by Section 8.2 bullet 3. > > Basically, all the details are up to the implementation, at least > currently. And they are definitely not architectural issues, IMHO. Yes, you're correct. I should have RTFM better. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 20 11:52:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 20 10:52:03 2003 Subject: [Hipsec] miscellaneous comments on the drafts In-Reply-To: <200310201332.16416.julien.laganier@sun.com> References: <3F93A8E1.8050203@nomadiclab.com> <200310201332.16416.julien.laganier@sun.com> Message-ID: <3F93FD6B.8030607@nomadiclab.com> >>> However, the loopback HIP is a bit hard to implement... >> >> Ours does, at least sort of, if I remember correctly. We are using >> the HITs as keys to a internal data structure too. I don't >> understand why it is hard to have both the src and dst equal? > > I guess it can be hard if the data structure storing the state > associated with a given HITs pair doesn't record the > {initiator|responder} quality of the node. You shouldn't need to do that. > If it is the case, while using loopbacks HITs, you end-up having only > one state storing indeed two different states, one as an initiator > and the other one as a responder. Exactly. That is what you should have, one state. According to Section 5.4.2, if you receive an I2 in state E2, you should process it, send an R2 and go to E3. Then, in E3, if you receive and R2, you should just drop it and remain in E3. Hence, no special tricks are needed. You just must be able to receive and correctly process an I2 when in state E2. Section 8.6 bullet 18 also explicitly mentions state E2 as a possible state for processing an I2. Section 8.7 is also very clear. --Pekka Nikander From mkomu@niksula.hut.fi Mon Oct 20 12:13:01 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Mon Oct 20 11:13:01 2003 Subject: [Hipsec] Re: Issue 26: Minimum value for HIP Parameters length field (was: miscellaneous comments on the drafts In-Reply-To: <3F93A995.2090807@nomadiclab.com> References: <3F93A995.2090807@nomadiclab.com> Message-ID: On Mon, 20 Oct 2003, Pekka Nikander wrote: > Miika Komu wrote: > > draft-08-pre describes the maximum value for a HIP parameter length in > > section 6.1. Should the minimum value (zero?) specified also as a hint for > > the developers to avoid buffer overflow issues in their implementation ?) > > I don't really understand. What is the issue? From my point of > view, it should be obvious (from the definition of I1) that the > minimum length of the HIP Parameters field is zero. > > Why, exactly, should it be defined? What was the difficulty > you encoutered? Sorry, I was a bit confused. The HIP header length is ok, I meant a min/max value for any HIP parameter, such as DIFFIE_HELLMAN, CERT, etc. But that depends on the number of existing parameters in a HIP message, so I guess that can be left out of the draft. The implementation is ultimately responsible of checking the validity of the lengths of HIP parameters in a HIP packet. (I encountered this issue when I was updating our HIP packet builder library and I had to verify the minimum and maximum lengths of HIP parameters in incoming HIP packets) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Julien.Laganier@Sun.COM Mon Oct 20 12:24:03 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 20 11:24:03 2003 Subject: [Hipsec] miscellaneous comments on the drafts In-Reply-To: <3F93FD6B.8030607@nomadiclab.com> References: <200310201332.16416.julien.laganier@sun.com> <3F93FD6B.8030607@nomadiclab.com> Message-ID: <200310201752.47964.julien.laganier@sun.com> On Monday 20 October 2003 17:21, Pekka Nikander wrote: > >>> However, the loopback HIP is a bit hard to implement... > >> > >> Ours does, at least sort of, if I remember correctly. We are using > >> the HITs as keys to a internal data structure too. I don't > >> understand why it is hard to have both the src and dst equal? > > > > I guess it can be hard if the data structure storing the state > > associated with a given HITs pair doesn't record the > > {initiator|responder} quality of the node. > > You shouldn't need to do that. I agree. > > If it is the case, while using loopbacks HITs, you end-up having only > > one state storing indeed two different states, one as an initiator > > and the other one as a responder. > > Exactly. That is what you should have, one state. Indeed. > According to Section 5.4.2, if you receive an I2 in state E2, > you should process it, send an R2 and go to E3. Then, in E3, > if you receive and R2, you should just drop it and remain in E3. > > Hence, no special tricks are needed. You just must be able to > receive and correctly process an I2 when in state E2. I concur. But as a possible goal of doing a loopback HIP exchange was to debug (It was mine), I wasn't satisfied in having R2 dropped because it doesn't allow me to debug the R2 input side ;-) Thanks, --julien From shep@alum.mit.edu Mon Oct 20 12:57:03 2003 From: shep@alum.mit.edu (Tim Shepard) Date: Mon Oct 20 11:57:03 2003 Subject: [Hipsec] an alternative to making IPv4 NATs "HIP aware" Message-ID: <200310201626.h9KGQGWB010012@ginger.lcs.mit.edu> There has been discussion about making HIP traverse IPv4 NATs. We've broken that down into two cases: (1) Making the IPv4 NAT HIP-aware (2) somehow tunneling HIP through a NAT that is not aware of HIP. I would like to point out that there is an alternative to (1) which is to deploy RFC3056 (with RFC3068 if no better tunnel is known) at the NAT and use IPv6 behind the NAT, and then run HIP (and ESP) over IPv6. To complete the story, we just need to say that hosts implementing HIP SHOULD give themselves IPv6 connectivity via RFC3056/RFC3068 if they don't otherwise have IPv6 connectivity but do have IPv4 connectivity that is not an RFC1918 address. I think it would be much nicer to ask NAT implementors to do RFC3056/RFC3068 than to do something special to make their NATs HIP-aware. What do you think? (BTW, About 6 months ago I gave myself IPv6 connectivity at home using RFC3056/RFC3068. It worked, and without me having to contact anyone to make arrangements for a tunnel. If you haven't done so yet, you should try it.) -Tim Shepard shep@alum.mit.edu From mkousa@cc.hut.fi Tue Oct 21 13:30:01 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 21 12:30:01 2003 Subject: [Hipsec] IMPLEMENTORS: New -08-pre and interoperability in Minneapolis In-Reply-To: <3F7AB147.3060306@nomadiclab.com> References: <3F7AB147.3060306@nomadiclab.com> Message-ID: Section 3.3 Security Parameter Index (SPI) of draft-08 says that "The SPI selection SHOULD be random." While I was fixing our implementation, I found out that RFC2406 (IP Encapsulating Security Payload (ESP)) section 2.1 defines some restrictions for SPI assignment: "The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use" and "The SPI value of zero (0) is reserved for local, implementation- specific use and MUST NOT be sent on the wire". Should the draft-08 also note that these values defined in RFC2406 must not be used ? From pekka.nikander@nomadiclab.com Thu Oct 23 06:17:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 05:17:01 2003 Subject: [Hipsec] Host Identity Protocol Architecture and BOF Message-ID: <3F97A396.5040300@nomadiclab.com> Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 23 07:09:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 06:09:01 2003 Subject: [Hipsec] Closing Issues 20, 21, 22, 23, 24, and 26 Message-ID: <3F97AFC4.1000106@nomadiclab.com> I haven't seen any discussion on Issue 20: Padding encrypted TLV, after Oct 7th. Therefore I think we can close it. I haven't seen any discussion on Issue 21: Forced ESP sending in NES. I think we can close it. I haven't seen any discussion on Issue 22: NES ID initialization. I think we can close it. I haven't seen any discussion on Issue 23: New substate for receiving ICMP, after Oct 8th. Therefore I think we can close it. I haven't seen any discussion on issue 24: Unification of HMAC and SIG processing. I think we can close it. Based on the discussion on Issue 26, I don't see any need for changes. I think we can close the issue. --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 23 07:21:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 06:21:00 2003 Subject: [Hipsec] Closing Issue 27: Handling reserved SPI values (was something else) In-Reply-To: References: <3F7AB147.3060306@nomadiclab.com> Message-ID: <3F97B283.7000100@nomadiclab.com> Mika Kousa wrote: > Section 3.3 Security Parameter Index (SPI) of draft-08 says that "The SPI > selection SHOULD be random." While I was fixing our implementation, I > found out that RFC2406 (IP Encapsulating Security Payload (ESP)) section > 2.1 defines some restrictions for SPI assignment: "The set of SPI values > in the range 1 through 255 are reserved by the Internet Assigned Numbers > Authority (IANA) for future use" and "The SPI value of zero (0) is > reserved for local, implementation- specific use and MUST NOT be sent on > the wire". Should the draft-08 also note that these values defined in > RFC2406 must not be used ? Good catch. I replaced RFC2406 with draft-ietf-ipsec-esp-v3, and added a reference to Section 2.1 of that draft to the SPI section of our draft. I think the issue is fixed now, and can be closed. --Pekka From pekka.nikander@nomadiclab.com Thu Oct 23 08:02:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 07:02:00 2003 Subject: [Hipsec] draft-moskowitz-hip-08.txt IS OUT! Message-ID: <3F97BC1E.3000106@nomadiclab.com> Folks, I submitted just a few moments ago draft-moskowitz-hip-08.txt to the repositories. It should resolve almost all of the issues raised, with two exceptions: Issue 18: Example chacksums The reason for this having been left open is that I am getting weary on editing this draft, and don't have the energy to produce high quality examples from the raw material. Issue 25: Renumbering of parameter IDs once again. This I have left open deliberately so that there is *some* change for -08-pre-Oct01 and -08 versions to interoperate. Unfortunately the HMAC computation is different between these two versions (Issue 24), and therefore care must be taken. Other than that, there should not be any major showstoppers. The issues page, http://www.tml.hut.fi/~pnr/HIP/issues.html has been updated to reflect the status of the issues. It may take some time before the draft appears at the repository due to the large number of last minute submissions. However, as usual, the draft is available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08.xml http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08.html What is less usual, though, is that this time I produced diffs against the previous pre-release, too: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-from-pre-Oct01.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-08-from-pre-Oct01.txt It has been a honor to be able to serve as the editor for this draft. I think that it represents an important piece of work. However, as some people know, I am best in working on new and complex issues, and not so good in trying to track zillions of details. For this and for other reasons, we have agreed that Petri Jokela will act as the draft editor from here on. I wish Petri good luck and enough of patience with this new job! --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 23 09:15:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 08:15:01 2003 Subject: [Hipsec] Host Identity Protocol Architecture and BOF Message-ID: <3F97A396.5040300@nomadiclab.com> Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From pekka.nikander@nomadiclab.com Thu Oct 23 09:15:05 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 23 08:15:05 2003 Subject: [Hipsec] Host Identity Protocol Architecture and BOF Message-ID: <3F97A396.5040300@nomadiclab.com> Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From mkomu@niksula.hut.fi Fri Oct 24 10:37:01 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Fri Oct 24 09:37:01 2003 Subject: [Hipsec] draft-moskowitz-hip-08.txt IS OUT! In-Reply-To: <3F97BC1E.3000106@nomadiclab.com> References: <3F97BC1E.3000106@nomadiclab.com> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-684387517-1067004425=:9487 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 23 Oct 2003, Pekka Nikander wrote: > Issue 25: Renumbering of parameter IDs once again. > > This I have left open deliberately so that there > is *some* change for -08-pre-Oct01 and -08 > versions to interoperate. Unfortunately the HMAC > computation is different between these two > versions (Issue 24), and therefore care must be > taken. Other than that, there should not be any > major showstoppers. A patch for solving the issue for draft-09 is attached. I incremented all of the type values up by one and changed the text specifying the syntax of the "critical" value. The CERT parameter type value was wrong in draft-08 (CERT is optional; isn't it?) and it is also fixed. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ ---559023410-684387517-1067004425=:9487 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-moskowitz-hip-08.xml.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-moskowitz-hip-08.xml.patch" LS0tIGRyYWZ0LW1vc2tvd2l0ei1oaXAtMDgueG1sLm9sZAkyMDAzLTEwLTIz IDE0OjEzOjI4LjAwMDAwMDAwMCArMDMwMA0KKysrIGRyYWZ0LW1vc2tvd2l0 ei1oaXAtMDgueG1sCTIwMDMtMTAtMjQgMTY6NTA6NTYuMDAwMDAwMDAwICsw MzAwDQpAQCAtMTI1NSw0MSArMTI1NSw0MSBAQA0KICAgICAgICAgICA8YXJ0 d29yaz4NCiAgICBUTFYgICAgICAgICAgICAgICBUeXBlICBMZW5ndGggICAg IERhdGENCiANCi0gICBTUElfTFNJICAgICAgICAgICAwICAgICAxNiAgICAg ICAgIFJlbW90ZSdzIFNQSSwgUmVtb3RlJ3MgTFNJLg0KKyAgIFNQSV9MU0kg ICAgICAgICAgIDEgICAgIDE2ICAgICAgICAgUmVtb3RlJ3MgU1BJLCBSZW1v dGUncyBMU0kuDQogDQotICAgQklSVEhEQVlfQ09PS0lFICAgMi80ICAgMzIg ICAgICAgICBTeXN0ZW0gQm9vdCBDb3VudGVyIHBsdXMNCisgICBCSVJUSERB WV9DT09LSUUgICAzLzUgICAzMiAgICAgICAgIFN5c3RlbSBCb290IENvdW50 ZXIgcGx1cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdHdvIDY0LWJpdCBmaWVsZHM6DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtIFJhbmRvbSAjSSANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0gSyBvciByYW5kb20gI0oNCiAN CiANCi0gICBESUZGSUVfSEVMTE1BTiAgICA2ICAgICB2YXJpYWJsZSAgIHB1 YmxpYyBrZXkNCisgICBESUZGSUVfSEVMTE1BTiAgICA3ICAgICB2YXJpYWJs ZSAgIHB1YmxpYyBrZXkNCiANCi0gICBORVNfSU5GTyAgICAgICAgICAxMCAg ICAgICAgICAgICAgIE9sZCBTUEksIE5ldyBTUEkgYW5kIG90aGVyDQorICAg TkVTX0lORk8gICAgICAgICAgMTEgICAgICAgICAgICAgICBPbGQgU1BJLCBO ZXcgU1BJIGFuZCBvdGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW5mbyBuZWVkZWQgZm9yIE5FUw0KIA0KLSAgIEhJUF9U UkFOU0ZPUk0gICAgIDE2ICAgIHZhcmlhYmxlICAgSElQIEVuY3J5cHRpb24g YW5kIEludGVncml0eQ0KKyAgIEhJUF9UUkFOU0ZPUk0gICAgIDE3ICAgIHZh cmlhYmxlICAgSElQIEVuY3J5cHRpb24gYW5kIEludGVncml0eQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHJhbnNmb3JtDQog DQotICAgRVNQX1RSQU5TRk9STSAgICAgMTggICAgdmFyaWFibGUgICBFU1Ag RW5jcnlwdGlvbiBhbmQNCisgICBFU1BfVFJBTlNGT1JNICAgICAxOSAgICB2 YXJpYWJsZSAgIEVTUCBFbmNyeXB0aW9uIGFuZA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gVHJhbnNm b3JtDQogDQotICAgRU5DUllQVEVEICAgICAgICAgMjAgICAgdmFyaWFibGUg ICBFbmNyeXB0ZWQgcGFydCBvZiBJMiBvciBDRVINCisgICBFTkNSWVBURUQg ICAgICAgICAyMSAgICB2YXJpYWJsZSAgIEVuY3J5cHRlZCBwYXJ0IG9mIEky IG9yIENFUg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgcGFja2V0cw0KLSAgIEhPU1RfSUQgICAgICAgICAgIDMyICAgIHZhcmlh YmxlICAgSG9zdCBJZGVudGl0eQ0KKyAgIEhPU1RfSUQgICAgICAgICAgIDMz ICAgIHZhcmlhYmxlICAgSG9zdCBJZGVudGl0eQ0KIA0KLSAgIEhPU1RfSURf RlFETiAgICAgIDM0ICAgIHZhcmlhYmxlICAgSG9zdCBJZGVudGl0eSB3aXRo IEZ1bGx5DQorICAgSE9TVF9JRF9GUUROICAgICAgMzUgICAgdmFyaWFibGUg ICBIb3N0IElkZW50aXR5IHdpdGggRnVsbHkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFF1YWxpZmllZCBEb21haW4gTmFtZQ0K IA0KICAgIENFUlQgICAgICAgICAgICAgIDY0ICAgIHZhcmlhYmxlICAgSEkg Y2VydGlmaWNhdGUNCiANCi0gICBITUFDICAgICAgICAgICAgICA2NTUwMCAy NCAgICAgICAgIEhNQUMgYmFzZWQgbWVzc2FnZSANCisgICBITUFDICAgICAg ICAgICAgICA2NTUwMSAyNCAgICAgICAgIEhNQUMgYmFzZWQgbWVzc2FnZSAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhl bnRpY2F0aW9uIGNvZGUsIHdpdGgNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGtleSBtYXRlcmlhbCBmcm9tIEhJUF9UUkFOU0ZP Uk0NCiANCi0gICBISVBfU0lHTkFUVVJFMiAgICA2NTUzMiB2YXJpYWJsZSAg IFNpZ25hdHVyZSBvZiB0aGUgUjEgcGFja2V0IA0KKyAgIEhJUF9TSUdOQVRV UkUyICAgIDY1NTMzIHZhcmlhYmxlICAgU2lnbmF0dXJlIG9mIHRoZSBSMSBw YWNrZXQgDQogDQotICAgSElQX1NJR05BVFVSRSAgICAgNjU1MzQgdmFyaWFi bGUgICBTaWduYXR1cmUgb2YgdGhlIHBhY2tldA0KKyAgIEhJUF9TSUdOQVRV UkUgICAgIDY1NTM1IHZhcmlhYmxlICAgU2lnbmF0dXJlIG9mIHRoZSBwYWNr ZXQNCiANCiAgICAgICAgICAgPC9hcnR3b3JrPg0KICAgICAgICAgPC9maWd1 cmU+DQpAQCAtMTMzNSwxMSArMTMzNSwxMSBAQA0KICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogDQogICAgVHlwZSAgICAgICAgIFR5cGUgY29kZSBmb3Ig dGhlIHBhcmFtZXRlcg0KLSAgICAgQyAgICAgICAgICBDcml0aWNhbC4gIFpl cm8gaWYgdGhpcyBwYXJhbWV0ZXIgaXMgY3JpdGljYWwsIGFuZA0KLSAgICAg ICAgICAgICAgICBNVVNUIGJlIHJlY29nbml6ZWQgYnkgdGhlIHJlY2lwaWVu dCwgb25lIG90aGVyd2lzZS4NCisgICAgIEMgICAgICAgICAgQ3JpdGljYWwu ICBPbmUgaWYgdGhpcyBwYXJhbWV0ZXIgaXMgY3JpdGljYWwsIGFuZA0KKyAg ICAgICAgICAgICAgICBNVVNUIGJlIHJlY29nbml6ZWQgYnkgdGhlIHJlY2lw aWVudCwgemVybyBvdGhlcndpc2UuDQogICAgICAgICAgICAgICAgIFRoZSBD IGJpdCBpcyBjb25zaWRlcmVkIHRvIGJlIGEgcGFydCBvZiB0aGUgVHlwZSBm aWVsZC4NCi0gICAgICAgICAgICAgICAgQ29uc2VxdWVudGx5LCBjcml0aWNh bCBwYXJhbWV0ZXJzIGFyZSBhbHdheXMgZXZlbg0KLSAgICAgICAgICAgICAg ICBhbmQgbm9uLWNyaXRpY2FsIG9uZXMgaGF2ZSBhbiBvZGQgdmFsdWUuDQor ICAgICAgICAgICAgICAgIENvbnNlcXVlbnRseSwgY3JpdGljYWwgcGFyYW1l dGVycyBhcmUgYWx3YXlzIG9kZCBhbmQNCisgICAgICAgICAgICAgICAgbm9u LWNyaXRpY2FsIG9uZXMgaGF2ZSBhbiBldmVuIHZhbHVlLg0KICAgIExlbmd0 aCAgICAgICBMZW5ndGggb2YgdGhlIHBhcmFtZXRlciwgaW4gYnl0ZXMuDQog ICAgQ29udGVudHMgICAgIFBhcmFtZXRlciBzcGVjaWZpYywgZGVmaW5lZCBi eSBUeXBlDQogICAgUGFkZGluZyAgICAgIFBhZGRpbmcsIDAtNyBieXRlcywg YWRkZWQgaWYgbmVlZGVkDQpAQCAtMTQzOCw3ICsxNDM4LDcgQEANCiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTFNJICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogDQotICAgVHlwZSAgICAgICAgIDANCisgICBUeXBlICAgICAgICAgMQ0K ICAgIExlbmd0aCAgICAgICAxMg0KICAgIFJlc2VydmVkICAgICBaZXJvIHdo ZW4gc2VudCwgaWdub3JlZCB3aGVuIHJlY2VpdmVkDQogICAgU1BJICAgICAg ICAgIFNlY3VyaXR5IFBhcmFtZXRlciBJbmRleA0KQEAgLTE0NjgsNyArMTQ2 OCw3IEBADQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KIA0KLSAgIFR5cGUgICAgICAgICAgIDIgKGluIFIx KSBvciA0IChpbiBJMikNCisgICBUeXBlICAgICAgICAgICAzIChpbiBSMSkg b3IgNCAoaW4gSTIpDQogICAgTGVuZ3RoICAgICAgICAgMjgNCiAgICBSZXNl cnZlZCAgICAgICBaZXJvIHdoZW4gc2VudCwgaWdub3JlZCB3aGVuIHJlY2Vp dmVkDQogICAgQmlydGhkYXkgICAgICAgU3lzdGVtIGJvb3QgY291bnRlcg0K QEAgLTE0OTYsNyArMTQ5Niw3IEBADQogICAgLyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgcGFkZGluZyAgICAgICAgICAg IHwNCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KLSAgIFR5cGUgICAg ICAgICAgIDYNCisgICBUeXBlICAgICAgICAgICA3DQogICAgTGVuZ3RoICAg ICAgICAgbGVuZ3RoIGluIG9jdGV0cywgZXhjbHVkaW5nIFR5cGUsIExlbmd0 aCwgYW5kIHBhZGRpbmcNCiAgICBHcm91cCBJRCAgICAgICBkZWZpbmVzIHZh bHVlcyBmb3IgcCBhbmQgZw0KICAgIFB1YmxpYyBWYWx1ZSAgIHRoZSBzZW5k ZXIncyBwdWJsaWMgRGlmZmllLUhlbGxtYW4ga2V5DQpAQCAtMTU0MCw3ICsx NTQwLDcgQEANCiAgICB8ICAgICAgICAgIFRyYW5zZm9ybS1JRCAjbiAgICAg IHwgICAgICAgICAgICAgUGFkZGluZyAgICAgICAgICAgfA0KICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogDQotICAgVHlwZSAgICAgICAgICAgMTYNCisg ICBUeXBlICAgICAgICAgICAxNw0KICAgIExlbmd0aCAgICAgICAgIGxlbmd0 aCBpbiBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5ndGgsIGFuZCBwYWRk aW5nDQogICAgVHJhbnNmb3JtLUlEICAgRGVmaW5lcyB0aGUgSElQIFN1aXRl IHRvIGJlIHVzZWQNCiAgICAgICAgICAgICA8L2FydHdvcms+DQpAQCAtMTU4 NSw3ICsxNTg1LDcgQEANCiAgICB8ICAgICAgICAgIFN1aXRlLUlEICNuICAg ICAgICAgIHwgICAgICAgICAgICAgUGFkZGluZyAgICAgICAgICAgfA0KICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogDQotICAgVHlwZSAgICAgICAgICAg MTgNCisgICBUeXBlICAgICAgICAgICAxOQ0KICAgIExlbmd0aCAgICAgICAg IGxlbmd0aCBpbiBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5ndGgsIGFu ZCBwYWRkaW5nDQogICAgU3VpdGUtSUQgICAgICAgRGVmaW5lcyB0aGUgRVNQ IFN1aXRlIHRvIGJlIHVzZWQNCiAgICAgICAgICAgICA8L2FydHdvcms+DQpA QCAtMTYzOSw3ICsxNjM5LDcgQEANCiAgICAvICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgcGFkZGluZyAgICAg fA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQotICAgVHlwZSAgICAg ICAgICAgMzINCisgICBUeXBlICAgICAgICAgICAzMw0KICAgIExlbmd0aCAg ICAgICAgIGxlbmd0aCBpbiBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5n dGgsIGFuZCBwYWRkaW5nDQogICAgSG9zdCBJZGVudGl0eSAgYWN0dWFsIGhv c3QgaWRlbnRpdHkNCiAgICAgICAgICAgICA8L2FydHdvcms+DQpAQCAtMTY3 Nyw3ICsxNjc3LDcgQEANCiAgICAvICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIFBhZGRpbmcgICAgfA0KICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogDQotICAgVHlwZSAgICAgICAgICAg MzQNCisgICBUeXBlICAgICAgICAgICAzNQ0KICAgIExlbmd0aCAgICAgICAg IGxlbmd0aCBpbiBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5ndGgsIGFu ZCBwYWRkaW5nDQogICAgSEkgbGVuZ3RoICAgICAgbGVuZ3RoIG9mIHRoZSBI b3N0IElkZW50aXR5DQogICAgRlFETiBsZW5ndGggICAgbGVuZ3RoIG9mIHRo ZSBGUURODQpAQCAtMTc1NSw3ICsxNzU1LDcgQEANCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQotICAg VHlwZSAgICAgICAgICAgNjU1MDANCisgICBUeXBlICAgICAgICAgICA2NTUw MQ0KICAgIExlbmd0aCAgICAgICAgIDIwDQogICAgSE1BQyAgICAgICAgICAg DQogDQpAQCAtMTgxNiw3ICsxODE2LDcgQEANCiAgICAvICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgcGFkZGluZyAgICAg ICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQotICAgVHlw ZSAgICAgICAgICAgNjU1MzQgKDJeMTYtMikNCisgICBUeXBlICAgICAgICAg ICA2NTUzNSAoMl4xNi0yKQ0KICAgIExlbmd0aCAgICAgICAgIGxlbmd0aCBp biBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5ndGgsIGFuZCBwYWRkaW5n DQogICAgU0lHIGFsZyAgICAgICAgU2lnbmF0dXJlIGFsZ29yaXRobQ0KICAg IFNpZ25hdHVyZSAgICAgIHRoZSBzaWduYXR1cmUgaXMgY2FsY3VsYXRlZCBv dmVyIHRoZSBISVAgcGFja2V0LA0KQEAgLTE4NzIsNyArMTg3Miw3IEBADQog DQogICAgICAgICAgIDxmaWd1cmU+DQogICAgICAgICAgICAgPGFydHdvcms+ DQotICAgVHlwZSAgICAgICAgICAgNjU1MzIgKDJeMTYtNCkNCisgICBUeXBl ICAgICAgICAgICA2NTUzMyAoMl4xNi00KQ0KICAgIExlbmd0aCAgICAgICAg IGxlbmd0aCBpbiBvY3RldHMsIGV4Y2x1ZGluZyBUeXBlLCBMZW5ndGgsIGFu ZCBwYWRkaW5nDQogICAgU0lHIGFsZyAgICAgICAgU2lnbmF0dXJlIGFsZ29y aXRobQ0KICAgIFNpZ25hdHVyZSAgICAgIHRoZSBzaWduYXR1cmUgaXMgY2Fs Y3VsYXRlZCBvdmVyIHRoZSBSMSBwYWNrZXQsDQpAQCAtMTkyMyw3ICsxOTIz LDcgQEANCiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldyBTUEkg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogDQotICAgVHlwZSAgICAgICAgICAgMTANCisgICBUeXBlICAg ICAgICAgICAxMQ0KICAgIExlbmd0aCAgICAgICAgIDEyDQogICAgUiAgICAg ICAgICAgICAgT25lIGlmIHRoZSBORVMgaXMgYSByZXBseSB0byBhbm90aGVy IE5FUywNCiAgICAgICAgICAgICAgICAgICBvdGhlcndpc2UgemVyby4NCkBA IC0xOTcyLDcgKzE5NzIsNyBAQA0KICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgIFBhZGRpbmcgICAgICAgICAgICB8 DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCi0gICBUeXBlICAgICAg ICAgICAyMA0KKyAgIFR5cGUgICAgICAgICAgIDIxDQogICAgTGVuZ3RoICAg ICAgICAgbGVuZ3RoIGluIG9jdGV0cywgZXhjbHVkaW5nIFR5cGUsIExlbmd0 aCwgYW5kIHBhZGRpbmcNCiAgICBSZXNlcnZlZCAgICAgICB6ZXJvIHdoZW4g c2VudCwgaWdub3JlZCB3aGVuIHJlY2VpdmVkDQogICAgSVYgICAgICAgICAg ICAgSW5pdGlhbGl6YXRpb24gdmVjdG9yLCBpZiBuZWVkZWQsIG90aGVyd2lz ZSBub25leGlzdGluZy4NCg== ---559023410-684387517-1067004425=:9487-- From pekka.nikander@nomadiclab.com Tue Oct 28 13:38:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 28 13:38:01 2003 Subject: [Hipsec] The BOF has been approved Message-ID: <3F9EBE8D.2010401@nomadiclab.com> After some waiting I finally got a word from the ADs. The BOF has been formally approved, so there will be a BOF. However, the ADs will still try to move it so that it would appear earlier in the week, due to their own timing constraints. --Pekka Nikander From petri.jokela@nomadiclab.com Thu Oct 30 09:43:01 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Oct 30 09:43:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development Message-ID: <3FA12A84.3050000@nomadiclab.com> Hi everyone, I have now installed an issue tracking system for the draft-moskowitz-hip-xx development. Unfortunately, issue numbering that Pekka used is no longer valid. The numbering of issues begins (again) form 1. The issue tracker can be found from: http://hip4inter.net/issues/ and with userid: guest and password: guest you get a reading access to the issue database. For Issues #1 and #2 (originally from the Pekka's issue list #18 and #25), Thomas and Miika have offered their helping hands. I haven't yet begun the edition of the draft, I suppose that there is no hurry before Minneapolis, -08 will be used there anyway. During HIP for *BSD and HIPL interop tests today, we found one interpretation problem with the -08 draft (Issue #3 in the issue tracker). We had understood the ESP key usage is different ways. In Minneapolis, it would be nice if everyone use the keys in the same way :-) Problem description: ESP keys are retrieved from the keymat. The direction where the keys are used is unclear. For HIP keys, it is clear that the Initiator key is used by the Initiator for encryption. However, it seems that the interpretation for ESP keys is not straightforward. As the Initiator selects the SPI value to be used from the Receiver to the Initiator (SPI Initiator), it may be "logical" that the "Initiator ESP key" is used also by the Receiver to encrypt data that is sent to the Initiator, just like the SPI-I. Solution that we propose (HIPL and NomadicLab) A possible solution for clarifying the keymat usage (In chapter 9): Rename: "Initiator ESP encryption key" -> "SPI-I ESP encryption key" "Initiator ESP authentication key" -> "SPI-I ESP authentication key" "Responder ESP encryption key" -> "SPI-R ESP encryption key" "Responder ESP authentication key" -> "SPI-R ESP authentication key" Now, whenever the SPI-I is used, the corresponding SPI-I key is used (both for encryption and decryption). There should not be any misunderstanding after this change. Any comments ? /petri From andrew@indranet.co.nz Thu Oct 30 17:40:01 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Oct 30 17:40:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA12A84.3050000@nomadiclab.com> References: <3FA12A84.3050000@nomadiclab.com> Message-ID: <1376609.1067602195@[192.168.1.249]> --On Thursday, 30 October 2003 5:13 p.m. +0200 Petri Jokela wrote: > A possible solution for clarifying the keymat usage (In chapter 9): > > Rename: > "Initiator ESP encryption key" -> "SPI-I ESP encryption key" > "Initiator ESP authentication key" -> "SPI-I ESP authentication key" > "Responder ESP encryption key" -> "SPI-R ESP encryption key" > "Responder ESP authentication key" -> "SPI-R ESP authentication key" > > Now, whenever the SPI-I is used, the corresponding SPI-I key is used > (both for encryption and decryption). There should not be any > misunderstanding after this change. Except that I can't easily understand your description.... How about: > Rename: > "Initiator ESP encryption key" -> "ESP encryption key for Initiator's incoming traffic (therefore also Responder's outgoing traffic)" etc etc. I suggest this because the SAs are what we are creating using these keys, and every SA uses all four keys, just in different slots. So we should use the SA slots to describe the use of the keys; however, we only require to describe one direction, because the other is a mirror image. Andrew --------- Andrew McGregor Director, Scientific Advisor IndraNet Technologies Ltd http://www.indranet-technologies.com/ From pekka.nikander@nomadiclab.com Fri Oct 31 00:08:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 31 00:08:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <1376609.1067602195@[192.168.1.249]> References: <3FA12A84.3050000@nomadiclab.com> <1376609.1067602195@[192.168.1.249]> Message-ID: <3FA1F56C.1000906@nomadiclab.com> >> A possible solution for clarifying the keymat usage (In chapter 9): >> >> Rename: >> "Initiator ESP encryption key" -> "SPI-I ESP encryption key" >> "Initiator ESP authentication key" -> "SPI-I ESP authentication key" >> "Responder ESP encryption key" -> "SPI-R ESP encryption key" >> "Responder ESP authentication key" -> "SPI-R ESP authentication key" > > How about: > >> Rename: >> "Initiator ESP encryption key" -> "ESP encryption key for Initiator's > > incoming traffic (therefore also Responder's outgoing traffic)" > etc etc. > > I suggest this because the SAs are what we are creating using these > keys, and every SA uses all four keys, just in different slots. So we > should use the SA slots to describe the use of the keys; however, we > only require to describe one direction, because the other is a mirror > image. I agree with Andrew that we (once more) must be pretty explicit. One possibility would be to add more text to the ESP section, which is currently in bad shape since I moved most of the text to the architecture draft. For example, there could be a subsection: X.1 ESP Security Associations Each HIP association is linked with two ESP SAs, one incoming and one outgoing. The Initiator's incoming SA corresponds with the Responder's outgoing one. The initiator defines the SPI for this association, as defined in Section XXX. This SA is called SA-I, and the corresponding SPI is called SPI-I. Respectively, the responder's incoming SA corresponds with the Initiator's outgoing SA and is called SA-R, with the SPI-R. The Initiator creates SA-I as a part of R1 processing, before sending out the I2, as explained in Step XXX in Section XXX. The keys are derived from KEYMAT, as defined in Section XXX. The Responder creates SA-I as a part of I2 processing, see Section XXX. The Responder creates SA-R as a part of I2 processing, brefore sending out R2, see Step XXX in Section XXX. The Initator creates SA-R when processing R2, see Section XXX. X.2 Updating ESP SAs during rekeying --Pekka From Julien.Laganier@Sun.COM Fri Oct 31 06:19:01 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 31 06:19:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development References: <3FA12A84.3050000@nomadiclab.com> Message-ID: <3FA24C60.9010006@Sun.COM> Petri Jokela wrote: > > ESP keys are retrieved from the keymat. The direction where the keys are > used is unclear. > > For HIP keys, it is clear that the Initiator key is used by the > Initiator for encryption. However, it seems that the interpretation for > ESP keys is not straightforward. As the Initiator selects the SPI value > to be used from the Receiver to the Initiator (SPI Initiator), it may be > "logical" that the "Initiator ESP key" is used also by the Receiver to > encrypt data that is sent to the Initiator, just like the SPI-I. While it's true that the existing text is prone to different interpretations, I'm not sure that your proposition appears "logical" to me... Quoting you: > the "Initiator ESP key" is used also by the Receiver to > encrypt data that is sent to the Initiator, just like the SPI-I. As is was unclear in the spec, I've assumed what appears "logical" to me: Use the ESP keys in the same way than HIP keys. That is, the HIP initiator encryption KEY is used by the Initiator to _encrypt_ data sent to the Responder, so I induct that, similarly, the ESP initiator encryption key is used by the Initiator to encrypt data it sends to the Responder, which is exactly the opposite of what you've described ;-) > Solution that we propose (HIPL and NomadicLab) > > A possible solution for clarifying the keymat usage (In chapter 9): > > Rename: > "Initiator ESP encryption key" -> "SPI-I ESP encryption key" > "Initiator ESP authentication key" -> "SPI-I ESP authentication key" > "Responder ESP encryption key" -> "SPI-R ESP encryption key" > "Responder ESP authentication key" -> "SPI-R ESP authentication key" > > Now, whenever the SPI-I is used, the corresponding SPI-I key is used > (both for encryption and decryption). There should not be any > misunderstanding after this change It clarifies a lot of things, though I am not sure it's consistent with HIP keys usage. Thanks, --julien From pekka.nikander@nomadiclab.com Fri Oct 31 06:33:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 31 06:33:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA24C60.9010006@Sun.COM> References: <3FA12A84.3050000@nomadiclab.com> <3FA24C60.9010006@Sun.COM> Message-ID: <3FA24F93.5060508@nomadiclab.com> Julien Laganier wrote: > While it's true that the existing text is prone to different > interpretations, I'm not sure that your proposition appears "logical" to > me... Quoting you: > > > the "Initiator ESP key" is used also by the Receiver to > > encrypt data that is sent to the Initiator, just like the SPI-I. > > As is was unclear in the spec, I've assumed what appears "logical" to > me: Use the ESP keys in the same way than HIP keys. > > That is, the HIP initiator encryption KEY is used by the Initiator to > _encrypt_ data sent to the Responder, so I induct that, similarly, the > ESP initiator encryption key is used by the Initiator to encrypt data it > sends to the Responder, which is exactly the opposite of what you've > described ;-) I didn't notice that. Sorry for my sloppiness. I agree with you, Julien, that the keys should be used in the same ways as HIP keys. Therefore I would suggest that we rename the SAs and SPIs once more: SA-I => SA-RI SPI-I => SPI-RI SA-R => SA-IR SPI-R => SPI-IR This explicitly indicates the direction of the SAs, making it unambigous. Unless I am mistaken once more, it sounds like both HIPL and we have to reverse key usage in our implementations. That shouldn't be a big deal. --Pekka From petri.jokela@nomadiclab.com Fri Oct 31 06:42:00 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 31 06:42:00 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA24C60.9010006@Sun.COM> References: <3FA12A84.3050000@nomadiclab.com> <3FA24C60.9010006@Sun.COM> Message-ID: <3FA2502C.2010305@nomadiclab.com> Julien Laganier wrote: > Petri Jokela wrote: > > > >> ESP keys are retrieved from the keymat. The direction where the keys >> are used is unclear. >> >> For HIP keys, it is clear that the Initiator key is used by the >> Initiator for encryption. However, it seems that the interpretation >> for ESP keys is not straightforward. As the Initiator selects the SPI >> value to be used from the Receiver to the Initiator (SPI Initiator), >> it may be "logical" that the "Initiator ESP key" is used also by the >> Receiver to encrypt data that is sent to the Initiator, just like the >> SPI-I. > > > While it's true that the existing text is prone to different > interpretations, I'm not sure that your proposition appears "logical" to > me... Quoting you: > > > the "Initiator ESP key" is used also by the Receiver to > > encrypt data that is sent to the Initiator, just like the SPI-I. > > As is was unclear in the spec, I've assumed what appears "logical" to > me: Use the ESP keys in the same way than HIP keys. Yes, that would be logical when reading the key retrieving from the keymat. But: SPIs work the other way round, and the SPI-I (selected by the initiator) is used from the responder towards the initiator. Thus it can be thought that it is logical to use Initiator key for encrypting data to be sent to the Initiator, just like the SPI-I (and in that case we have a collision with the HIP key definition). What is logical for one person is not logical for the other person, as was noticed yesterday during the interop test :-) >> Rename: >> "Initiator ESP encryption key" -> "SPI-I ESP encryption key" >> "Initiator ESP authentication key" -> "SPI-I ESP authentication key" >> "Responder ESP encryption key" -> "SPI-R ESP encryption key" >> "Responder ESP authentication key" -> "SPI-R ESP authentication key" >> >> Now, whenever the SPI-I is used, the corresponding SPI-I key is used >> (both for encryption and decryption). There should not be any >> misunderstanding after this change > > > It clarifies a lot of things, though I am not sure it's consistent with > HIP keys usage. No, it's not, but by changing the naming we tried to get rid of the logic between the HIP and the ESP keys and tie the definition with the SPI selection. It might be better to adopt the Andrew's proposal: we get rid of the "Initiator key" and "Responder key" names and, in fact, describe the actual usage of the key material. Also the ESP section modification, as Pekka proposed, would clarify the key usage. > Thanks, > > --julien /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From rgm@htt-consult.com Fri Oct 31 07:42:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Fri Oct 31 07:42:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA1F56C.1000906@nomadiclab.com> References: <3FA12A84.3050000@nomadiclab.com> <1376609.1067602195@[192.168.1.249]> <3FA1F56C.1000906@nomadiclab.com> Message-ID: <6.0.0.22.2.20031031080922.03c65ef8@localhost> At 12:38 AM 10/31/2003, Pekka Nikander wrote: > Each HIP association is linked with two ESP SAs, one > incoming and one outgoing. > > The Initiator creates SA-I as a part of R1 processing, before > > The Responder creates SA-R as a part of I2 processing, As good naming as anything. BTW, we have also found it helpful to include an SA ID which is a hash of information within the SA. This is valuable for SAs that don't naturally have SPIs. In HIP (as in IPsec), the SPI is the SA ID... From rgm@htt-consult.com Fri Oct 31 07:42:04 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Fri Oct 31 07:42:04 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <1376609.1067602195@[192.168.1.249]> References: <3FA12A84.3050000@nomadiclab.com> <1376609.1067602195@[192.168.1.249]> Message-ID: <6.0.0.22.2.20031031080414.03c6a6b8@localhost> At 06:09 PM 10/30/2003, Andrew McGregor wrote: >I suggest this because the SAs are what we are creating using these keys, >and every SA uses all four keys, just in different slots. So we should >use the SA slots to describe the use of the keys; however, we only require >to describe one direction, because the other is a mirror image. In 802.11, 802.1, and EAP-keying we are looking heavily into organizing everything in terms of SAs. We have LOTS of SAs. :) In a new clause in 802.11 I wrote up 3 SAs (Jesse Walker 'normalized' my text :) ): PMKSA, PTKSA, and GTKSA. In EAP we are doing similar work, setting up a separate SA for each level in the EAP keying hierarchy. A similiar change in HIP could well help in understanding. Something like INITSA and RESPSA, or just ISA and RSA ;) Just a quick check back here and now back to reading 180 page 802 specs for balloting (802.1X-REV due Nov 4th and 802.11i-D7 due Nov 9th). From petri.jokela@nomadiclab.com Fri Oct 31 07:52:00 2003 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 31 07:52:00 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA24F93.5060508@nomadiclab.com> References: <3FA12A84.3050000@nomadiclab.com> <3FA24C60.9010006@Sun.COM> <3FA24F93.5060508@nomadiclab.com> Message-ID: <3FA26083.701@nomadiclab.com> Pekka Nikander wrote: > Therefore I would suggest that we rename the SAs and SPIs > once more: > > SA-I => SA-RI > SPI-I => SPI-RI > SA-R => SA-IR > SPI-R => SPI-IR > > This explicitly indicates the direction of the SAs, making > it unambigous. > > Unless I am mistaken once more, it sounds like both HIPL > and we have to reverse key usage in our implementations. > That shouldn't be a big deal. HIPL had it correctly (with this interpretation in mind) before yesterday, but they changed it according to our interpretation. It should not be too bad to change the order of the keys (once more ;-). But, anyway, it would be very convenient if everyone uses the same definitions :-) If we define also the HIP keys in the same way, we would get: 9. HIP KEYMAT ... HIP-IR encryption key for Initiator's outgoing HIP packets HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets HIP-RI encryption key (currently unused) for Responder's outgoing HIP packets HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets SA-IR ESP encryption key for Initiator's outgoing traffic SA-IR ESP authentication key for Initiator's outgoing traffic SA-RI ESP encryption key for Responder's outgoing traffic SA-RI ESP authentication key for Reponder's outgoing traffic The IR and RI denotes the direction of the traffic where the key is applied. The IR describes "from the Initiator to the Responder"-direction and the RI the other direction. ... and in Chapter 11: Pekka's text (with SA-IR etc. modifications). > --Pekka > > > -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com From pekka.nikander@nomadiclab.com Fri Oct 31 08:10:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 31 08:10:01 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA26083.701@nomadiclab.com> References: <3FA12A84.3050000@nomadiclab.com> <3FA24C60.9010006@Sun.COM> <3FA24F93.5060508@nomadiclab.com> <3FA26083.701@nomadiclab.com> Message-ID: <3FA26647.9040902@nomadiclab.com> Petri Jokela wrote: > 9. HIP KEYMAT > > ... > HIP-IR encryption key for Initiator's outgoing HIP packets > HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets > HIP-RI encryption key (currently unused) for Responder's outgoing HIP > packets > HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets > SA-IR ESP encryption key for Initiator's outgoing traffic > SA-IR ESP authentication key for Initiator's outgoing traffic > SA-RI ESP encryption key for Responder's outgoing traffic > SA-RI ESP authentication key for Reponder's outgoing traffic > > The IR and RI denotes the direction of the traffic where the key is > applied. The IR describes "from the Initiator to the > Responder"-direction and the RI the other direction. > > ... > > > and in Chapter 11: > > Pekka's text (with SA-IR etc. modifications). Looks good. --Pekka From Julien.Laganier@Sun.COM Fri Oct 31 09:09:02 2003 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 31 09:09:02 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development In-Reply-To: <3FA26647.9040902@nomadiclab.com> References: <3FA12A84.3050000@nomadiclab.com> <3FA26083.701@nomadiclab.com> <3FA26647.9040902@nomadiclab.com> Message-ID: <200310311539.47225.julien.laganier@sun.com> On Friday 31 October 2003 14:40, Pekka Nikander wrote: > Petri Jokela wrote: > > 9. HIP KEYMAT > > > > ... > > HIP-IR encryption key for Initiator's outgoing HIP packets > > HIP-IR integrity (HMAC) key for Initiator's outgoing HIP packets > > HIP-RI encryption key (currently unused) for Responder's outgoing HIP > > packets > > HIP-RI integrity (HMAC) key for Responder's outgoing HIP packets > > SA-IR ESP encryption key for Initiator's outgoing traffic > > SA-IR ESP authentication key for Initiator's outgoing traffic > > SA-RI ESP encryption key for Responder's outgoing traffic > > SA-RI ESP authentication key for Reponder's outgoing traffic > > > > The IR and RI denotes the direction of the traffic where the key is > > applied. The IR describes "from the Initiator to the > > Responder"-direction and the RI the other direction. > > > > ... > > > > > > and in Chapter 11: > > > > Pekka's text (with SA-IR etc. modifications). > > Looks good. Fine with me too. Thanks, --julien From thomas.r.henderson@boeing.com Fri Oct 31 12:12:02 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Oct 31 12:12:02 2003 Subject: [Hipsec] Issues for draft-moskowitz-hip-08 further development Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5CE3@xch-nw-27.nw.nos.boeing.com> for what it's worth, I also agree with Julien's interpretation and the proposed revised draft text (and I hazily remember,=20 when testing with Andrew in March, that one of us needed to=20 flip the keys because we had interpreted it differently). However, regarding the last paragraph in section 9, it currently states in a roundabout way that the HIP keys are only drawn=20 for "initial" case. This could be more explicit. That is, any=20 NES causes new ESP keys only to be drawn-- if an association wants=20 to change its HIP keys, it must restart the exchange by sending I1. Suggested last paragraph rephrase: "The four HIP keys are only drawn from KEYMAT during a HIP I1->R2 exchange. Subsequent rekeys using NES will only draw=20 the four ESP keys from KEYMAT. Section 8.9 describes the rules for reusing or regenerating KEYMAT based on the NES exchange." =20 From thomas.r.henderson@boeing.com Fri Oct 31 18:03:01 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Oct 31 18:03:01 2003 Subject: [Hipsec] HIP KEYMAT clarification Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5CEC@xch-nw-27.nw.nos.boeing.com> Also in Sec. 9, "Sort(HIT-I | HIT-R) is defined as the numeric network byte=20 order comparison of the HITs, with lower HIT preceding higher HIT, resulting in the concatenation of the HITs in the said order." first, I don't think that network vs host byte order is germane to the comparison operation-- although it is germane to the byte ordering of the hash material. Second, this=20 description does not clarify whether the 128-bit number=20 is considered to be signed vs. unsigned. Suggested new text: "Sort(HIT-I | HIT-R) is defined as the network byte order=20 concatenation of the two HITs, with the smaller HIT preceding the larger HIT, resulting from the numeric comparison of the=20 two HITs interpreted as positive (unsigned) 128-bit integers=20 in network byte order." Tom