From petri.jokela@nomadiclab.com Fri Oct 1 03:14:03 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 1 02:14:03 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <414DF55F.7020802@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> Message-ID: <415D056C.2070707@nomadiclab.com> Yogesh Prem Swami wrote: > Okay, the minimal changes required in the present HIP key exchange is > to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in > the HMAC of message 4 (shown in the message exchange below). Note > that the present protocol in the draft looks fairly secure, but as SIGMA > paper points out encryption is not the right method to prove possession > of session key (but the attack that the paper describes in the presence > of stream cipher doesn't apply here). So while the encrypted token > { PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token > guarantees that identity mis-binding attack cannot be carried out, > it's still better to use HMAC, IMO. (Besides we have a proof that > HMAC based scheme is secure.) > > I have also added nonce-I and nonce-R in all these message. This is > important to allow parallel SA creation, and allow cases where both > initiator and responder choose pre computed g^i and g^r (this can > happen, unless the draft explicitly prevents it). The nonce should > be used in deriving the session keys. Currently we have the ECHO REQ/REPLY in R1/I2. This nonce would replace it. Any opinions on this list? > So the key exchange with minimum change should look something like: > > 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > > 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > SIG( HIT-R, g^r, PUBLIC_KEY-R) > > > 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > SIG( HIT-I, HIT-R, SPI, g^i, > { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > > 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > has changed */ > According to the new HMAC stuff (including NONCE parameter instead of ECHO parameters), packets would look something like: NONCE parameter contains both nonce-I and nonce-R values, zero if not available. HOST_ID contains both the PUBLIC_KEY and the Domain-ID I1: IP ( HIP ( NONCE ) ) R1: IP ( HIP ( NONCE, [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, HOST_ID, HIP_SIGNATURE_2 )) R1 signature: HIP packet with the following fields zeroed: HIT-I, header checksum and Random #I. NONCE also zeroed to support precreated R1s? I2: IP ( HIP ( NONCE, SPI, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, HIP_SIGNATURE, HMAC ) ) I2 signature: everything covered I2 HMAC: (g^xy, HIT-I, HOST_ID(initiator) ) R2: IP ( HIP ( NONCE, SPI, HMAC, HIP_SIGNATURE ) ) R2 HMAC: (g^xy, HIT-R, SPI-R, HOST_ID(responder) ) > Couple of observations about this key exchange: > > A) The identity of Responder cannot be concealed even against the > passive attack. The HOST_ID in message-2 is required so that the > Initiator can get the public-key to verify the SIGNATURE from > responder. > > B) The identity of Initiator cannot be concealed against an active > attacker unless g^r is covered in SIGNATURE calculation in > message-2. (So keep section-7 description and change section-4 text) > > (A) and (B) together means that if we want to get responders ID > protection then we need to severely reorganize the messages. I think that at this point we are not willing to make radical changes. Any opinions? > > Yogesh From petri.jokela@nomadiclab.com Fri Oct 1 05:16:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 1 04:16:01 2004 Subject: [Hipsec] Basehip: pre1 version of 01 Message-ID: <415D21ED.1040205@nomadiclab.com> I uploaded the pre1 version of basehip draft -01 to our server. There are some editions since 00. See the diff-file. http://hip4inter.net/drafts.php BR, Petri From jeffrey.m.ahrenholz@boeing.com Fri Oct 1 12:12:02 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Fri Oct 1 11:12:02 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> A couple of questions about this nonce: - Does including the nonce in R1 affect the R1 properties of being stateless, precomputed? - One motivation for the nonce is for allowing parallel SA creation. Yogesh's example was having 3 different SAs between the same hosts at the same time, for three different TCP connections. How does this work after all of the HIP SAs are set up? It seems you need to use port numbers then to disambiguate which packets flow into which SAs/SPI. Would the port numbers need to be included in the HIP exchange, or how does the responding side (for example) know the specifics of how to set up its SAs and policies? -Jeff > > I have also added nonce-I and nonce-R in all these message. This is > > important to allow parallel SA creation, and allow cases where both > > initiator and responder choose pre computed g^i and g^r (this can > > happen, unless the draft explicitly prevents it). The nonce should > > be used in deriving the session keys. >=20 > Currently we have the ECHO REQ/REPLY in R1/I2. This nonce=20 > would replace=20 > it. Any opinions on this list? From thomas.r.henderson@boeing.com Tue Oct 5 00:48:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Mon Oct 4 23:48:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> I plan to submit this draft as WG version -00 in a few days, but have put it up for any early comments: http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt I have tried to address the issues that people have raised on the list, and issues that have been discovered upon implementing the previous draft version. Below is a summary of open issues: Update on HIP mobility management open issues --------------- Note: The first four issues are logged at the issue tracker. The remainder are issues that have arisen during revision of the text, and open issues raised on the mailing list. On the hip-mm issue tracker, I would suggest to keep issues 1, 2, and 3 open, close issue 4, and add 6, 10, and 11 (below) to the issue tracker. 1. (Roundup issue tracker #1): Potential conflict in updating SPI values Suggested resolution: Keep open. This issue pertains to whether=20 we can abandon the address group abstraction. We agreed to leave it open until we had more insight. 2. (Roundup issue tracker #2): Problems with middleboxes Suggested resolution: Keep open. Middlebox traversal needs to be considered more carefully before this issue can be closed. For example, should one-way REAs be deprecated? 3. (Roundup issue tracker #3): address check RR design Suggested resolution: Keep open. The use of ECHO_REQUEST/REPLY has plugged the main issue raised here, but additional work ongoing in mobike and multi6 design team on failover detection and validation of alternate addresses that may apply also to HIP. 4. (Roundup issue tracker #4): Use of multiple SAs Suggested resolution: Close this issue (resolved). 5. REA parameter type is "to be defined" Suggested resolution: Tentatively, we have used the value "3" in our implementation. The desire has been to keep REA forward in the list of parameters, to make middlebox parsing easier. Whether REA should precede SPI (value "1") or vice versa might be debatable. =20 6. Bidirectionality of NES conflicting with unidirectionality of SAs and REA in multihoming case Mika has suggested in a recent mail that, when there are multiple SAs in a REA, and REA is paired with NES, that it can become ambiguous as to which SA should be rekeyed upon receipt of a REA/NES. Suggested resolution: Add a note to the text that, in the case of multihoming with multiple SAs, it is RECOMMENDED to associate SAs in pairs, and that when a NES is received for a particular SA, the peer should rekey the paired SA. Also, state that using asymmetrically set up SAs is experimental,=20 and may fail to interoperate. Also, issue should be opened in issue tracker. 7. The issue was raised on the list whether there needs to be an API to allow an application to select the source or destination IP address when there are multiple choices. Suggested resolution: Should be left outside of the draft, or discussed in an appendix. For now, there is no proposed text that would address this issue. =20 8. Discussion on the use of multihomed SAs for load balancing Suggested resolution: There are many unsolved issues with respect to load balancing across multiple addresses. For now,=20 we recommend that multihoming is just used/specified for=20 failover purposes, although experimentation is recommended. 9. If HIP negotiates base exchange using link locals, and one host moves, it will not be able to find its peer Suggested resolution: State that a host SHOULD provide its peer with a globally reachable IP address instead of relying exclusively on link-local addresses. 10. Should REA be included in R2 or R1 (R1 is presently specified in text)? Note that there is some conflict in saying that, when REA=20 is included in R1 and it includes a new preferred address,=20 that the puzzle solution MUST be valid for both responder=20 addresses. The conflict is in using Appendix D (base spec)=20 mapping functions. Suggested resolution: Open, but leaning towards recommending inclusion in R2 instead of R1, unless the reason for putting it in R1 is (re)discovered. Also, issue should be opened in issue tracker. 11. Use of SPI parameter when REA is present-- is it necessary? Suggested resolution: Open until middlebox implications are better understood. Also, issue should be opened in issue tracker. From miika@iki.fi Tue Oct 5 03:06:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Oct 5 02:06:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: On Mon, 4 Oct 2004, Henderson, Thomas R wrote: > 9. If HIP negotiates base exchange using link locals, and one > host moves, it will not be able to find its peer > > Suggested resolution: State that a host SHOULD provide its > peer with a globally reachable IP address instead of relying > exclusively on link-local addresses. (the same goes for site-local addresses) > 10. Should REA be included in R2 or R1 (R1 is presently > specified in text)? > > Note that there is some conflict in saying that, when REA > is included in R1 and it includes a new preferred address, > that the puzzle solution MUST be valid for both responder > addresses. The conflict is in using Appendix D (base spec) > mapping functions. > > Suggested resolution: Open, but leaning towards recommending > inclusion in R2 instead of R1, unless the reason for putting > it in R1 is (re)discovered. > > Also, issue should be opened in issue tracker. I'd vote for the inclusion in the R2. This way, the R1s don't have to be prebuilt every time the responder moves. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From miika@iki.fi Tue Oct 5 03:29:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Oct 5 02:29:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <415D056C.2070707@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <415D056C.2070707@nomadiclab.com> Message-ID: On Fri, 1 Oct 2004, Petri Jokela wrote: > > I have also added nonce-I and nonce-R in all these message. This is > > important to allow parallel SA creation, and allow cases where both > > initiator and responder choose pre computed g^i and g^r (this can > > happen, unless the draft explicitly prevents it). The nonce should > > be used in deriving the session keys. > > Currently we have the ECHO REQ/REPLY in R1/I2. This nonce would replace > it. Any opinions on this list? Seems like this won't affect the stateliness of responder, so I guess the change is ok. > > Couple of observations about this key exchange: > > > > A) The identity of Responder cannot be concealed even against the > > passive attack. The HOST_ID in message-2 is required so that the > > Initiator can get the public-key to verify the SIGNATURE from > > responder. > > > > B) The identity of Initiator cannot be concealed against an active > > attacker unless g^r is covered in SIGNATURE calculation in > > message-2. (So keep section-7 description and change section-4 text) > > > > (A) and (B) together means that if we want to get responders ID > > protection then we need to severely reorganize the messages. > > I think that at this point we are not willing to make radical changes. > Any opinions? Agree. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkousa@cc.hut.fi Tue Oct 5 06:14:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 5 05:14:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: One possible Denial of Service attack occurred in my mind: A host could fake a creation of a new SA causing resource consumption at the peer host. Host A sends UPDATEs according to section 5.2 Host multihoming, REA containing addresses as much as there are room in the UPDATE, NES with Old SPI=New SPI=some_index, and of course SEQ. Actually host A does not create any SAs, it just sets the SPI value. Then assume that host A is able to respond to B from the addresses included in the REA when B will be sending reply UPDATEs. When the peer host B receives the UPDATE, it thinks that the peer has really created a new SA, so it stores the addresses (memory usage) and creates a new SA (heavy operation, memory usage), and acknowledges the A's UPDATE. Then A acknowledges the B's UPDATE. At this time B is quite surely finished creating the SA, and it starts verifying the addresses. Now the evil host A repeats the procedure, with the only difference of just increasing the index number in NES. B creates again a new SA and stores the addresses. Repeat this for a long time and host B is out of memory. Surely host B will free the memory reserved for the addresses under verification, if it will not receive any ACKs for them. This will still be slower than A's ability to allocate B's memory using fake UPDATEs. Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs allowed (send NOTIFY if SA was not created ?). From mkousa@cc.hut.fi Tue Oct 5 06:37:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 5 05:37:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: On Mon, 4 Oct 2004, Henderson, Thomas R wrote: -> 4. (Roundup issue tracker #4): Use of multiple SAs -> -> Suggested resolution: Close this issue (resolved). How was this resolved (I forgot..) ? The issue tracker shows only one posting about this issue. >From the issue tracker #4: "is there still a need to create a new SA for each new address put in use?". Why create separate SAs even for the IP addresses ? If each address would have its own SA and therefore own SPI, how can you assign them to SPI groups as in Figure 2 ? Somehow I think creating one SA per one peer address is overkill. I've been playing with "same SA for all addresses belonging to the same SPI", as in Figure 2. I have managed to create multiple simultaneous SAs, but I do not have support for REAs yet. -> 6. Bidirectionality of NES conflicting with unidirectionality -> of SAs and REA in multihoming case -> -> Mika has suggested in a recent mail that, when there are -> multiple SAs in a REA, and REA is paired with NES, that -> it can become ambiguous as to which SA should be rekeyed -> upon receipt of a REA/NES. -> -> Suggested resolution: Add a note to the text that, in the -> case of multihoming with multiple SAs, it is RECOMMENDED to -> associate SAs in pairs, and that when a NES is received for -> a particular SA, the peer should rekey the paired SA. -> Also, state that using asymmetrically set up SAs is experimental, -> and may fail to interoperate. -> -> Also, issue should be opened in issue tracker. I would like to see what is the definition for a "paired SA". How it is related to the peer's SAs and how it is associated when a new SA is created. -> 11. Use of SPI parameter when REA is present-- is it necessary? I have no experience yet. -> Suggested resolution: Open until middlebox implications are -> better understood. -> -> Also, issue should be opened in issue tracker. Then we would have SPIs in three places in the same packet. REA, NES, and SPI. Messy ? Also the SPI selection algorithm for the parameter would be nice. From mkousa@cc.hut.fi Tue Oct 5 08:55:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 5 07:55:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: Comments on address verification: Looks like there is a lot of text which assume the situation as if there is always only one address listed in the REA. That causes misinterpretation (for me at least) in sentences such as: -Section 4.2 Address verification, "A simple technique to verify addresses is to send an UPDATE to the host at the new address." and "If the peer host is rekeying by sending an UPDATE with NES to the new address, the arrival of data on the new SPI can also be used to verify the address." Does this verify the reachability of all addresses listed in the REA ? No. Shouldn't this be "For each of the listed addresses in the REA, .." ? Something like in draft mm-00 section 4.3 Address verification: "To acknowledge that it has received the REA, and to initiate an address check, the HIP host receiving a REA immediately sends an AC to all addresses mentioned in the REA." -Section 5.1 Mobility with single SA pair, "Upon obtaining a new IP address, the mobile host sends a REA parameter to the peer host in an UPDATE message. The REA indicates the following: the new IP address, the SPI associated with the new IP address, the address lifetime, and whether the new address is a preferred address. .. The UPDATE messages sent from the peer back to the mobile are sent to the newly advertised address." And the "newly advertised address" is defined here as .. ? Preferred address in the REA, if there is any (and what if not) ? All of the addresses ? Hmm..but wait..ahh..the reader must notice the word "messages", so by deduction this section should also say "for all of the addresses a separate UPDATE is sent by the peer..", right ? From mkousa@cc.hut.fi Tue Oct 5 10:26:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 5 09:26:00 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: In section 5.1 Mobility with single SA pair, "Readdress without rekeying, but with address check": When a mobile hosts sends UPDATE(REA, SEQ) (Figure 3), must it be processed in any state (established or rekeying) ? How it should be processed upon receive ? Can we skip some tests mentioned in the base draft's section 8.11 Processing UPDATE packets ? From pekka.nikander@nomadiclab.com Tue Oct 5 14:38:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 5 13:38:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: > One possible Denial of Service attack occurred in my mind: I don't find this very serious. Firstly, the host must be already communicating in order for this to happen. Hence, there should be some minimum level of trust between the hosts. Secondly, creating an SA is not that heavy since it does not involve any public key crypto, just hash functions in order to generate new key material. > Solutions: rate limit UPDATE handling, mamimum amount of simultaneous > SAs > allowed (send NOTIFY if SA was not created ?). I agree that each implementation should have some sensible, configurable limit of how many SAs it by default is creating for peer hosts. I think something like 5 should be more than enough for the time being. Anyway, I think it would be good to have a brief explanation of this in the Security Considerations section, with a RECOMMENDATION of having an upper bound for parallel SAs per host, with some RECOMMENDED default value. Would you Mika be willing to write some raw text? --Pekka From mkousa@cc.hut.fi Tue Oct 5 19:33:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Tue Oct 5 18:33:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: On Tue, 5 Oct 2004, Pekka Nikander wrote: -> > One possible Denial of Service attack occurred in my mind: -> -> I don't find this very serious. Firstly, the host must be -> already communicating in order for this to happen. Hence, -> there should be some minimum level of trust between the hosts. Surely, but by assumption the evil host is willing to spend some cpu time needed for the base exchange. After a couple of seconds it can launch this long lasting attack against the victim. Compared to the effects this causes, the cpu power needed for the base exchange is close to zero. A really naive implementation might assume that if the base exchange was successful, then the rest of the communication could be consired as trustworthy. -> Secondly, creating an SA is not that heavy since it does not -> involve any public key crypto, just hash functions in order -> to generate new key material. Ah, all right then. But anyway, creation and updating SAs need quite a lot more resources elsewhere than just on HIP level, SA related stuff in the kernel etc. -> > Solutions: rate limit UPDATE handling, mamimum amount of simultaneous SAs -> > allowed (send NOTIFY if SA was not created ?). -> -> I agree that each implementation should have some sensible, -> configurable limit of how many SAs it by default is creating -> for peer hosts. I think something like 5 should be more than -> enough for the time being. Assuming that each interface has its own SA, as described in the current draft, this might be sufficient. But if we follow the proposals which suggest own SA for each of the (IP) addresses, five might be too low. I do not know so much about real life situations, such as how many addresses some busy host might have at a time. Five SAs is probably sufficient for 99% of the time. Limit could also be dynamic, e.g. based on the trust. That is, policy issue. -> Anyway, I think it would be good to have a brief explanation -> of this in the Security Considerations section, with a -> RECOMMENDATION of having an upper bound for parallel SAs per -> host, with some RECOMMENDED default value. -> -> Would you Mika be willing to write some raw text? Let's see if I can write some short text about this issue during this week, something like we have been discussing right now. From pekka.nikander@nomadiclab.com Wed Oct 6 07:44:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 6 06:44:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> > Ah, all right then. But anyway, creation and updating SAs need quite a > lot > more resources elsewhere than just on HIP level, SA related stuff in > the > kernel etc. Depending on implementation that may or may not be that much. > Five SAs is probably sufficient for 99% of the time. Agreed. We need some conservative default; hence the suggestion for five. > Limit could also be dynamic, e.g. based on the trust. That is, policy > issue. Sure. The text should reflect this, being suggestive and outlining some sensible default values. > -> Would you Mika be willing to write some raw text? > > Let's see if I can write some short text about this issue during this > week, something like we have been discussing right now. Good! --Pekka PS. If you want me to react to your mail quickly, even if it is a mailing list reply, please make the To: directly to me (or at least CC: me). Otherwise my filters will direct it to a separate folder, and it may take a few days before I read it. From mkousa@cc.hut.fi Wed Oct 6 10:16:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Oct 6 09:16:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> Message-ID: A conflict in 5th paragraph of section 7.1 Sending REAs: "All addresses corresponding to the SPI have the same lifetime." But the rest of the discussion on address lifetimes tells that each address have their own lifetimes. From thomas.r.henderson@boeing.com Wed Oct 6 13:17:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 6 12:17:00 2004 Subject: [Hipsec] (corrected) preview of draft-ietf-hip-mm-00 for review Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Henderson, Thomas R=20 > Sent: Monday, October 04, 2004 9:56 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review >=20 >=20 > I plan to submit this draft as WG version -00 in a few days, > but have put it up for any early comments: >=20 > http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt >=20 I made a mistake and provided Petri with only a partially updated draft. He has now posted the draft I originally intended to preview post (open issues list is the same): http://hip4inter.net/documentation/drafts/draft-ietf-hip-mm-00.txt Below are the diffs from what was originally posted-- I haven't yet processed the comments that have been coming on the list. Key to this diff file: < Previously posted, modified draft-nikanker-hip-mm-02 > Updated version at new URL above (draft-ietf-hip-mm-00) 12c12 < draft-nikander-hip-mm-02 --- > draft-ietf-hip-mm-00 350,352c350,352 < In the HIP base protocol specification [3], it is defined how two < hosts exchange their Host Identifiers and establish a pair of ESP < Security Associations (SA). =20 --- > The HIP base protocol specification [3] defines how two hosts > exchange their Host Identifiers and establish a pair of ESP = Security > Associations (SA). =20 528a529,531 > It is not specified how a host knows whether or not middleboxes = might > lie on its path, so a conservative assumption may be to always > include the SPI parameter. 544a547,553 > In general, when multiple addresses are used for a session, there = is > the question of using multiple addresses for failover only or for > load-balancing. Due to the implications of load-balancing on the > transport layer that still need to be worked out, this draft = assumes > that multiple addresses are used primarily for failover. An > implementation may use ICMP interactions, reachability checks, or > other means to detect the failure of an address. 639c639 < about changes of IP addresses on one of its SPIs. The readdressing --- > about changes of IP addresses on affected SPIs. The readdressing 744a745,748 > Hosts that use link-local addresses as source addresses in their = HIP > handshakes may not be reachable by a mobile peer host unless a > globally routable address is provided either in the initial = handshake > or via the REA parameter. 791c795 < implicitly affiliated with different addresses. --- > implicitly affiliated with different source addresses. 803a808,813 > When rekeying in a multihoming situation in which there is an > asymmetric number of SAs between two hosts, a respondent to the = NES/ > UPDATE procedure may have some ambiguity as to which inbound SA it > should update in response to the peer's UPDATE. In such a case, = the > host SHOULD choose an SA corresponding to the inbound interface on > which the UPDATE was received. 881,890d890 < 5.7 Initiating the protocol in R1 or I2 <=20 < A Responder host MAY include one or more REA parameters in the R1 < packet that it sends to the Initiator. These parameters MUST be < protected by the R1 signature. If the R1 packet contains REA < parameters, the Initiator SHOULD send the I2 packet to the new < preferred address. The Responder MUST make sure that the puzzle < solution is valid BOTH for the initial IP destination address used < for I1 and for the new preferred address. The I1 destination = address < and the new preferred address may be identical. 899a900,908 > 5.7 Initiating the protocol in R1 or I2 >=20 > A Responder host MAY include one or more REA parameters in the R1 > packet that it sends to the Initiator. These parameters MUST be > protected by the R1 signature. If the R1 packet contains REA > parameters, the Initiator SHOULD send the I2 packet to the new > preferred address. The I1 destination address and the new = preferred > address may be identical. >=20 1040c1096,1098 < each of them must be matched with a NES parameter: --- > and at least one of the REA parameters is matched with a NES > parameter, then each REA must be matched with a NES parameter, to > avoid ambiguity: 1112c1168 < a REA with the SPI field within the REA set to the new address, and --- > a REA with the SPI field within the REA set to the new SPI, and = also 1181a1238,1239 > 5. Mark all addresses at the address group that were NOT listed in > the REA parameter as DEPRECATED. 1252c1324 < ICMP erro messages arrive that deprecate the preferred address, --- > ICMP error messages arrive that deprecate the preferred = address, 1377c1433 < return routability check provides some assurance that the given --- > address reachability check provides some assurance that the given From mkousa@cc.hut.fi Wed Oct 6 20:53:01 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Wed Oct 6 19:53:01 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> Message-ID: Here is the initial text to the Security Considerations section I wrote about the issue on maximum allowed outbound SAs. I'm not so familiar with the correct usage of these capitalized RECOMMENDED/SHOULD/MUST/etc. words, but you might want to edit this text anyway. The text digests the mailing list discussion, nothing new was added. When a host has an additional network interface to use, the host might want to inform its peer about it by sending the SPI of the newly created SA associated with the network interface. Consequently, information on this SA must also be stored in the peer host. Because this operation requires allocation and usage of limited resources, such as memory and cpu, it is RECOMMENDED that there is an upper bound limit for the number of simultaneous outgoing SAs a host is willing to create. Because the exact number of network interfaces the peer host could have is usually not known in advance, it is RECOMMENDED that this value is configurable during runtime or at least at compile time. The suggested RECOMMENDED default value of five (5) maximum outbound SAs is assumed to be enough for most of the situations. In general, the value depends on enforced policy and the level of trust a host has against its peer host. Lower level of trust SHOULD decrease the maximum value. For trusted systems the value could even be unlimited, but this is highly NOT RECOMMENDED. From pekka.nikander@nomadiclab.com Thu Oct 7 01:27:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 7 00:27:00 2004 Subject: [Hipsec] preview of draft-ietf-hip-mm-00 for review In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060880@xch-nw-27.nw.nos.boeing.com> <1EB95D18-178E-11D9-A0F5-000D9331AFB0@nomadiclab.com> Message-ID: <9D810CBE-1822-11D9-BF2A-000D9331AFB0@nomadiclab.com> > Here is the initial text to the Security Considerations section I wrote > about the issue on maximum allowed outbound SAs. I'm not so familiar > with > the correct usage of these capitalized RECOMMENDED/SHOULD/MUST/etc. > words, > but you might want to edit this text anyway. The text digests the > mailing > list discussion, nothing new was added. Tnx. A slightly edited version below. --Pekka Managing multiple outgoing Security Associations for a peer host consumes some memory and also some CPU resources. Because the HIP protocol has been designed to support communication with peer hosts that are not fully trusted, there SHOULD be a means to limit the amount of resources reserved per any given peer. In particular, it is RECOMMENDED that there is a total upper bound limit and a per-peer upper bound limit for the number of simultaneous outgoing SAs a host is willing to create. Because the exact number of network interfaces a given peer host could have is usually not known in advance, it is RECOMMENDED that the upper limit values be user configurable. The RECOMMENDED default value of five (5) outbound SAs per peer host is assumed to be enough for most of the situations. In general, the value depends on the enforced policy and the level of trust a host has against the given peer host. Lower level of trust, e.g. HIP associations with hosts using non-public keys, MAY decrease the maximum value. For trusted systems the upper bound may be increased or even lifted. To support smooth handovers, the upper bound MUST always be at least two (2). [Rationale for the keywords: In general, these advice deal with local resource consumption, and do not directly affect interoperability. However, hosts that have a high number of IP addresses may need to be aware of these recommendations, in order to better react to their peer's behaviour. (The peer may be limiting the number of SAs.) Not following the advice may lead to DoS vulnerabilities, hence the RECOMMENDATION. On the other hand, decreasing the default value may lead to interoperability problems if the other host is expecting the default upper bound of five. Hence the MAY for reducing the upper bound, and MUST for at least two outgoing SAs per host.] From Gonzalo.Camarillo@ericsson.com Thu Oct 7 02:44:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Thu Oct 7 01:44:01 2004 Subject: [Hipsec] Agenda requests Message-ID: <4164E796.6030603@ericsson.com> Folks, we are officially starting to gather agenda requests for the HIP WG meeting in Washington. You should send your agenda request to the chairs indicating what you want to present, any related documents, and how long you want your agenda-slot to be. Thanks, Gonzalo HIP co-chair From petri.jokela@nomadiclab.com Thu Oct 7 03:45:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Oct 7 02:45:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> Message-ID: <4164F590.9040204@nomadiclab.com> Ahrenholz, Jeffrey M wrote: > A couple of questions about this nonce: > > - Does including the nonce in R1 affect the R1 properties of being > stateless, precomputed? As far as I can see, it doesn't affect. > - One motivation for the nonce is for allowing parallel SA creation. > Yogesh's example was having 3 different SAs between the same hosts at > the same time, for three different TCP connections. How does this work > after all of the HIP SAs are set up? It seems you need to use port > numbers then to disambiguate which packets flow into which SAs/SPI. > Would the port numbers need to be included in the HIP exchange, or how > does the responding side (for example) know the specifics of how to set > up its SAs and policies? So, creating multiple SAs would require some information change between the hosts about the usage of the connections. I think that it is not feasible to include it in HIP v1. A "hack" would be to use multiple HIs (HITs) for creating separate SAs between the hosts. Not a nice solution and solves the problem only from the Initiator point of view, but it wouldn't require any additional negotiation between the hosts. There are not too many opinions on this issue on the list? What shall we do with it: 1) add the NONCE parameter and remove ECHO REQ/RESP, 2) leave the draft as it is now and think this again in HIP v2. /petri From Julien.Laganier@Sun.COM Thu Oct 7 04:25:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Oct 7 03:25:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? In-Reply-To: <4164F590.9040204@nomadiclab.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> Message-ID: <200410071033.29140.julien.laganier@sun.com> On Thursday 07 October 2004 09:51, Petri Jokela wrote: > Ahrenholz, Jeffrey M wrote: > > A couple of questions about this nonce: > > > > - Does including the nonce in R1 affect the R1 properties of > > being stateless, precomputed? > > As far as I can see, it doesn't affect. > > > - One motivation for the nonce is for allowing parallel SA > > creation. Yogesh's example was having 3 different SAs between the > > same hosts at the same time, for three different TCP connections. > > How does this work after all of the HIP SAs are set up? It seems > > you need to use port numbers then to disambiguate which packets > > flow into which SAs/SPI. Would the port numbers need to be > > included in the HIP exchange, or how does the responding side > > (for example) know the specifics of how to set up its SAs and > > policies? > > So, creating multiple SAs would require some information change > between the hosts about the usage of the connections. I think that > it is not feasible to include it in HIP v1. I agree. > A "hack" would be to use multiple HIs (HITs) for creating separate > SAs between the hosts. Not a nice solution and solves the problem > only from the Initiator point of view, but it wouldn't require any > additional negotiation between the hosts. You can create separate SAs based on different NONCES, and then the hack is when an outbound packet enters ESP, the SA selection is made locally, based on Traffic Selectors including TCP/UDP ports for example, and not enforced by the ESP receivers, which hence doesn't need to be aware of the local TSs used by the ESP sender. This allows for separation of multiple connexions by the sender, without having to negociate TSs with TCP/UDP ports numbers in HIP itself. > There are not too many opinions on this issue on the list? What > shall we do with it: 1) add the NONCE parameter and remove ECHO > REQ/RESP, 2) leave the draft as it is now and think this again in > HIP v2. I would vote for adding NONCE, as it make HIP SIGMA-compliant, and keep ECHO_REQ/REP. IMHO this is a minor addition which buys us provable security by conforming to the SIGMA core protocol, so I believe we don't need to wait until v2 to handle NONCEs. My 2 cents, --julien From petri.jokela@nomadiclab.com Thu Oct 7 07:10:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Oct 7 06:10:01 2004 Subject: [Hipsec] BaseHIP Issue #42 Message-ID: <416525B8.6090604@nomadiclab.com> The key exchange described on page 12 of the base draft was a bit unclear. So, a new proposal: 4.1 HIP base exchange The base HIP exchange serves to manage the establishment of state between an Initiator and a Responder. During the exchange, an IPsec Security Association is created between the hosts. The last three packets of the exchange, R1, I2, and R2, constitute a standard authenticated Diffie-Hellman key exchange for session key generation. The Initiator first sends a trigger packet, I1, to the Responder. The packet contains only the HIT of the Initiator and possibly the HIT of the Responder, if it is known. The second packet, R1, starts the actual exchange. It contains a puzzle, that is, a cryptographic challenge that the Initiator must solve before continuing the exchange. In addition to that, it contains the initial Diffie-Hellman parameters and a signature, covering the message partly. Some fields are left outside the signature to support pre-created R1s. In I2 packet, the Initiator must display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 contains also Diffie-Hellman parameter that carries needed information for the Responder. The packet is signed by the sender. The R2 packet finalizes the 4-way handshake, containing the SPI value of the Responder. The packet is signed. The base exchange is illustrated below. During this D-H procedure, the hosts create an IPsec session key. Initiator Responder I1: trigger exchange --------------------------> select pre-computed R1 R1: puzzle, D-H, key, sig <------------------------- check sig remain stateless solve puzzle I2: solution, D-H, {key}, sig --------------------------> compute D-H check cookie check puzzle check sig R2: sig <-------------------------- check sig compute D-H In R1, the signature covers the packet, after setting the initiator HIT, header checksum as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any TLVs that follow the signature In I2, the signature covers the whole packet, excluding any TLVs that follow the signature. In R2, the signature and the HMAC covers the whole envelope. In this section we cover the overall design of the base exchange. The details are the subject of the rest of this memo. From mkousa@cc.hut.fi Thu Oct 7 08:07:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Oct 7 07:07:00 2004 Subject: [Hipsec] (corrected) preview of draft-ietf-hip-mm-00 for review In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060881@xch-nw-27.nw.nos.boeing.com> Message-ID: 5.7 Initiating the protocol in R1 or I2: Should there be some explicit notes about the KEYMAT index to be used when retrieving keying materials for the SA(s) if the R1 or I2 contains (multiple) REA(s) ? Or do we just assume that the implementors know what they are doing without telling them. That is, they use the current KEYMAT index right after when the HIP keys were drawn. From julien.laganier@sun.com Thu Oct 7 09:12:00 2004 From: julien.laganier@sun.com (Julien Laganier) Date: Thu Oct 7 08:12:00 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <200410071521.16054.julien.laganier@sun.com> Hi Folks, Looking at the paper "Experience with the Host Identity Protocol for Secure Mobility and Multihoming" by Henderson et al., I found that DSA signing and verification account for a huge part of the association set-up latency. Hence, I am wondering what is the rationale for HIP to specify DSA as a MANDATORY algorithm, although RSA signatures verification might be ten times faster than DSA? Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) which has reduced P.K. and signatures size, and can be as fast or faster than RSA? Thanks, --julien From jari.arkko@piuha.net Thu Oct 7 09:20:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu Oct 7 08:20:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <200410071521.16054.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> Message-ID: <416543F8.6040006@piuha.net> There used to be IPR concerns with RSA, but I believe the patents expired. ECC is a mine field of IPR, so I'd rather stay out of it if possible. I'd go for RSA, personally. --Jari Julien Laganier wrote: > Hi Folks, > > Looking at the paper "Experience with the Host Identity Protocol for > Secure Mobility and Multihoming" by Henderson et al., I found that > DSA signing and verification account for a huge part of the > association set-up latency. > > Hence, I am wondering what is the rationale for HIP to specify DSA as > a MANDATORY algorithm, although RSA signatures verification might be > ten times faster than DSA? > > Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) which > has reduced P.K. and signatures size, and can be as fast or faster > than RSA? > > Thanks, > > --julien > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From jeffrey.m.ahrenholz@boeing.com Thu Oct 7 11:35:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Thu Oct 7 10:35:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE4@xch-nw-09.nw.nos.boeing.com> > You can create separate SAs based on different NONCES, and then the=20 > hack is when an outbound packet enters ESP, the SA selection is made=20 > locally, based on Traffic Selectors including TCP/UDP ports for=20 > example, and not enforced by the ESP receivers, which hence doesn't=20 > need to be aware of the local TSs used by the ESP sender. >=20 > This allows for separation of multiple connexions by the sender,=20 > without having to negociate TSs with TCP/UDP ports numbers in HIP=20 > itself. Using this method, with the receiver not aware of the sender's local TSs, you would probably have asymmetric return traffic (i.e., returning on another SPI)(unless the receiver sets up its own TSs that happen to exactly match the sender). But I would agree that this might be more elegant than using multiple HIs. > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and=20 > keep ECHO_REQ/REP.=20 Do we need both NONCE and ECHO? > IMHO this is a minor addition which buys us provable security by=20 > conforming to the SIGMA core protocol, so I believe we don't need to=20 > wait until v2 to handle NONCEs. I think this is a good argument too. I wouldn't mind adding the nonce. Maybe note its future usefulness. If it replaces the ECHO_*, then it is not very different from the ECHO_* parameter anyway. -Jeff From jeffrey.m.ahrenholz@boeing.com Thu Oct 7 12:20:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Thu Oct 7 11:20:01 2004 Subject: [Hipsec] BaseHIP Issue #42 Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE5@xch-nw-09.nw.nos.boeing.com> Petri, > The key exchange described on page 12 of the base draft was a bit=20 > unclear. So, a new proposal: This new text is much clearer. I have a few suggested minor edits below. -Jeff The second packet, R1, starts the actual exchange. It contains a puzzle, that is, a cryptographic challenge that the Initiator must solve before continuing the exchange. In addition, it contains the initial Diffie-Hellman parameters and a signature, covering part of the message. Some fields are left outside the signature to support pre-created R1s. In the I2 packet, the Initiator must display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 also contains a Diffie-Hellman parameter that carries needed information for the Responder. The packet is signed by the sender. =20 In R1, the signature covers the packet, after setting the initiator HIT, header checksum, and the PUZZLE parameter's Opaque and Random #I fields temporarily to zero, and excluding any TLVs that follow the signature. =20 In I2, the signature covers the whole packet, excluding=20 any TLVs that follow the signature. =20 In R2, the signature and the HMAC cover the whole envelope. =20 In this section we cover the overall design of the base exchange. The details are the subject of the rest of this memo. From Julien.Laganier@Sun.COM Thu Oct 7 17:14:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Oct 7 16:14:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: References: <200407151325.14103.julien.laganier@sun.com> Message-ID: <200410072323.32301.julien.laganier@sun.com> --Boundary_(ID_slDDtQREaSofIkrNVClEkg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Friday 16 July 2004 19:00, Pekka Nikander wrote: > >> So here is my attempted approach and a close handshake that > >> can apply to HIP as well as NOID. The goal is to remove the case > >> when one end retains association state and the other end has > >> discarded it, since this seems to open up some DoS opportunity. > > > > IMHO, this scheme fills a hole in the HIP specification, > > particularly since we removed the RESYNC-related stuff. Hence, I > > am strongly in favor of adopting (and adapting) the proposed > > approach. > > > > There's a remaining question, though: Does it belongs to the > > base protocol spec, or rather to an extension? I would vote for > > the first but I'm not 100% sure... > > > > What do other people think? > > I don't have any strong opinion. If someone makes a good write up > for the base spec, I don't have anything against including it. Folks, Attached is an attempted write down containing additional sections complementing the HIP protocol specification with a CLOSE/CLOSE_ACK handshake, based on Erik's approach. Please let me know what you think, especially things still missing, and your opinion on its maturity for a possible integration within the base spec draft (-01 or later). Thanks, --julien --Boundary_(ID_slDDtQREaSofIkrNVClEkg) Content-type: text/plain; charset=iso-8859-1; name=hip_closeack.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=hip_closeack.txt The mechanism uses two time constant: UAL (Unused Association Lifetime) minutes and MSL (Maximum Segment Lifetime) minutes. ----------------------------------------------------------------- 5.4.1 HIP States UNASSOCIATED State machine start I1-SENT Initiating HIP I2-SENT Waiting to finish HIP R2-SENT Waiting to finish HIP ESTABLISHED HIP SA established REKEYING HIP SA established, but UPDATE is outstanding for rekeying CLOSING HIP SA closing, no data (ESP) can be sent E-FAILED HIP exchange failed ----------------------------------------------------------------- 5.4.2 HIP State Processes +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED Receive ESP for unknown SA, optionally send ICMP as defined in Section 6.3 and stay at UNASSOCIATED Receive CLOSE for unknown association, send CLOSE_ACK and stay at UNASSOCIATED Receive ANYOTHER, drop and stay at UNASSOCIATED +------------+ |ESTABLISHED | HIP SA established +------------+ Receive I1, send R1 and stay at ESTABLISHED Receive I2, process with cookie and possible Opaque data verification if successful, send R2, drop old SAs, establish new SA, go to R2-SENT if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPDATE, process if successful, send UPDATE in reply and go to REKEYING if failed, stay at ESTABLISHED Need rekey, send UPDATE and go to REKEYING No packet sent/received during UAL minutes, send CLOSE and go to CLOSING. Receive CLOSE, process if successful, send CLOSE_ACK and go to UNASSOCIATED if failed, stay at ESTABLISHED +---------+ | CLOSING | HIP association has not been used for UAL (Unused Association +---------+ Lifetime) minutes. Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive ANYOTHER, drop and stay at CLOSING Timeout, increment timeout sum, reset timer if timeout sum is less than UAL+MSL minutes, retransmit CLOSE and stay at CLOSING if timeout sum is greater than UAL+MSL minutes, go to UNASSOCIATED ----------------------------------------------------------------- 5.4.3 Simplified HIP State Diagram +-+ | | CLOSE received, send CLOSE_ACK V ^ +------------+ |UNASSOCIATED|<=================+-+ +------------+ | | ^ | | | CLOSE_ACK received, or | | | UAL+MSL minutes CLOSE | | | re-xmits | | CLOSE received, ^ | | send CLOSE_ACK +---------+ | | | CLOSING |>-------------------+ | +---------+ | ^ | | No packet sent/received | | for UAL min, send CLOSE | ^ | +------------+ | |ESTABLISHED |>-------------------+ +------------+ ----------------------------------------------------------------- 7.10 CLOSE - the HIP association closing packet The HIP header values for the CLOSE packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) ) Valid control bits: none The sender MUST include an ECHO_REPLY used to validate CLOSE_ACK received in response, and both an HMAC and a signature (calculated over the whole HIP envelope). The receiver peer MUST validate both the HMAC and the signature if it has a HIP association state, and MUST reply with a CLOSE_ACK containing an ECHO_REPLY corresponding to the received ECHO_REQUEST. ----------------------------------------------------------------- 7.11 CLOSE_ACK - the HIP closing acknowledgment packet The HIP header values for the CLOSE_ACK packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REPLY [, HMAC, HIP_SIGNATURE] ) ) Valid control bits: none The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope) if it has a HIP association state. The receiver peer MUST validate both the HMAC and the signature if present and it has an association state. ----------------------------------------------------------------- 8.16 Processing CLOSE packets When the host receives a CLOSE message it discards the HIP association state and responds with a CLOSE_ACK message. (The authenticity of the CLOSE message is verified using both HMAC and SIGNATURE). This processing applies whether or not the HIP association state is CLOSING in order to handle CLOSE messages from both ends crossing in flight. Once the HIP association state has been discarded any need to send data packets will trigger creating and establishing of a new HIP association, starting with sending an I1. A CLOSE message which is received when there is no HIP association state can not be verified but will result in a CLOSE_ACK response to speed up the peer discarding the HIP association in the presence of packet loss. ----------------------------------------------------------------- 8.17 Processing CLOSE_ACK packets When a host receives a CLOSE_ACK message it verifies that it is in CLOSING state and that the CLOSE_ACK was in response to the CLOSE (using the included ECHO_REPLY in response to the sent ECHO_REQUEST). It is possible to use stronger verification of the CLOSE_ACK based on optional HMAC and SIGNATURE but only for the first CLOSE message since the HIP state is discarded on its reception. Then, depending on policy, when the CLOSE_ACK response to the first CLOSE is lost, an implementation discards its HIP state by waiting for either subsequent not-signed and not-MACed CLOSE_ACK packets, or the full UAL+MSL minutes retransmission period. --Boundary_(ID_slDDtQREaSofIkrNVClEkg)-- From thomas.r.henderson@boeing.com Thu Oct 7 17:55:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 7 16:55:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Ahrenholz, Jeffrey M=20 > Sent: Thursday, October 07, 2004 8:42 AM > To: Julien Laganier; hipsec@honor.trusecure.com > Cc: Petri Jokela; Yogesh Prem Swami > Subject: RE: [Hipsec] NONCE parameter in base exchange? >=20 >=20 >=20 > > > You can create separate SAs based on different NONCES, and then the=20 > > hack is when an outbound packet enters ESP, the SA=20 > selection is made=20 > > locally, based on Traffic Selectors including TCP/UDP ports for=20 > > example, and not enforced by the ESP receivers, which hence doesn't=20 > > need to be aware of the local TSs used by the ESP sender. > >=20 > > This allows for separation of multiple connexions by the sender,=20 > > without having to negociate TSs with TCP/UDP ports numbers in HIP=20 > > itself. >=20 > Using this method, with the receiver not aware of the sender's local > TSs, you would probably have asymmetric return traffic (i.e.,=20 > returning > on another SPI)(unless the receiver sets up its own TSs that happen to > exactly match the sender). But I would agree that this might be more > elegant than using multiple HIs. Although HIP does not have any requirements document, I don't think that managing multiple parallel SAs is a strong requirement to work for=20 HIPv1. It has been stated in the architecture document that there is=20 less policy granularity in HIP than in other key exchange protocols. =20 Maybe this gets revisited in the future. >=20 > > > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and=20 > > keep ECHO_REQ/REP.=20 >=20 > Do we need both NONCE and ECHO? I don't see why we can't replace ECHO_REQ/RESP with NONCE. They are functionally the same, right? (and define a NONCE within and outside of the signature, like ECHO_REQ is presently done). >=20 > > IMHO this is a minor addition which buys us provable security by=20 > > conforming to the SIGMA core protocol, so I believe we=20 > don't need to=20 > > wait until v2 to handle NONCEs. >=20 Agreed. Tom From Julien.Laganier@Sun.COM Thu Oct 7 19:16:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Oct 7 18:16:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406088E@xch-nw-27.nw.nos.boeing.com> Message-ID: <200410080125.22712.julien.laganier@sun.com> On Thursday 07 October 2004 23:58, Henderson, Thomas R wrote: > > -----Original Message----- > > From: Ahrenholz, Jeffrey M > > Sent: Thursday, October 07, 2004 8:42 AM > > To: Julien Laganier; hipsec@honor.trusecure.com > > Cc: Petri Jokela; Yogesh Prem Swami > > Subject: RE: [Hipsec] NONCE parameter in base exchange? > > > > > > > > > You can create separate SAs based on different NONCES, and then > > > the hack is when an outbound packet enters ESP, the SA > > > > selection is made > > > > > locally, based on Traffic Selectors including TCP/UDP ports for > > > example, and not enforced by the ESP receivers, which hence > > > doesn't need to be aware of the local TSs used by the ESP > > > sender. > > > > > > This allows for separation of multiple connexions by the > > > sender, without having to negociate TSs with TCP/UDP ports > > > numbers in HIP itself. > > > > Using this method, with the receiver not aware of the sender's > > local TSs, you would probably have asymmetric return traffic > > (i.e., returning > > on another SPI)(unless the receiver sets up its own TSs that > > happen to exactly match the sender).=20 But IPsec is asymmetric, isn't it? You need two IPsec SAs, with two=20 SPIs, one in each direction to carry a single TCP connexion. Traffic=20 will return 'asymmetrically' to 'another' SPI, but return packets=20 might well flow 'symmetrically' on the IP network, i.e., on the same=20 path as forward packets (if both peers are using a single net_if wich=20 is assigned a single IP address). > > But I would agree that this=20 > > might be more elegant than using multiple HIs. > > Although HIP does not have any requirements document, I don't think > that managing multiple parallel SAs is a strong requirement to work > for HIPv1. =A0It has been stated in the architecture document that > there is less policy granularity in HIP than in other key exchange > protocols. Maybe this gets revisited in the future. I agree. For now, if one of the peers wants to spread connexions=20 amongst multiple SAs, he can use kind of "sender-side only" TSs.=20 It obtains part of the wanted effect. And if the other peer is willing=20 to play the same game then everything is fine: each TCP connexion=20 flow onto his own two IPsec SAs, on the same IP path, though the SPI=20 are different and it hasn't been specifically negotiated. =20 > > > > Do we need both NONCE and ECHO? > > I don't see why we can't replace ECHO_REQ/RESP with NONCE. They > are functionally the same, right? (and define a NONCE within and > outside of the signature, like ECHO_REQ is presently done)..=20 I dunno. BTW, NONCEs might also be useful if we add a CLOSE/CLOSEACK hanshake=20 to HIP: If a host is in state CLOSING but has data to sent, it can=20 initiates another HIP exchange with a newly created state and fresh=20 NONCE-I.=20 This way a responder receiving a packet might be able to differentiate=20 states which otherwise would have appeared to be the same. =2D-julien From jeffrey.m.ahrenholz@boeing.com Thu Oct 7 20:09:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Thu Oct 7 19:09:01 2004 Subject: [Hipsec] NONCE parameter in base exchange? Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EE6@xch-nw-09.nw.nos.boeing.com> > > > Using this method, with the receiver not aware of the sender's > > > local TSs, you would probably have asymmetric return traffic > > > (i.e., returning > > > on another SPI)(unless the receiver sets up its own TSs that > > > happen to exactly match the sender).=20 >=20 > But IPsec is asymmetric, isn't it? You need two IPsec SAs, with two=20 > SPIs, one in each direction to carry a single TCP connexion. Traffic=20 > will return 'asymmetrically' to 'another' SPI, but return packets=20 > might well flow 'symmetrically' on the IP network, i.e., on the same=20 > path as forward packets (if both peers are using a single net_if wich=20 > is assigned a single IP address). Right, I meant/should've said "i.e., returning on a SPI other than the one paired with the outgoing SPI." As this seems relevant to multihoming, this "sender-side only" traffic selector concept might be noted in the hip-mm-00 draft, if we add the NONCE. (although this might alter the concept depicted in Figure 2 (Page 8) if we have multiple SPIs using the same address...) -Jeff From Jan.Melen@nomadiclab.com Fri Oct 8 02:46:00 2004 From: Jan.Melen@nomadiclab.com (Jan Mikael Melen) Date: Fri Oct 8 01:46:00 2004 Subject: [Hipsec] NONCE parameter in base exchange? In-Reply-To: <200410071033.29140.julien.laganier@sun.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> <200410071033.29140.julien.laganier@sun.com> Message-ID: <200410080953.33603.Jan.Melen@nomadiclab.com> Hi, On Thursday 07 October 2004 11:33, Julien Laganier wrote: > > There are not too many opinions on this issue on the list? What > > shall we do with it: 1) add the NONCE parameter and remove ECHO > > REQ/RESP, 2) leave the draft as it is now and think this again in > > HIP v2. > > I would vote for adding NONCE, as it make HIP SIGMA-compliant, and > keep ECHO_REQ/REP. > > IMHO this is a minor addition which buys us provable security by > conforming to the SIGMA core protocol, so I believe we don't need to > wait until v2 to handle NONCEs. I would vote for option 1.5 so I don't have anything against renaming ECHO to NONCE if it is what makes people to sleep better ;) The functionality is the same with NONCE and ECHO as it has been pointed out several times on this list (s/ECHO/NONCE/g ;) But I won't be voting for having multiple SAs with different policies. IMHO before we can have multiple SAs with different policies we should be able to somehow inform the peer node that I'm going to use this SA only for ssh and would like to have the return packets through the SA paired to this one. Now if either end wants to use some other protocol they'll know that they'll have to create a new SA pair between the hosts or do some policy negotiation. I think that this kind of policy issues should be left to HIPv2. Regards, Jan From pekka.nikander@nomadiclab.com Fri Oct 8 04:44:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 8 03:44:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <200410072323.32301.julien.laganier@sun.com> References: <200407151325.14103.julien.laganier@sun.com> <200410072323.32301.julien.laganier@sun.com> Message-ID: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> >>>> So here is my attempted approach and a close handshake that >>>> can apply to HIP as well as NOID. The goal is to remove the case >>>> when one end retains association state and the other end has >>>> discarded it, since this seems to open up some DoS opportunity. >>> >>> IMHO, this scheme fills a hole in the HIP specification, >>> particularly since we removed the RESYNC-related stuff. Hence, I >>> am strongly in favor of adopting (and adapting) the proposed >>> approach. >> >> I don't have any strong opinion. If someone makes a good write up >> for the base spec, I don't have anything against including it. > > Attached is an attempted write down containing additional sections > complementing the HIP protocol specification with a CLOSE/CLOSE_ACK > handshake, based on Erik's approach. Looks good, thanks! The only thing I was left wondering is the overloading of the CLOSE_ACK message. In the text provided, CLOSE_ACK works both as an ack to a received CLOSE and as a kind of error message telling that there is no such association. In the former case, it is protected with HMAC and SIG, in the latter case it is not. Maybe it would be better to have different messages for these purposes? That is, in the UNASSOCIATED state, if you receive a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable error code. In that way the CLOSE_ACK message would be only used for acknowledging CLOSE. A related issue is whether we should allow/require a "CLOSED" state. A host sending a CLOSE_ACK would enter a "CLOSED" state for a certain period (2 * timeout?), and during that time it would be able to send further CLOSE_ACK messages in the case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) It would then automatically move to UNASSOCIATED if it receives no CLOSE messages within that period. I don't think the CLOSED state is necessarily needed, or should be mandated, but it sounds to be as a nice engineering optimisation that some implementations might want to do. --- We probably need also some text to the security considerations section, considering the potential DoS attacks related to the CLOSE mechanism. It should note that since the CLOSE (and CLOSE_ACK?) messages have HMAC, an outsider cannot CLOSE a connection. It has SIG, allowing middle boxes to inspect the messages and immediately close the related SAs. --Pekka From pekka.nikander@nomadiclab.com Fri Oct 8 07:01:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 8 06:01:01 2004 Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-Reply-To: <200410071033.29140.julien.laganier@sun.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EDE@xch-nw-09.nw.nos.boeing.com> <4164F590.9040204@nomadiclab.com> <200410071033.29140.julien.laganier@sun.com> Message-ID: <7B085D15-191A-11D9-BF2A-000D9331AFB0@nomadiclab.com> Just one aspect now, I'll try to return to the rest later. Sorry for not having had time to take this up earlier. Supporting multiple parallel SAs between any pair of HIs has been a non-goal for HIP from the beginning. The mobility and multi-homing extension adds such a feature, but _only_ for dealing with replay window problems. If this non-goal is not clear from the base spec / arch spec, we need to add explicit text. And I guess the case is so, since we've faced this same issue before. Anyone willing to draft text to be included in both/either of the drafts, noting that _architecturally_ HIP only considers host-to-host granularity, and any finer granularity is FFS? If someone wants to add policy control to HIP so that you could have multiple parallel SAs for policy purposes, that requires an extension and DOES NOT belong to the base specification. From that point of view, I don't see any need for having nonces. There may be other reasons; I haven't had flow time to contemplate that. --Pekka From petri.jokela@nomadiclab.com Fri Oct 8 07:06:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 8 06:06:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> References: <200407151325.14103.julien.laganier@sun.com> <200410072323.32301.julien.laganier@sun.com> <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> Message-ID: <4166764D.1060401@nomadiclab.com> Pekka Nikander wrote: > > Looks good, thanks! > > Maybe it would be better to have different messages for these > purposes? That is, in the UNASSOCIATED state, if you receive > a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable > error code. In that way the CLOSE_ACK message would be only > used for acknowledging CLOSE. > > A related issue is whether we should allow/require a "CLOSED" > state. A host sending a CLOSE_ACK would enter a "CLOSED" > state for a certain period (2 * timeout?), and during that > time it would be able to send further CLOSE_ACK messages in the > case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) > It would then automatically move to UNASSOCIATED if it receives > no CLOSE messages within that period. > > I don't think the CLOSED state is necessarily needed, or should > be mandated, but it sounds to be as a nice engineering optimisation > that some implementations might want to do. > Thanks Julien for the text! I modified a bit Julien's proposal according to Pekka's comments. My notes are included in the text. Outgoing/incoming data traffic text needs still something For example when the association is not dropped in the CLOSED state and there is some data that would belong to this association. /petri 5.4.2 HIP State Processes <**PJ**> In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOSE, not written down here <**PJ**> +------------+ |UNASSOCIATED| Start state +------------+ Datagram to send requiring a new SA, send I1 and go to I1-SENT Receive I1, send R1 and stay at UNASSOCIATED Receive I2, process if successful, send R2 and go to R2-SENT if fail, stay at UNASSOCIATED Receive ESP for unknown SA, optionally send ICMP as defined in Section 6.3 and stay at UNASSOCIATED Receive CLOSE for unknown association, stay at UNASSOCIATED Receive ANYOTHER, drop and stay at UNASSOCIATED <**PJ**> ESTABLISHED: Go to CLOSED instead of UNASSOCIATED <**PJ**> +------------+ |ESTABLISHED | HIP SA established +------------+ Receive I1, send R1 and stay at ESTABLISHED Receive I2, process with cookie and possible Opaque data verification if successful, send R2, drop old SAs, establish new SA, go to R2-SENT if fail, stay at ESTABLISHED Receive R1, drop and stay at ESTABLISHED Receive R2, drop and stay at ESTABLISHED Receive ESP for SA, process and stay at ESTABLISHED Receive UPDATE, process if successful, send UPDATE in reply and go to REKEYING if failed, stay at ESTABLISHED Need rekey, send UPDATE and go to REKEYING No packet sent/received during UAL minutes, send CLOSE and go to CLOSING. Receive CLOSE, process if successful, send CLOSE_ACK and go to CLOSED if failed, stay at ESTABLISHED <**PJ**> Closing: Move to CLOSED after sending CLOSE_ACK instead of UNASSOCIATED <**PJ**> +---------+ | CLOSING | HIP association has not been used for UAL (Unused +---------+ Association Lifetime) minutes. Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, discard state and go to CLOSED if failed, stay at CLOSING Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSING Receive ANYOTHER, drop and stay at CLOSING Timeout, increment timeout sum, reset timer if timeout sum is less than UAL+MSL minutes, retransmit CLOSE and stay at CLOSING if timeout sum is greater than UAL+MSL minutes, go to UNASSOCIATED <**PJ**> CLOSED is a new state. Timeout sum should be 2*MSL or something else?? <**PJ**> +--------+ | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary +--------+ Datagram to send, requires creation of another HIP association in UNASSOCIATED state (which will send I1 and go to I1-SENT) Receive CLOSE, process if successful, send CLOSE_ACK, stay at CLOSED if failed, stay at CLOSED Receive CLOSE_ACK, process if successful, discard state and go to UNASSOCIATED if failed, stay at CLOSED Receive ANYOTHER, drop and stay at CLOSED Timeout, increment timeout sum, reset timer if timeout counter > 2 * MSL, discard state and go to UNASSOCIATED else stay at CLOSED 5.4.3 Simplified HIP State Diagram +-+ | | CLOSE received, send NOTIFY V ^ +------------+ |UNASSOCIATED|<----------------------+ +------------+ | ^ | Timeout, move to | CLOSE_ACK received, or | UNASSOCIATED | timeout sum > UAL+MSL | | +--------+ ^ rec CLOSE, +--->| CLOSED |----+ +---------+ send CLOSE_ACK | +--------+ | CLOSE received, | CLOSING |----------------+ | ^ | send CLOSE_ACK | |-----+ | | | +---------+ | timeout sum | +-----+ ^ ^ | < UAL+MSL, | | +------+ retransmit CLOSE | | | | No packet sent/received | | for UAL min, send CLOSE | ^ | CLOSE received, +------------+ | send CLOSE_ACK |ESTABLISHED |>----------------------+ +------------+ ----------------------------------------------------------------- <**PJ**> Removed optional things, NOTIFY is sent in UNASSOCIATED state <**PJ**> 7.11 CLOSE_ACK - the HIP closing acknowledgment packet The HIP header values for the CLOSE_ACK packet: Header: Packet Type = XXX Tbd. SRC HIT = Sender's HIT DST HIT = Recipient's HIT IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) Valid control bits: none The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope). The receiver peer MUST validate both the HMAC and the signature. ----------------------------------------------------------------- <**PJ**> We don't discard the state before we move to UNASSOCIATED. - If we want to send data? We cannot use the old association any longer, we need to start a new negotiation. That part of the text needs maybe some clarification. <**PJ**> 8.16 Processing CLOSE packets When the host receives a CLOSE message it responds with a CLOSE_ACK message and moves to CLOSED state. (The authenticity of the CLOSE message is verified using both HMAC and SIGNATURE). This processing applies whether or not the HIP association state is CLOSING in order to handle CLOSE messages from both ends crossing in flight. The HIP association is not discarded before the host moves from the UNASSOCIATED state. Once the closing process has started, any need to send data packets will trigger creating and establishing of a new HIP association, starting with sending an I1. A CLOSE message which is received when there is no HIP association state can not be verified but will result in a NOTIFY response. ----------------------------------------------------------------- <**PJ**> Optional things removed. ACK also accepted in CLOSED state if we have earlier sent CLOSE related to the same association: ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, send CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent CLOSE ->... <**PJ**> 8.17 Processing CLOSE_ACK packets When a host receives a CLOSE_ACK message it verifies that it is in CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSE (using the included ECHO_REPLY in response to the sent ECHO_REQUEST). The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is discarded when the state changes to UNASSOCIATED and, after that, NOTIFY is sent as a response to a CLOSE message. ----------------------------------------------------------------- <**PJ**> New NOTIFY <**PJ**> 6.2.19 NOTIFY UNKNOWN ASSOCIATION 44 The received CLOSE message referred to an association that does not exist. From shep@alum.mit.edu Fri Oct 8 07:18:00 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Fri Oct 8 06:18:00 2004 Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-Reply-To: Your message of Fri, 08 Oct 2004 14:09:10 +0300. <7B085D15-191A-11D9-BF2A-000D9331AFB0@nomadiclab.com> Message-ID: > Supporting multiple parallel SAs between any pair of HIs > has been a non-goal for HIP from the beginning. Yes. And our thinking on this was that HIs can be easily created, as many as you like, and only one of two hosts would have to use a different HI in order to have parallel HIP sessions going simultaneously between two hosts. We were thinking that typical HIP associations would be using an ephemeral HI on at least one end (probably the initiator) so if for some reason you need to open a parallel SA, you just create another ephemeral HI. Even if there's a situation where you need non-ephemeral HIs at both ends, then if you need parallel SAs, you can probably manage to have a different HI at least at one end. At least that is what we were thinking, and at this particular moment I am not convinced that this thinking was in error. -Tim Shepard shep@alum.mit.edu From pekka.nikander@nomadiclab.com Fri Oct 8 08:12:02 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 8 07:12:02 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <414DF55F.7020802@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> Message-ID: <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> Yogesh, Trying to finally cover this message, sorry for the delay. Anyway, thanks a lot of taking this up and writing this. > Okay, the minimal changes required in the present HIP key exchange is > to just add a HMAC(g^xy, HOST_ID) in message-3 and adds HOST_ID in > the HMAC of message 4 (shown in the message exchange below). Note > that the present protocol in the draft looks fairly secure, but as > SIGMA > paper points out encryption is not the right method to prove possession > of session key (but the attack that the paper describes in the presence > of stream cipher doesn't apply here). So while the encrypted token > { PUBLIC_KEY-I, Domain-ID-I }_g^ri and the signature over this token > guarantees that identity mis-binding attack cannot be carried out, > it's still better to use HMAC, IMO. (Besides we have a proof that > HMAC based scheme is secure.) Sounds good. > I have also added nonce-I and nonce-R in all these message. This is > important to allow parallel SA creation, and allow cases where both > initiator and responder choose pre computed g^i and g^r (this can > happen, unless the draft explicitly prevents it). The nonce should > be used in deriving the session keys. As was discussed in other messages, parallel SAs between any given pair of HITs is a non-goal. I'd like to understand better your reference to pre-computed D-H keys by both parties. Would you care to explain? > 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > > 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > SIG( HIT-R, g^r, PUBLIC_KEY-R) > > > 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > SIG( HIT-I, HIT-R, SPI, g^i, > { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > > 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > has changed */ If I understand correctly, and leaving aside the issue of nonces, the only differences are the addition of HMAC to I2 and the change of the HMAC contents in R2. They seem OK to me. > o In the draft it's important to say that the responder should keep > the random value r for at least 2*MSL (and possibly longer) from > the > last time it sent message 2. In case Message 3 arrives after 2*MSL, > and no random number r can be found, it should be dropped and an > ICMP > message should be sent. If the Initiator receives an ICMP after > sending message-3, it should not assume that the responder sent > the message, and should not close that session. An Initiator > MAY however start with a new parallel I1 with a new nonce value. Sounds OK to me. I guess most of this is already implied by the draft, but it would be much better to be explicit. Petri your Yogesh, could you provide us with some concrete proposal? > Couple of observations about this key exchange: > > A) The identity of Responder cannot be concealed even against the > passive attack. The HOST_ID in message-2 is required so that the > Initiator can get the public-key to verify the SIGNATURE from > responder. Yes. One way to address this has been discussed in the BLIND paper by Jukka Ylitalo and me, in this year's Cambridge Security Protocols Workshop. See Jukka's or my publications web pages. > B) The identity of Initiator cannot be concealed against an active > attacker unless g^r is covered in SIGNATURE calculation in > message-2. (So keep section-7 description and change section-4 text) Sounds OK to me. > (A) and (B) together means that if we want to get responders ID > protection then we need to severely reorganize the messages. Yes. We are aware of that. See the above mentioned paper. > One simple thing one can do is to only send the public-key and > in message-2 (and leave Domain-ID-R field completely out). That doesn't help much, since in HIP the public key IS the real identifier. The hostname/NAI is only considered as auxliary information. You may learn the association between the public key and the hostname/NAI also from the DNS or some other databse. > Later, > Responder can put Domain-ID as encrypted in message-4 and let Initiator > verify it against the MAC received in message-2. The advantage is that > we can now protect the identity of Initiator against passive attacker > and the Identity of responder against Active attackers. The > disadvantage > is that the Initiator's ID cannot be protected against active > attackers. It was a deliberate choice to err on protecting the initiator's privacy more than the responder's. > Note that protecting the Public-Key alone without Domain-ID is not > that useful. The worst thing that an attacker can do by stealing the > public key is to register it under her own name (i.e., Eve takes > Alice's public key and puts it in DNSsec under Eve's name, assuming > DNSsec doesn't do proof of possession checks). Binding of public keys and external identifiers, such as hostnames or NAIs, is currently outside the scope of the WG charter. The architectural stance is that the public key is the primary identifier, and getting the public key from a human understandable name is a separate problem. > But the HMAC binding to > name in SIGMA prevents from attacks that can result from this kind of > behavior, so it's not that useful to protect the public-key. Note > that this is the reason I have added HOST_ID in message-4. HMACing > only HITs will get us in trouble. I don't see any adverse effects of adding the HOST_ID to the HMACs, even though I doubt its value. The kind of identity stealing attack that you describe belongs, from an architectural point of view, beyond the HIP base spec. On the other hand, if we can this easily provide some extra security, then why not. In summary: I am in favour of making these two changes: - adding a HMAC to I2 - changeing the R2 HMAC contents I still haven't been convinced about the nonces. The multiple-SA argument doesn't hold as it is a non-goal. I haven't seen explicit argumentation about using nonces for keymat generation. --Pekka From Julien.Laganier@Sun.COM Fri Oct 8 09:34:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 8 08:34:01 2004 Subject: [Hipsec] Agenda requests In-Reply-To: <4164E796.6030603@ericsson.com> References: <4164E796.6030603@ericsson.com> Message-ID: <200410081543.39186.julien.laganier@sun.com> On Thursday 07 October 2004 08:52, Gonzalo Camarillo wrote: > Folks, > > we are officially starting to gather agenda requests for the HIP WG > meeting in Washington. You should send your agenda request to the > chairs indicating what you want to present, any related documents, > and how long you want your agenda-slot to be. Hi Gonzalo, I'd like to request to short (10 minutes) slots to present draft-ietf-hip-dns-00.txt and draft-ietf-hip-rvs-00.txt in the next HIP WG session. Thanks, --julien From thomas.r.henderson@boeing.com Fri Oct 8 17:00:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Oct 8 16:00:01 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Responding below to a number of (mostly Miika's) comments: (thanks for donating Security Considerations text! unless there is objection, I will include the version that Pekka edited) >=20 > > 9. If HIP negotiates base exchange using link locals, and one > > host moves, it will not be able to find its peer > > > > Suggested resolution: State that a host SHOULD provide its > > peer with a globally reachable IP address instead of relying > > exclusively on link-local addresses. >=20 > (the same goes for site-local addresses) site-locals are deprecated, but I think we can address this generally by saying "locally scoped" or "non-global" address. >=20 > > 10. Should REA be included in R2 or R1 (R1 is presently > > specified in text)? > > > > Note that there is some conflict in saying that, when REA > > is included in R1 and it includes a new preferred address, > > that the puzzle solution MUST be valid for both responder > > addresses. The conflict is in using Appendix D (base spec) > > mapping functions. > > > > Suggested resolution: Open, but leaning towards recommending > > inclusion in R2 instead of R1, unless the reason for putting > > it in R1 is (re)discovered. > > > > Also, issue should be opened in issue tracker. >=20 > I'd vote for the inclusion in the R2. This way, the R1s don't=20 > have to be > prebuilt every time the responder moves. >=20 It seems that most people (including myself) prefer the R2-- any objection if we make that change now? > One possible Denial of Service attack occurred in my mind: >=20 > A host could fake a creation of a new SA causing resource=20 > consumption at=20 > the peer host. This covered by Miika's proposed security section. > -> 4. (Roundup issue tracker #4): Use of multiple SAs > ->=20 > -> Suggested resolution: Close this issue (resolved). >=20 > How was this resolved (I forgot..) ? The issue tracker shows only one=20 > posting about this issue. Here was the start of the thread that caused that issue: http://honor.trusecure.com/pipermail/hipsec/2004-April/000667.html My understanding of the consensus (or the way that the thread eventually tailed off) was that a mechanism to have multiple SAs to handle the case where RTTs are very different was needed, but maybe in some cases it could be avoided (depending on how well the anti-replay was tuned). > -> Suggested resolution: Add a note to the text that, in the > -> case of multihoming with multiple SAs, it is RECOMMENDED to > -> associate SAs in pairs, and that when a NES is received for > -> a particular SA, the peer should rekey the paired SA. > -> Also, state that using asymmetrically set up SAs is experimental,=20 > -> and may fail to interoperate. > -> >=20 > I would like to see what is the definition for a "paired SA".=20 > How it is=20 > related to the peer's SAs and how it is associated when a new SA is=20 > created. >=20 Here is proposed text for a replacement of the third paragraph in=20 Section 5.2: "IPsec SAs are unidirectional, and the protocol may support = configurations in which an asymmetric number of inbound and outbound SAs exist on a = given host with respect to another host. However, for the purpose of handling multihoming more cleanly, it is RECOMMENDED that inbound and outbound = SAs=20 be created and maintained in a pairwise fashion between hosts, and that when rekeying occurs on one SA, it is also triggered on the paired SA. = For example, the HIP base exchange results in two SAs-- one inbound and one outbound on each host. If one of the two hosts wants to advertise = another interface to its peer, it should add a new inbound SA and send a REA = (and NES) to the peer. The peer should also create a new inbound SA. These two new SAs are also paired. Subsequently, when a rekey occurs on one = SA, a corresponding rekey is performed on the paired SA, with no ambiguity. = Implementations that fail to follow the above guidelines may fail to=20 interoperate cleanly." > -> 11. Use of SPI parameter when REA is present-- is it necessary? >=20 > I have no experience yet. >=20 > -> Suggested resolution: Open until middlebox implications are > -> better understood. > ->=20 > -> Also, issue should be opened in issue tracker. >=20 > Then we would have SPIs in three places in the same packet. REA, > NES, and SPI. Messy ? REA and NES both need SPI, since REA may occur without NES. SPI would seem to be redundant, unless a middlebox always wants SPI to be there, for its convenience. Suggest to leave it open for now. >=20 > Also the SPI selection algorithm for the parameter would be nice. Suggest statement that "SPI selection is performed in the same manner as in the base exchange." >=20 > Looks like there is a lot of text which assume the situation=20 > as if there=20 > is always only one address listed in the REA. That causes=20 > misinterpretation (for me at least) in sentences such as: >=20 >=20 > -Section 4.2 Address verification, "A simple technique to=20 > verify addresses=20 > is to send an UPDATE to the host at the new address." and "If=20 > the peer=20 > host is rekeying by sending an UPDATE with NES to the new=20 > address, the=20 > arrival of data on the new SPI can also be used to verify the=20 > address."=20 >=20 > Does this verify the reachability of all addresses listed in=20 > the REA ? No. >=20 > Shouldn't this be "For each of the listed addresses in the REA, .." ?=20 > Something like in draft mm-00 section 4.3 Address verification: "To=20 > acknowledge that it has received the REA, and to initiate an address=20 > check, the HIP host receiving a REA immediately sends an AC to all=20 > addresses mentioned in the REA." Yes, should state "for each" > -Section 5.1 Mobility with single SA pair, "Upon obtaining a new IP=20 > address, the mobile host sends a REA parameter to the peer host in an=20 > UPDATE message. The REA indicates the following: the new IP=20 > address, the=20 > SPI associated with the new IP address, the address lifetime,=20 > and whether=20 > the new address is a preferred address. .. The UPDATE=20 > messages sent from=20 > the peer back to the mobile are sent to the newly advertised address." >=20 > And the "newly advertised address" is defined here as .. ? Preferred=20 > address in the REA, if there is any (and what if not) ? All of the=20 > addresses ? >=20 > Hmm..but wait..ahh..the reader must notice the word "messages", so by=20 > deduction this section should also say "for all of the addresses a=20 > separate UPDATE is sent by the peer..", right ? Yes, this should be clarified as you point out. =20 > In section 5.1 Mobility with single SA pair, "Readdress=20 > without rekeying,=20 > but with address check": >=20 > When a mobile hosts sends UPDATE(REA, SEQ) (Figure 3), must it be=20 > processed in any state (established or rekeying) ? How it should be=20 > processed upon receive ? Can we skip some tests mentioned in the base=20 > draft's section 8.11 Processing UPDATE packets ? Yes, I will refer to 8.11 and remove the redundant text. > A conflict in 5th paragraph of section 7.1 Sending REAs: "All=20 > addresses=20 > corresponding to the SPI have the same lifetime." But the rest of the=20 > discussion on address lifetimes tells that each address have=20 > their own=20 > lifetimes. I think that the quoted sentence should be struck (maybe Pekka has an opinion). The address lifetimes correspond to the IPv6 stateless autoconfiguration lifetimes-- not necessarily the same for all addresses. > 5.7 Initiating the protocol in R1 or I2: >=20 > Should there be some explicit notes about the KEYMAT index to=20 > be used when=20 > retrieving keying materials for the SA(s) if the R1 or I2 contains=20 > (multiple) REA(s) ? Or do we just assume that the=20 > implementors know what=20 > they are doing without telling them. That is, they use the=20 > current KEYMAT=20 > index right after when the HIP keys were drawn. I do not see any harm in adding a sentence for clarity. From jari.arkko@piuha.net Sat Oct 9 02:16:00 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Sat Oct 9 01:16:00 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: <416783AC.3050408@piuha.net> Henderson, Thomas R wrote: >>>9. If HIP negotiates base exchange using link locals, and one >>>host moves, it will not be able to find its peer >>> >>>Suggested resolution: State that a host SHOULD provide its >>>peer with a globally reachable IP address instead of relying >>>exclusively on link-local addresses. >> >>(the same goes for site-local addresses) > > > site-locals are deprecated, but I think we can address this > generally by saying "locally scoped" or "non-global" address. Statistically unique site-local addresses would probably be OK too, for usage within a site. The problem with the link-local and old site local addresses was not just the connectivity but also potential collisions; you could attempt talking to a node which had nothing to do with the previous node you talked with. The connectivity part is, however, not a major problem as far as I can see. Even global addresses might have connectivity problems in some cases, and we provide multihoming primarily to combat this problem. --Jari From yogesh.swami@acm.org Sun Oct 10 22:28:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Sun Oct 10 21:28:01 2004 Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-Reply-To: References: Message-ID: <4169F148.8010502@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig90A14E5CE55C2CD19A479754 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit catching up... ext Tim Shepard wrote: >>Supporting multiple parallel SAs between any pair of HIs >>has been a non-goal for HIP from the beginning. > > > Yes. > > And our thinking on this was that HIs can be easily created, as many > as you like, and only one of two hosts would have to use a different > HI in order to have parallel HIP sessions going simultaneously between > two hosts. We were thinking that typical HIP associations would be > using an ephemeral HI on at least one end (probably the initiator) so > if for some reason you need to open a parallel SA, you just create > another ephemeral HI. Even if there's a situation where you need > non-ephemeral HIs at both ends, then if you need parallel SAs, you can > probably manage to have a different HI at least at one end. > > At least that is what we were thinking, and at this particular moment > I am not convinced that this thinking was in error. > I wasn't expecting so much discussion on this issue. One can of course use new HIs for every simultaneous SA creation, but a) this will make the possibility of HIT collision much higher, b) the user will have to wait for minutes if HIs are to be generated on the fly (may be one can cache all the previously generated HIs, still...) and c) If you want MITM prevention through DNSsec, the DNS database size will explode. Compared to all this, a nonce is somewhat more efficient. If I understand right, I guess the traffic selector is the main objection that people have for not using nonce. But as Julien pointed out, one can use "populate from packets" (PFP) to setup the filters. Also, I am not sure how multiple HIs help. If you have a BITW implementation of IPsec, you still need some mechanism to tell the IPsec filter to select packets based on IP address/port-numbers (the HITs are not present in the packets). So we end with the same problem, don't we? What am I missing here? Yogesh --------------enig90A14E5CE55C2CD19A479754 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWnxTHkjMhOId4nzAQKZoQgApNSCCGDbACL20hG88Yg8hJkb1zu/+P08 7zPiwZH8wYXpKOGF535vLkU77j7IkHHocax9vvGJlywLF9oi4gX/jHa9cf9Vh4Dj 0a6Oob0dEVYYrqvE9Y9X5j2R8AaPlZwNbd+ZLf4zF3quBDDXrco422+r9z2FS46N pelz6zqb9WLkAqZCRLSl5lNt5lRq0n257PRt5EwA0qH1n8Nmeu5N+IFmjjR3R18w bzx630/UzmeYdJoPupW3FfkyHuBAxMvgetgMNF6UuqC5Hv8TgEHgipukEd2aksxD HF/cNn+k1qPmITzW3STXyxLxfvzQV1yklIGyQh/YvvVFzw7uq1r2zQ== =OZjQ -----END PGP SIGNATURE----- --------------enig90A14E5CE55C2CD19A479754-- From yogesh.swami@acm.org Sun Oct 10 22:34:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Sun Oct 10 21:34:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> Message-ID: <4169F281.8000703@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD9BE0ED44EAF8E977C004A9B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pekka, Please see in line: ext Pekka Nikander wrote: > Yogesh, > > >> I have also added nonce-I and nonce-R in all these message. This is >> important to allow parallel SA creation, and allow cases where both >> initiator and responder choose pre computed g^i and g^r (this can >> happen, unless the draft explicitly prevents it). The nonce should >> be used in deriving the session keys. > > > As was discussed in other messages, parallel SAs between any > given pair of HITs is a non-goal. I'd like to understand better > your reference to pre-computed D-H keys by both parties. Would > you care to explain? > Let's say, both the sides, Alice and Bob, use precomputed values of g^x and g^y. Let's also say that both Alice and Bob update their g^x and g^y only once every hour. That means, during that one hour period, no matter how many HIP exchange Alice and Bob do, they will end up with the same Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which will be the same). This can have quite a few security implications. For example, replay protection will become weak, because an attacker can now inject packets from previous sessions and simple sequence numbers and HMAC based authentication will not be able to detect it (Assuming the session was not using any form of Initialization Vectors). >> 1. I->R: NCN-I, 0, HIT-I, [HIT-R] >> >> 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R >> SIG( HIT-R, g^r, PUBLIC_KEY-R) >> >> >> 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, >> { PUBLIC_KEY-I, Domain-ID-I }_g^ri, >> SIG( HIT-I, HIT-R, SPI, g^i, >> { PUBLIC_KEY-R, Domain-ID }_g^ri, ) >> *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* >> >> 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), >> HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content >> has changed */ > > > If I understand correctly, and leaving aside the issue of nonces, > the only differences are the addition of HMAC to I2 and the > change of the HMAC contents in R2. They seem OK to me. > >> o In the draft it's important to say that the responder should keep >> the random value r for at least 2*MSL (and possibly longer) from the >> last time it sent message 2. In case Message 3 arrives after 2*MSL, >> and no random number r can be found, it should be dropped and an ICMP >> message should be sent. If the Initiator receives an ICMP after >> sending message-3, it should not assume that the responder sent >> the message, and should not close that session. An Initiator >> MAY however start with a new parallel I1 with a new nonce value. > > > Sounds OK to me. I guess most of this is already implied by the > draft, but it would be much better to be explicit. Petri your Yogesh, > could you provide us with some concrete proposal? > >> Couple of observations about this key exchange: >> >> A) The identity of Responder cannot be concealed even against the >> passive attack. The HOST_ID in message-2 is required so that the >> Initiator can get the public-key to verify the SIGNATURE from >> responder. > > > Yes. One way to address this has been discussed in the BLIND > paper by Jukka Ylitalo and me, in this year's Cambridge Security > Protocols Workshop. See Jukka's or my publications web pages. > >> B) The identity of Initiator cannot be concealed against an active >> attacker unless g^r is covered in SIGNATURE calculation in >> message-2. (So keep section-7 description and change section-4 text) > > > Sounds OK to me. > >> (A) and (B) together means that if we want to get responders ID >> protection then we need to severely reorganize the messages. > > > Yes. We are aware of that. See the above mentioned paper. > >> One simple thing one can do is to only send the public-key and >> in message-2 (and leave Domain-ID-R field completely out). > > > That doesn't help much, since in HIP the public key IS the real > identifier. The hostname/NAI is only considered as auxliary > information. You may learn the association between the public > key and the hostname/NAI also from the DNS or some other databse. > I agree. But the HIs alone are somewhat hard to work with. When a hosts grants access to resources, it needs to know who the person on the other side is, and that's why I consider names bound to HIs to be a fundamental component to identity. This can also have scalability issues (for example, with e-mail addresses you can grant access to every one with address for example as *.acm.org. With HIs one will have to list all the HIs, which is error prone and takes a lot more space). >> Later, >> Responder can put Domain-ID as encrypted in message-4 and let Initiator >> verify it against the MAC received in message-2. The advantage is that >> we can now protect the identity of Initiator against passive attacker >> and the Identity of responder against Active attackers. The disadvantage >> is that the Initiator's ID cannot be protected against active attackers. > > > It was a deliberate choice to err on protecting the initiator's > privacy more than the responder's. > But now, if an attacker, Eve, wants to get the Identity of the Initiator, Alice, all Eve has to do is to just take Alice's HIT (from an exchange that she started) and send an I1 to Alice. Alice, on seeing I1 will herself give her identity out in R1. >> Note that protecting the Public-Key alone without Domain-ID is not >> that useful. The worst thing that an attacker can do by stealing the >> public key is to register it under her own name (i.e., Eve takes >> Alice's public key and puts it in DNSsec under Eve's name, assuming >> DNSsec doesn't do proof of possession checks). > > > Binding of public keys and external identifiers, such as hostnames > or NAIs, is currently outside the scope of the WG charter. The > architectural stance is that the public key is the primary identifier, > and getting the public key from a human understandable name is a > separate problem. see above. > >> But the HMAC binding to >> name in SIGMA prevents from attacks that can result from this kind of >> behavior, so it's not that useful to protect the public-key. Note >> that this is the reason I have added HOST_ID in message-4. HMACing >> only HITs will get us in trouble. > > > I don't see any adverse effects of adding the HOST_ID to the > HMACs, even though I doubt its value. The kind of identity > stealing attack that you describe belongs, from an architectural > point of view, beyond the HIP base spec. On the other hand, > if we can this easily provide some extra security, then why not. > > In summary: I am in favour of making these two changes: > - adding a HMAC to I2 > - changeing the R2 HMAC contents > > I still haven't been convinced about the nonces. The multiple-SA > argument doesn't hold as it is a non-goal. I haven't seen > explicit argumentation about using nonces for keymat generation. > Okay, the theory for using nonce (or any random data) in keymat goes as follows (my apologizes, if I am repeating well known stuff): The fact that an attacker cannot generate g^xy from g^x and g^y in itself is not sufficient to guarantee that the scheme is secure. Even though an attacker cannot exactly compute g^xy from g^x and g^y, she can still guess 60%-80% of bits of g^xy with a high (~ 0.95) probability. (For example, some people believe that the generator 2 leaks information about x in 2^x (mod p) because 2^x = (1+1)^x = 1 + x + x(x-1)/2 + .... by binomial expansion -- an expression with only x on right hand side. Of course no one has shown, to the best of my knowledge, how to predict the bits of g^xy (mod p) based on this or any similar information.) So to make the scheme more secure, what one needs is that given (g^x, g^y, and g^xy) an attacker should not be able to distinguish it from the distribution of (g^x, g^y, and g^Random_number). There are lots of papers on this problem (called the Decision Diffie-Hellman (DDH) problem). To achieve this, g^xy is MACed to get rid of the non-uniform distribution of bits of g^xy and make it look more like g^random_number (actually if there is a better Pseudo Random Number Generator (PRG) than MACs, then that PRG should be used instead). For a MAC to generate a uniform distribution it should have enough entropy in the input stream. Adding a nonce (or any random data) helps in that sense. Note that the present KEYMAT also MACs the HITs, but the amount of entropy of HITs combined (=127*2) is much less that the size of g^xy (=1024 bits). So how much MAC will be able to get rid of predictability of g^xy is not clear (it might be sufficient; I haven't been closely following crypto stuff after 2001, so I don't know what new developments have taken place). Adding the nonce in key generation might help from that POV. If you don't want to add a nonce, then just adding some random data will also help (e.g., using the entire R1 and I2 packets in KEYMAT generation). Yogesh --------------enigD9BE0ED44EAF8E977C004A9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWnygXkjMhOId4nzAQLbVwgAj7YES64v6htAAtG9iOfXRdEY135FixNG K10uIVrVt65Arzn4xjfTDQcqALdNzjEWU8rihVIrJn+TPullGrjF2TGVTjDy/+n9 M2oLoJabyGx01XQzYIn2rcoRnvAQtjwPiQZ4qs3olXCWrO6OKsvgHT/sQ/IRWQOg qJ+qSnLOlN54KuwoEgbaJm27dF+B7UhdhP0Q060u5LAUSrF1/Wbahpyrq1BKC++c rO3q9rc8dqt/zh4OjTq29NRKQQuLABGFGsmids/t90tpG88dc4vs7trB0WslnOr1 mQ8Xv079EjB6lJ7BZsLkhUoMbdGG508+OktveXZenZZ+0F7w0sOA2Q== =LeaH -----END PGP SIGNATURE----- --------------enigD9BE0ED44EAF8E977C004A9B-- From pekka.nikander@nomadiclab.com Mon Oct 11 01:56:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 00:56:01 2004 Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-Reply-To: <4169F148.8010502@acm.org> References: <4169F148.8010502@acm.org> Message-ID: <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> > If I understand right, I guess the traffic selector is the main > objection that people have for not using nonce. But as Julien > pointed out, one can use "populate from packets" (PFP) to setup > the filters. As far as I have understood the thinking of the community (the chairs may correct), the current belief is that if someone wants to have traffic selectors and multiple parallel SAs for policy reason, the right thing to do is to write an extension, present it at the RG side, and sense the feeling of the community at the re-chartering time. Hence, IMHO, that discussion should be moved to the RG mailing list. > Also, I am not sure how multiple HIs help. If you have a BITW > implementation of IPsec, you still need some mechanism to tell > the IPsec filter to select packets based on IP address/port-numbers > (the HITs are not present in the packets) At least my understanding has been that iff you are dealing with legacy hosts and therefore BITW IPsec, you just configure your host to use either LSIs (1.0.0.0/8) or HITs (4000::0/2) on the local link. Contrary what the docs says, in that special case you do have LSIs or HITs in IP headers on the wire. Hence, you will have HITs (or at least LSIs) even in a BITW implementation. Other than that, properply implementing HIP support on a BITW box is pretty impossible. --Pekka From pekka.nikander@nomadiclab.com Mon Oct 11 02:01:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 01:01:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4169F281.8000703@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Message-ID: <143BE305-1B4C-11D9-97E8-000D9331AFB0@nomadiclab.com> Yogesh, This is very good and educating discussion, at least to me. Thanks again for bringing this up, even if I seem to oppose quite a lot of what you say :-) >> I'd like to understand better >> your reference to pre-computed D-H keys by both parties. Would >> you care to explain? > > Let's say, both the sides, Alice and Bob, use precomputed values of g^x > and g^y. Let's also say that both Alice and Bob update their g^x and > g^y > only once every hour. That means, during that one hour period, no > matter > how many HIP exchange Alice and Bob do, they will end up with the same > Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which > will be the same). Well, my understanding has been that you shouldn't reuse your DH-key, ever. (Maybe the docs don't say that.) That is, you should have a pool of precomputed R1s, use that pool pretty uniformingly while they are valid, and once you get an I2 for a given R1, cease transmitting it. When some R1s expire, you can reuse the DH keys in them after a while, i.e., when it looks like that you won't get any I2 on them. Since all this is supposed to be (mostly) stateless, implementing this in practise is pretty hard, though. Hence, while I don't buy your argument above, there still seems to be of some value. >> ... in HIP the public key IS the real >> identifier. The hostname/NAI is only considered as auxliary >> information. You may learn the association between the public >> key and the hostname/NAI also from the DNS or some other databse. > > I agree. But the HIs alone are somewhat hard to work with. When a hosts > grants access to resources, it needs to know who the person on the > other > side is, and that's why I consider names bound to HIs to be a > fundamental component to identity. From a practical point of view, I can't help but agree. However, from an architectural purity point of view, I bitterly disagree. :-) > This can also have scalability issues > (for example, with e-mail addresses you can grant access to every one > with address for example as *.acm.org. With HIs one will have to list > all the HIs, which is error prone and takes a lot more space). Right. That's why the HAA HITs were introduced. The recent development has pretty much ignored them, but I expect them to pop up later. OTOH, you have to remember that you have to store either the HITs or the HIs somewhere, in order to be (reasonably) secure. It may be enough to store a wild card name locally, but then you still need to have access to a trusted binding between the names and HIs. I'd most probably attempt to solve this problem with SDSI/SPKI name certificates, without storing anything locally, if space is of concern. Hence, the name transferred as a part of the HIP base exchange really is just auxliary information. You can't trust it, in no way, as you can't trust your peer. In fact, if the proposed DHT infra was there in place, we most probably wouldn't need the HOST_ID payload at all. >> It was a deliberate choice to err on protecting the initiator's >> privacy more than the responder's. > > But now, if an attacker, Eve, wants to get the Identity of the > Initiator, Alice, all Eve has to do is to just take Alice's HIT (from > an > exchange that she started) and send an I1 to Alice. Alice, on seeing I1 > will herself give her identity out in R1. That depends on the policy Alice has. If the associated HI is non-public, the case may be that Alice doesn't reply to any I1s asking to connect to it. Again, if you want to have full privacy with HIP, you most probably need to go to something like BLIND. (And there you have the nonces, too :-). Hence, I don't see much value in changing the base spec at this point of time. But, as I wrote above, this discussion is very useful and preferably should be preserved in some form. I think we should either write another draft, or add an informational appendix on the base spec. >> I still haven't been convinced about the nonces. The multiple-SA >> argument doesn't hold as it is a non-goal. I haven't seen >> explicit argumentation about using nonces for keymat generation. > > Okay, the theory for using nonce (or any random data) in keymat goes as > follows (my apologizes, if I am repeating well known stuff): The fact > that an attacker cannot generate g^xy from g^x and g^y in itself is not > sufficient to guarantee that the scheme is secure. Even though an > attacker cannot exactly compute g^xy from g^x and g^y, she can still > guess 60%-80% of bits of g^xy with a high (~ 0.95) probability. (For > example, some people believe that the generator 2 leaks information > about x in 2^x (mod p) because 2^x = (1+1)^x = 1 + x + x(x-1)/2 + .... > by binomial expansion -- an expression with only x on right hand side. > Of course no one has shown, to the best of my knowledge, how to predict > the bits of g^xy (mod p) based on this or any similar information.) Ok. This was new to me. (I haven't been really following crypto since 1999.) > So to make the scheme more secure, what one needs is that given (g^x, > g^y, and g^xy) an attacker should not be able to distinguish it from > the > distribution of (g^x, g^y, and g^Random_number). There are lots of > papers on this problem (called the Decision Diffie-Hellman (DDH) > problem). I see. The first time I hear about this. Mea culpa. > To achieve this, g^xy is MACed to get rid of the non-uniform > distribution of bits of g^xy and make it look more like g^random_number > (actually if there is a better Pseudo Random Number Generator (PRG) > than > MACs, then that PRG should be used instead). > > For a MAC to generate a uniform distribution it should have enough > entropy in the input stream. Adding a nonce (or any random data) helps > in that sense. Note that the present KEYMAT also MACs the HITs, but > the amount of entropy of HITs combined (=127*2) is much less that the > size of g^xy (=1024 bits). So how much MAC will be able to get rid of > predictability of g^xy is not clear (it might be sufficient; I haven't > been closely following crypto stuff after 2001, so I don't know what > new developments have taken place). > > Adding the nonce in key generation might help from that POV. If you > don't want to add a nonce, then just adding some random data will also > help (e.g., using the entire R1 and I2 packets in KEYMAT generation). Good goal. However, my current suggestion would be not to add nonces to the base spec. Adding HMAC to I2 and revising the R2 HMAC looks small enough that we can do that easily and safely enough. But adding nonces seems to have architectural implications that I don't quite understand. Hence, I would leave that for later. What do others think? However, I would encourage you to work towards a revision of BLIND, perhaps together with Jukka. (I am currently too busy to write papers.) As the key generation in BLIND is, by necessity, different from base HIP, including the nonces into key generation seems like a natural thing. My personal guess is that we most probably want to adopt some aspects of BLIND for the next revision of HIP, but given the pressures to get a stable specification out for experimentation, I would leave all this nonce stuff for future, and not change the current spec in that respect. --Pekka From miika@iki.fi Mon Oct 11 03:11:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Oct 11 02:11:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: <4169F281.8000703@acm.org> References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Message-ID: On Sun, 10 Oct 2004, Yogesh Prem Swami wrote: > > As was discussed in other messages, parallel SAs between any > > given pair of HITs is a non-goal. I'd like to understand better > > your reference to pre-computed D-H keys by both parties. Would > > you care to explain? > > > > Let's say, both the sides, Alice and Bob, use precomputed values of g^x > and g^y. Let's also say that both Alice and Bob update their g^x and g^y > only once every hour. That means, during that one hour period, no matter > how many HIP exchange Alice and Bob do, they will end up with the same > Keys (the KEYMAT only contains g^xy and HIT-I and HIT-R all of which > will be the same). > > This can have quite a few security implications. For example, replay > protection will become weak, because an attacker can now inject packets > from previous sessions and simple sequence numbers and HMAC based > authentication will not be able to detect it (Assuming the session was > not using any form of Initialization Vectors). The base spec says: "The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes." The case for long period of DH regeneration may be valid for devices with limited CPU resources (e.g. PDAs or overloaded servers). At the moment, I cannot remember how much CPU resources DH generation eats up in practice. If we decide to tangle the nonce into the KEYMAT derivation, we can still use the current scheme, i.e., grab the nonce from the echo request/reply messages. The nonce propably needs to be sufficiently large so that it really enhances the security. For practical reasons, is may be better that the length of the nonce is constant. We should also note that we probably want the nonce to be covered by the signature because otherwise the nonce can be tampered by an passive attacker (i.e. rogue host in the path of the message). This is problematic from the view point of precreated R1s because changing the nonce requires changing the precreated R1s (or a yet another index, based on nonce, to the table of R1s). > >> 1. I->R: NCN-I, 0, HIT-I, [HIT-R] > >> > >> 2. R->I: NCN-I, NCN-R, HIT-R, HIT-I, g^r, PUBLIC_KEY-R, Domain-ID-R > >> SIG( HIT-R, g^r, PUBLIC_KEY-R) > >> > >> > >> 3. I->R: NCN-I, NCN-R, HIT-I, HIT-R, SPI-I, [R1_COUNTER], g^i, > >> { PUBLIC_KEY-I, Domain-ID-I }_g^ri, > >> SIG( HIT-I, HIT-R, SPI, g^i, > >> { PUBLIC_KEY-R, Domain-ID }_g^ri, ) > >> *HMAC(g^xy, HIT-I, PUBLIC_KEY-I, Domain-ID-R)* > >> > >> 4. R->I: NCN-I, NCN-R, HIT-R, HIT-I, SPI-R, SIG(HIT-R, HIT-I), > >> HMAC(g^xy, HIT-R, SPI-R, *HOST_ID-R*) /* HMAC content > >> has changed */ > > > > > > If I understand correctly, and leaving aside the issue of nonces, > > the only differences are the addition of HMAC to I2 and the > > change of the HMAC contents in R2. They seem OK to me. For practical reasons, maybe the HMAC should cover the whole packet, not just few fields. The overhead should not be too significant, and it should be easier to implement. In addition, I find the "pseudo-HMAC" scheme above a bit difficult to implement; in the third and fourth packets, the HMAC covers parameters that are not present in the packet (3. packet g^r, 4. packet g^ir). Alternatively, we could have: I2: IP ( HIP ( SPI, [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, /* g^i */ DIFFIE_HELLMAN, /* g^r (is this really needed?) */ HIP_TRANSFORM, ESP_TRANSFORM, ENCRYPTED { HOST_ID }, [ ECHO_RESPONSE ], HMAC, HIP_SIGNATURE, [ECHO_RESPONSE] ) ) R2: IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) In this version, the HMAC covers the whole I2. There is no pseudo-HMAC; the initiator has to include both of the DH parameters to the responder. I am not completely sure if both of DH parameters need to be sent in I2 (Yogesh, opinion?) but it seems to be so in the SIGMA. Maybe the pseudo-HMAC scheme is better from the viewpoint of security as you don't echo the g^ir again on the wire. Anyway, the g^ir has been exposed already. The R2 remains the same as in the current draft because I coupled HIP with SIGMA-I. I interpreted the R2 as an "SIGMA ACK" that guarantees the peer awareness property. In a more strict sense, the R2 is not just a plain ack because it includes the SPI. I don't see this as a problem because the HMAC already protects against R2 replication attacks (e.g. man-in-the-middle host tries to record R2s, and tries to DoS the initiator with incorrect SPIs). > > That doesn't help much, since in HIP the public key IS the real > > identifier. The hostname/NAI is only considered as auxliary > > information. You may learn the association between the public > > key and the hostname/NAI also from the DNS or some other databse. > > > > I agree. But the HIs alone are somewhat hard to work with. When a hosts > grants access to resources, it needs to know who the person on the other > side is, and that's why I consider names bound to HIs to be a > fundamental component to identity. This can also have scalability issues > (for example, with e-mail addresses you can grant access to every one > with address for example as *.acm.org. With HIs one will have to list > all the HIs, which is error prone and takes a lot more space). You need certificates to guarantee that hostname/NAI is not forged. Until then, it can be considered only as informational. > >> Later, > >> Responder can put Domain-ID as encrypted in message-4 and let Initiator > >> verify it against the MAC received in message-2. The advantage is that > >> we can now protect the identity of Initiator against passive attacker > >> and the Identity of responder against Active attackers. The disadvantage > >> is that the Initiator's ID cannot be protected against active attackers. > > > > It was a deliberate choice to err on protecting the initiator's > > privacy more than the responder's. > > But now, if an attacker, Eve, wants to get the Identity of the > Initiator, Alice, all Eve has to do is to just take Alice's HIT (from an > exchange that she started) and send an I1 to Alice. Alice, on seeing I1 > will herself give her identity out in R1. The scenario you described seems to be a valid concern. HIP, as currently specified, does not take as good care as SIGMA-I of the initiator's identity. However, the problem can be alleviated with the policies described by Pekka in the previous email. I don't understand how the encrypted domain-ID does the trick. IMHO, to really solve the case, we need to hide the initiator's HIT in the HIP header. Perhaps we could use blinded HITs in HIPv2 as already suggested in earlier email from Pekka. A null HIT for the initiator has other problems. Btw, I did not see a direct correspondence between SIGMA-I/R and HIP. For example, the responder's identity cannot be encrypted. Also, the first message in SIGMA-I/R contains already the public DH key of the initiator, and we need to move it to the third message in HIP. However, I don't think this was of great importantance in SIGMA. The emphasis was on the following rules-of-thumb that can reused also in HIP (as Yogesh already suggested): * keep the HMAC key different from the other keys derived from KEYMAT (as they are in HIP) * each packet should include either a NONCE or DH * DH is covered by the SIGNATURE * The HOST_ID is covered by the HMAC -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 11 07:15:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 06:15:01 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <416783AC.3050408@piuha.net> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> <416783AC.3050408@piuha.net> Message-ID: >>>> 9. If HIP negotiates base exchange using link locals, and one >>>> host moves, it will not be able to find its peer >>>> >>>> Suggested resolution: State that a host SHOULD provide its >>>> peer with a globally reachable IP address instead of relying >>>> exclusively on link-local addresses. >>> >>> (the same goes for site-local addresses) >> site-locals are deprecated, but I think we can address this >> generally by saying "locally scoped" or "non-global" address. > > Statistically unique site-local addresses would probably be OK > too, for usage within a site. The problem with the link-local > and old site local addresses was not just the connectivity > but also potential collisions; you could attempt talking to > a node which had nothing to do with the previous node you > talked with. The connectivity part is, however, not a major > problem as far as I can see. Even global addresses might > have connectivity problems in some cases, and we provide > multihoming primarily to combat this problem. I agree. However, I think a SHOULD for non-global is the right choice now, as we the Hinden-Haberman addresses are not quite RFC yet. If they become an RFC, we can return to this and revise? --Pekka From pekka.nikander@nomadiclab.com Mon Oct 11 07:22:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 06:22:01 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: > Here is proposed text for a replacement of the third paragraph in > Section 5.2: > "IPsec SAs are unidirectional, and the protocol may support > configurations > in which an asymmetric number of inbound and outbound SAs exist on a > given > host with respect to another host. However, for the purpose of > handling > multihoming more cleanly, it is RECOMMENDED that inbound and outbound > SAs > be created and maintained in a pairwise fashion between hosts, and that > when rekeying occurs on one SA, it is also triggered on the paired SA. > For > example, the HIP base exchange results in two SAs-- one inbound and one > outbound on each host. If one of the two hosts wants to advertise > another > interface to its peer, it should add a new inbound SA and send a REA > (and > NES) to the peer. The peer should also create a new inbound SA. These > two new SAs are also paired. Subsequently, when a rekey occurs on one > SA, > a corresponding rekey is performed on the paired SA, with no ambiguity. > Implementations that fail to follow the above guidelines may fail to > interoperate cleanly." Looks good to me other than the last statement, which I would tune down. Maybe: "Note that it is possible that implementations that fail to follow the above guidelines may fail to interoperate with some implementations. However, it is recommended that implementations attempt to support peers that prefer to utilise non-paired SAs." And, maybe add at least the following: "It is expected that this section and behaviour will be modified in some future revision of this protocol, once the issue and its implications are understood better." >> A conflict in 5th paragraph of section 7.1 Sending REAs: "All >> addresses >> corresponding to the SPI have the same lifetime." But the rest of the >> discussion on address lifetimes tells that each address have >> their own >> lifetimes. > > I think that the quoted sentence should be struck (maybe Pekka has > an opinion). The address lifetimes correspond to the IPv6 stateless > autoconfiguration lifetimes-- not necessarily the same for all > addresses. That sentence was an optimisation that allowed only one lifetime to be sent for a group of addresses. I don't remember how the packet format is today; the sentence can be removed if the packet format supports different lifetimes. --Pekka From jari.arkko@piuha.net Mon Oct 11 07:32:00 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon Oct 11 06:32:00 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> <416783AC.3050408@piuha.net> Message-ID: <416A70C2.5020807@piuha.net> Pekka Nikander wrote: > I agree. > > However, I think a SHOULD for non-global is the right choice now, > as we the Hinden-Haberman addresses are not quite RFC yet. > If they become an RFC, we can return to this and revise? Works for me. --Jari From mkousa@cc.hut.fi Mon Oct 11 07:38:00 2004 From: mkousa@cc.hut.fi (Mika Kousa) Date: Mon Oct 11 06:38:00 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: 5.1 Mobility with single SA pair Mobile Host Peer Host UPDATE(REA, SEQ) -----------------------------------> UPDATE(SPI, SEQ, ACK, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> Figure 3: Readdress without rekeying, but with address check Now that we have seen the change needed for address check procedure (ECHO_REQUESTs are sent to each of the addresses listed in the REA, see this same thread), this section needs some editing. Peer Host does not need to send ACK for the REA-UPDATE in every UPDATE it sends related to address check procedure, it could send just ACK-UPDATE and after that the Peer Host sends the ECHO_REQUEST-UPDATEs: For example: Mobile Host Peer Host UPDATE(REA(addr_1,addr_2), SEQ) -----------------------------------> UPDATE(ACK) <----------------------------------- sent to addr_1: UPDATE(SPI, SEQ, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> sent to addr_2: UPDATE(SPI, SEQ, ECHO_REQUEST) <----------------------------------- UPDATE(ACK, ECHO_RESPONSE) -----------------------------------> ... Maybe the other figures and related texts in section 5 need similar changes when there is a possibility that REA contains many addresses, too. From miika@iki.fi Mon Oct 11 08:04:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Oct 11 07:04:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Message-ID: On Mon, 11 Oct 2004, Miika Komu wrote: > We should also note that we probably want the nonce to be covered by the > signature because otherwise the nonce can be tampered by an passive > attacker (i.e. rogue host in the path of the message). This is problematic > from the view point of precreated R1s because changing the nonce requires > changing the precreated R1s (or a yet another index, based on nonce, to > the table of R1s). I'll take this back. The nonce does not have to be covered by the signature because the the purpose of the nonce is not to provide integrity protection. > For practical reasons, maybe the HMAC should cover the whole packet, not > just few fields. The overhead should not be too significant, and it should > be easier to implement. In addition, I find the "pseudo-HMAC" scheme above > a bit difficult to implement; in the third and fourth packets, the HMAC > covers parameters that are not present in the packet (3. packet g^r, 4. > packet g^ir). > > Alternatively, we could have: > > I2: IP ( HIP ( SPI, > [R1_COUNTER,] > SOLUTION, > DIFFIE_HELLMAN, /* g^i */ > DIFFIE_HELLMAN, /* g^r (is this really needed?) */ > HIP_TRANSFORM, > ESP_TRANSFORM, > ENCRYPTED { HOST_ID }, > [ ECHO_RESPONSE ], > HMAC, > HIP_SIGNATURE, > [ECHO_RESPONSE] ) ) > > R2: IP ( HIP ( SPI, HMAC, HIP_SIGNATURE ) ) > > In this version, the HMAC covers the whole I2. There is no pseudo-HMAC; > the initiator has to include both of the DH parameters to the responder. I > am not completely sure if both of DH parameters need to be sent in I2 > (Yogesh, opinion?) but it seems to be so in the SIGMA. Maybe the > pseudo-HMAC scheme is better from the viewpoint of security as you don't > echo the g^ir again on the wire. Anyway, the g^ir has been exposed > already. I think I misunderstood the notation here. g^ir (or g^xy) is the shared Diffie-Hellman secret, not the concatenation of the Diffie-Hellman parameters. Just forget my alternative above =) So, I guess we need to include the shared secret in the calculation of the HMAC in I2 and R2? Still, I am a bit confused why this should be done. Yogesh, would you care to explain this point in more depth? I am not a crypto specialist... -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 11 08:11:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 07:11:01 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Message-ID: >> For practical reasons, maybe the HMAC should cover the whole packet, >> not >> just few fields. The overhead should not be too significant, and it >> should >> be easier to implement. In addition, I find the "pseudo-HMAC" scheme >> above >> a bit difficult to implement; in the third and fourth packets, the >> HMAC >> covers parameters that are not present in the packet (3. packet g^r, >> 4. > > I think I misunderstood the notation here. g^ir (or g^xy) is the shared > Diffie-Hellman secret, not the concatenation of the Diffie-Hellman > parameters. Just forget my alternative above =) > > So, I guess we need to include the shared secret in the calculation of > the > HMAC in I2 and R2? Still, I am a bit confused why this should be done. > Yogesh, would you care to explain this point in more depth? I am not a > crypto specialist... For practical purposes, we apparently need to use a different HMAC parameter type for I2 and R2, as they do not cover the packets but extra-protocol information. But that also makes it easier to either place it under the signature or outside, dependent on which is better. --Pekka From miika@iki.fi Mon Oct 11 08:36:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Oct 11 07:36:01 2004 Subject: [Hipsec] Re: review of comments on draft-ietf-hip-mm-00 preview In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060893@xch-nw-27.nw.nos.boeing.com> Message-ID: On Fri, 8 Oct 2004, Henderson, Thomas R wrote: > Responding below to a number of (mostly Miika's) comments: (You are confusing me with Mika. Most of the comments were from Mika. To confuse even more, we also have a "Miikka" at work. Fortunately, for your sake, he is not working on anything related to HIP ;) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Julien.Laganier@Sun.COM Mon Oct 11 12:50:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 11 11:50:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <4166764D.1060401@nomadiclab.com> References: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4166764D.1060401@nomadiclab.com> Message-ID: <200410111858.59103.julien.laganier@sun.com> --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Friday 08 October 2004 13:13, Petri Jokela wrote: > Pekka Nikander wrote: > > Looks good, thanks! > > > > Maybe it would be better to have different messages for these > > purposes? That is, in the UNASSOCIATED state, if you receive > > a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable > > error code. In that way the CLOSE_ACK message would be only > > used for acknowledging CLOSE. > > > > A related issue is whether we should allow/require a "CLOSED" > > state. A host sending a CLOSE_ACK would enter a "CLOSED" > > state for a certain period (2 * timeout?), and during that > > time it would be able to send further CLOSE_ACK messages in the > > case it gets another CLOSE. (Maybe the CLOSE_ACK was lost.) > > It would then automatically move to UNASSOCIATED if it receives > > no CLOSE messages within that period. > > > > I don't think the CLOSED state is necessarily needed, or should > > be mandated, but it sounds to be as a nice engineering > > optimisation that some implementations might want to do. > > Thanks Julien for the text! > > I modified a bit Julien's proposal according to Pekka's comments. > My notes are included in the text. Outgoing/incoming data traffic > text needs still something For example when the association is not > dropped in the CLOSED state and there is some data that would > belong to this association. Thanks Pekka and Petri, the modified text looks quite good. Attached are some answers/questions, correction to the text and suggested text for Security Considerations. Cheers, --julien --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA) Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK2 Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=CLOSEACK2 5.4.2 =A0HIP State Processes <**PJ**> =A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOS= E, not =A0 =A0 =A0 =A0 =A0written down here <**PJ**> <**JL**> Why not? <**JL**> =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED| =A0Start state =A0 =A0 +------------+ =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED =A0 =A0 Receive CLOSE for unknown association, optionnaly send NOTIFY as defined in section XXX and stay at UNASSOCIATED =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED <**PJ**> =A0 =A0 =A0 =A0 =A0ESTABLISHED: Go to CLOSED instead of UNASSOCIATED <**PJ**> =A0 =A0 +------------+ =A0 =A0 |ESTABLISHED | HIP SA established =A0 =A0 +------------+ =A0 =A0 Receive I1, send R1 and stay at ESTABLISHED =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 Receive I2, process with cookie and possible Opaque data verificati= on =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2, drop old SAs, establish new= SA, go to =A0=A0=A0=A0=A0=A0=A0=A0R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at ESTABLISHED =A0 =A0 Receive R1, drop and stay at ESTABLISHED =A0 =A0 Receive R2, drop and stay at ESTABLISHED =A0 =A0 Receive ESP for SA, process and stay at ESTABLISHED =A0 =A0 Receive UPDATE, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send UPDATE in reply and go to REKEY= ING =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 Need rekey, send UPDATE and go to REKEYING =A0 =A0 No packet sent/received during UAL minutes, send CLOSE and =A0 =A0 =A0=A0=A0=A0go to CLOSING. =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK and go to CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED <**PJ**> =A0 =A0 =A0 =A0 =A0Closing: Move to CLOSED after sending CLOSE_ACK instead = of =A0 =A0 =A0 =A0 =A0UNASSOCIATED <**PJ**> =A0 =A0 +---------+ =A0 =A0 | CLOSING | HIP association has not been used for UAL (Unused =A0 =A0 +---------+ Association Lifetime) minutes. =A0 =A0 Datagram to send, requires creation of another HIP association =A0=A0=A0=A0=A0=A0=A0=A0in UNASSOCIATED state (which will send I1 and go to= I1-SENT) =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, discard state and go to = CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive ANYOTHER, drop and stay at CLOSING =A0 =A0 Timeout, increment timeout sum, reset timer =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is less than UAL+MSL minutes, retran= smit CLOSE =A0=A0=A0=A0=A0=A0=A0=A0 =A0and stay at CLOSING =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is greater than UAL+MSL minutes, go = to =A0 =A0 =A0 =A0 =A0 =A0UNASSOCIATED <**PJ**> =A0 =A0 =A0 =A0 =A0CLOSED is a new state. Timeout sum should be 2*MSL or so= mething =A0 =A0 =A0 =A0 =A0else?? <**PJ**> <**JL**> The 'active closer' might retransmit a CLOSE during UAL + MSL, so I think a host entering CLOSED should wait for UAL + 2MSL before going to=20 UNASSOCIATED. Also, there's no need for 'timeout sun' or 'counter', nor to reset timer here. =A0 =A0 +--------+ =A0 =A0 | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary =A0 =A0 +--------+ =A0 =A0 Datagram to send, requires creation of another HIP association =A0=A0=A0=A0=A0=A0=A0=A0in UNASSOCIATED state (which will send I1 and go to= I1-SENT) =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, stay at CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive ANYOTHER, drop and stay at CLOSED Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED 5.4.3 =A0Simplified HIP State Diagram =A0 =A0 =A0 =A0 +-+ =A0 =A0 =A0 =A0 | | CLOSE received, send NOTIFY =A0 =A0 =A0 =A0 V ^ =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED|<----------------------+ =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| Timeout, move to =A0 =A0 =A0 =A0 =A0 | CLOSE_ACK received, or =A0 =A0 =A0 | UNASSOCIATED =A0 =A0 =A0 =A0 =A0 | timeout sum > UAL+MSL =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-= =2D------+ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0rec CLOSE, =A0 =A0 +--->| CLOSED |----+ =A0 =A0 =A0+---------+ send CLOSE_ACK | =A0 =A0+--------+ =A0 =A0| CLOSE re= ceived, =A0 =A0 =A0| CLOSING |----------------+ =A0 =A0 =A0 =A0| =A0 ^ =A0 =A0 | se= nd CLOSE_ACK =A0 =A0 =A0| =A0 =A0 =A0 =A0 |-----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 | =A0 =A0 | =A0 =A0 =A0+---------+ =A0 =A0 | timeout sum =A0 =A0 =A0 | =A0 +-----+ =A0 =A0 =A0 =A0 =A0 ^ =A0 ^ =A0 =A0 =A0| < UAL+MSL, =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 +------+ retransmit CLOSE =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 | No packet sent/received =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | for UAL min, send CLOSE =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| CLOSE received, =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | send C= LOSE_ACK =A0 =A0 |ESTABLISHED |>----------------------+ =A0 =A0 +------------+ =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0Removed optional things, NOTIFY is sent in UNASSOCIATED = state <**PJ**> 7.11 =A0CLOSE_ACK - the HIP closing acknowledgment packet =A0 =A0 The HIP header values for the CLOSE_ACK packet: =A0 =A0 Header: =A0=A0=A0=A0=A0=A0=A0=A0Packet Type =3D XXX Tbd. =A0=A0=A0=A0=A0=A0=A0=A0SRC HIT =3D Sender's HIT =A0=A0=A0=A0=A0=A0=A0=A0DST HIT =3D Recipient's HIT =A0 =A0 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) =A0 =A0 Valid control bits: none =A0 =A0 The sender MUST include both an HMAC and signature (calculated over =A0 =A0 the whole HIP envelope). =A0 =A0 The receiver peer MUST validate both the HMAC and the signature. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0We don't discard the state before we move to UNASSOCIATE= D. =A0 =A0 =A0 =A0 =A0- If we want to send data? We cannot use the old associa= tion =A0 =A0 =A0 =A0 =A0any longer, we need to start a new negotiation. That par= t of =A0 =A0 =A0 =A0 =A0the text needs maybe some clarification. <**PJ**> <**JL**> If a node needs to send data while in CLOSING or CLOSED state, a new exchange must be initiated by sending an I1. The problem is that both=20 nodes needs a means to distinguish packets from two incarnations of a same HIP association between two HIs. If a node receives an I1 while in CLOSING or CLOSED, or even if ESTABLISHED (if a CLOSE was lost), it would=20 create another HIP state and handle all inbound packets but CLOSE and=20 CLOSE_ACK with this new state. I found this approach ambiguous and a=20 bit naive (what happens if the new association is then closed ??).=20 That's one of the reason I've been advocating in the past for having either NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another possibility=20 might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and CLOSE_ACK=20 and use it to demultiplex the packets to the correct state. What does other people think? <**JL**> 8.16 Processing CLOSE packets =A0 =A0 When the host receives a CLOSE message it responds with a CLOSE_ACK =A0 =A0 message and moves to CLOSED state. =A0(The authenticity of the CLOSE =A0 =A0 message is verified using both HMAC and SIGNATURE). This processing =A0 =A0 applies whether or not the HIP association state is CLOSING in order =A0 =A0 to handle CLOSE messages from both ends crossing in flight. =A0 =A0 The HIP association is not discarded before the host moves from the =A0 =A0 UNASSOCIATED state. =A0 =A0 Once the closing process has started, any need to send data packets =A0 =A0 will trigger creating and establishing of a new HIP association, =A0 =A0 starting with sending an I1. =A0 =A0 A CLOSE message which is received when there is no HIP association =A0 =A0 state can not be verified but will result in a NOTIFY response. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0Optional things removed. ACK also accepted in CLOSED sta= te if we =A0 =A0 =A0 =A0 =A0have earlier sent CLOSE related to the same association: =A0 =A0 =A0 =A0 =A0ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, se= nd =A0 =A0 =A0 =A0 =A0CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent= CLOSE =A0 =A0 =A0 =A0 =A0->... <**PJ**> 8.17 Processing CLOSE_ACK packets =A0 =A0 When a host receives a CLOSE_ACK message it verifies that it is in =A0 =A0 CLOSING or CLOSED state and that the CLOSE_ACK was in response to t= he =A0 =A0 CLOSE (using the included ECHO_REPLY in response to the sent =A0 =A0 ECHO_REQUEST). =A0 =A0 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state =A0 =A0 is discarded when the state changes to UNASSOCIATED and, after that, =A0 =A0 NOTIFY is sent as a response to a CLOSE message. =2D---------------------------------------------------------------- <**PJ**> =A0 =A0 =A0 =A0 =A0New NOTIFY <**PJ**> 6.2.19 NOTIFY =A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A044 =A0 =A0 =A0 =A0 =A0 The received CLOSE message referred to an =A0 =A0 =A0 =A0 =A0 association that does not exist. =2D------------------------------------------------------------------ <**JL**> Below is suggested text to replace this paragraph of the Security Considera= tions: A fourth form of DoS attack is emulating the end of state. HIP has no end of state packet. It relies on a local policy timer to end state. A fourth form of DoS attack is emulating the end of state. HIP relies on= timers plus a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be= cause both CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a= connection. The presence of an additional SIGNATURE allows middle-boxes to inspect t= hese messages and discard the associated state (for e.g., firewalling, SPI-based NATin= g, etc.). However, the optionnal behavior of replying to CLOSE with a NOTIFY while= in UNASSOCIATED state might allow a spoofer sending CLOSE messages to launch reflexion attacks= =2E=20 =2D------------------------------------------------------------------------= =2D---= --Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)-- From yogesh.swami@acm.org Mon Oct 11 13:45:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Mon Oct 11 12:45:01 2004 Subject: Multiple parallel SAs (was Re: [Hipsec] NONCE parameter in base exchange?) In-Reply-To: <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <4169F148.8010502@acm.org> <53359DEC-1B4B-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <416AC836.8010802@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFBA5A59C0068240556F1285D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pekka, I am okay with not using NONCE. Also, as I have said before, it's important to get some implementation experience with the present draft. I'll get to other e-mails later on (in a couple of days). Yogesh ext Pekka Nikander wrote: >> If I understand right, I guess the traffic selector is the main >> objection that people have for not using nonce. But as Julien >> pointed out, one can use "populate from packets" (PFP) to setup >> the filters. > > > As far as I have understood the thinking of the community (the > chairs may correct), the current belief is that if someone wants > to have traffic selectors and multiple parallel SAs for policy > reason, the right thing to do is to write an extension, present > it at the RG side, and sense the feeling of the community at the > re-chartering time. Hence, IMHO, that discussion should be moved > to the RG mailing list. > >> Also, I am not sure how multiple HIs help. If you have a BITW >> implementation of IPsec, you still need some mechanism to tell >> the IPsec filter to select packets based on IP address/port-numbers >> (the HITs are not present in the packets) > > > At least my understanding has been that iff you are dealing > with legacy hosts and therefore BITW IPsec, you just configure > your host to use either LSIs (1.0.0.0/8) or HITs (4000::0/2) > on the local link. Contrary what the docs says, in that special > case you do have LSIs or HITs in IP headers on the wire. > Hence, you will have HITs (or at least LSIs) even in a BITW > implementation. Other than that, properply implementing HIP > support on a BITW box is pretty impossible. > > --Pekka > > > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec --------------enigFBA5A59C0068240556F1285D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWrIOXkjMhOId4nzAQLf1Qf/WhpNFLb0ZX64yPRGWi8UFQta12J263jV XTF+ms9J+orqpiLQiNHr8ctBM4w1RjE1BcetWqvPrYggcAo53pEP74OszM9Kes6N VozcT5b2IvFbruZ1goB+D8TagNxMHIr+T3XDfL6Z6G6ANmv+KzQGChTPdXDRsFw+ 4X6QWxEXPsBxcfMidrM9rAb8smfiCZ8wuXF40PTQDJ9OuEBPFAKWIqs0uZfi8pDl nDfoMA6XmncOjPm0yhDgIZDxK+yedzuGktcJbvF/VOv7LqhxWjh68huUcsZ5bBAt O7FsnKrtKGgbaU9CVDUuU+65D4cWitUIxLFn0GMwFiagdBDn7bErcA== =dkiL -----END PGP SIGNATURE----- --------------enigFBA5A59C0068240556F1285D-- From pekka.nikander@nomadiclab.com Mon Oct 11 14:19:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 11 13:19:01 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <200410111858.59103.julien.laganier@sun.com> References: <19F844C5-18FF-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4166764D.1060401@nomadiclab.com> <200410111858.59103.julien.laganier@sun.com> Message-ID: <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> Some details: > 5.4.2 =A0HIP State Processes > > <**PJ**> > =A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming = CLOSE, not > =A0 =A0 =A0 =A0 =A0written down here > <**PJ**> > > <**JL**> > Why not? > <**JL**> Actually, it should be ICMP parameter problem with pointer pointing to something useful, e.g., sender's HIT. That would be an indication that such an association does not exist. The same could be used also for received UPDATE, R2, and perhaps PAYLOAD, when the HIP association has been dropped. I would suggest a new section 6.3.5. 6.3.5. Non-existing HIP association If a HIP implementation receives a CLOSE, UPDATE, or PAYLOAD packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate limited, with an ICMP packet with the type Parameter Problem, the Pointer pointing to the the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, BOS, CER, and NOTIFY. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP replies. 8.11. 0. If there is no corresponding HIP association, the implementation MAY reply with an ICMP Parameter Problem, as specified in 6.3.5. > =A0 =A0 +------------+ > =A0 =A0 |UNASSOCIATED| =A0Start state > =A0 =A0 +------------+ > > =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT > =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED > =A0 =A0 Receive I2, process > =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT > =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED > > =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined > =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED > =A0 =A0 Receive CLOSE for unknown association, optionnaly send NOTIFY > as defined in section XXX and stay at UNASSOCIATED > =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED Before "receive anyother": Receive CLOSE, UPDATE, or PAYLOAD, optionally send ICMP Parameter Problem and stay in UNASSOCIATED. In CLOSING and CLOSED, if you receive I1 or I2, you should handle them=20= just as if you were in UNASSOCIATED. In I1 case, stay in the state where you are but reply with an R1. In I2 case, try to process, and if=20 successful, move to R2-SENT, otherwise stay where where you are. Some more text in Sec 8 probably needs to be revised. Please check. > <**JL**> > If a node needs to send data while in CLOSING or CLOSED state, a new > exchange must be initiated by sending an I1. The problem is that both > nodes needs a means to distinguish packets from two incarnations of a > same HIP association between two HIs. If a node receives an I1 while = in > CLOSING or CLOSED, or even if ESTABLISHED (if a CLOSE was lost), it=20 > would > create another HIP state and handle all inbound packets but CLOSE and > CLOSE_ACK with this new state. I found this approach ambiguous and a > bit naive (what happens if the new association is then closed ??). > That's one of the reason I've been advocating in the past for having=20= > either > NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another=20 > possibility > might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and=20 > CLOSE_ACK > and use it to demultiplex the packets to the correct state. > > What does other people think? > <**JL**> Reuse SEQ from UPDATE for CLOSE? > <**PJ**> > =A0 =A0 =A0 =A0 =A0New NOTIFY > <**PJ**> > > 6.2.19 NOTIFY > > > =A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A044 > > =A0 =A0 =A0 =A0 =A0 The received CLOSE message referred to an > =A0 =A0 =A0 =A0 =A0 association that does not exist. Not needed as we should use ICMP. Sorry for forgetting about my own guidelines. The last line of the suggested Sec Cons text must refer to ICMP, not NOTIFY. --Pekka From pekka.nikander@nomadiclab.com Tue Oct 12 03:42:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 12 02:42:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Message-ID: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> Here is my attempt for some new text to the arch draft: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2, together with Host Identifiers to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, the authors feel that the way IKE used UDP is architecturally wrong. A protocol controlling another protocol (like ICMP controlling IP) should be located either at the same layer with or the layer immediately above the controlled protocol, unless there are important reasons for doing otherwise. For example, in the case of IKE, the current design requires that certain UDP ports are excepted from the normal policy processing. Second, IKE and IKEv2 are, by design, very secure protocols. As an unfortunate side effect, that makes them unfriendly towards middle boxes. As adding a new naming layer allows one to potentially add a new forwarding layer, it is very important that the HIP protocols are friendly towards any middle boxes. Third, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. Future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. Comments? --Pekka From pekka.nikander@nomadiclab.com Tue Oct 12 03:51:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 12 02:51:00 2004 Subject: [Hipsec] SA granularity Message-ID: I wrote: > Supporting multiple parallel SAs between any pair of HIs > has been a non-goal for HIP from the beginning. The mobility > and multi-homing extension adds such a feature, but _only_ > for dealing with replay window problems. > > If this non-goal is not clear from the base spec / arch spec, > we need to add explicit text. And I guess the case is so, > since we've faced this same issue before. > > Anyone willing to draft text to be included in both/either of > the drafts, noting that _architecturally_ HIP only considers > host-to-host granularity, and any finer granularity is FFS? Here is the proposed text to clarify this issue: ... In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. Comments? --Pekka From jari.arkko@piuha.net Tue Oct 12 05:14:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Oct 12 04:14:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <416BA1F7.50608@piuha.net> Hi Pekka, and thanks for your text. It looks good. A couple of nits and comments below, however: > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for > this, and there are also a few architectural reasons. First, the > authors feel that the way IKE used UDP is architecturally wrong. > A protocol controlling another protocol (like ICMP controlling > IP) should be located either at the same layer with or the layer > immediately above the controlled protocol, unless there are > important reasons for doing otherwise. For example, in the case > of IKE, the current design requires that certain UDP ports are > excepted from the normal policy processing. Well, presumably the HIP protocol number would also be excepted? Suggestion: delete the example. > Second, IKE and IKEv2 are, by design, very secure protocols. I have a feeling that the parts of the design that affect middle boxes are more of an accident that design on purpose. I wasn't present when the protocols were being designed, but look at IPsec NAT traversal, for instance. Due to the placement of the SPIs deep inside the packet in an encrypted part and unidirectional SAs, NAT passage was not possible. In latest standards this has been fixed by UDP tunneling which on the other hand is quite open to modifications by middle boxes or even other parties. Suggestion: just say that the IKE-IPsec protocol set has not been designed with middle boxes in mind. > As an unfortunate side effect, that makes them unfriendly > towards middle boxes. As adding a new naming layer allows one > to potentially add a new forwarding layer, it is very important > that the HIP protocols are friendly towards any middle boxes. > > Third, from a conceptual point of view, the IPsec Security > Parameter Index (SPI) in ESP provides a simple compression of > the HITs. This does require per-HIT-pair SAs (and SPIs), and a > decrease of policy granularity over other Key Management > Protocols, such as IKE and IKEv2. Future HIP extensions may > provide for more granularity and creation of several ESP SAs > between a pair of HITs. --Jari From pekka.nikander@nomadiclab.com Tue Oct 12 05:23:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 12 04:23:00 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <416BA1F7.50608@piuha.net> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> Message-ID: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> Tnx, Jari. Here is the revised text: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2, together with Host Identifiers to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, the authors feel that the way IKE uses UDP is architecturally wrong. A protocol controlling another protocol (like ICMP controlling IP) should be located either at the same layer with or the layer immediately above the controlled protocol, unless there are important reasons for doing otherwise. Second, IKE and IKEv2 were not design with middle boxes in mind. As adding a new naming layer allows one to potentially add a new forwarding layer (see Section , below), it is very important that the HIP protocols are friendly towards any middle boxes. Third, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. --Pekka From Julien.Laganier@Sun.COM Tue Oct 12 07:11:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Oct 12 06:11:00 2004 Subject: [Hipsec] Recovery from state loss In-Reply-To: <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <200410111858.59103.julien.laganier@sun.com> <2632ABCC-1BB3-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <200410121320.35384.julien.laganier@sun.com> --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Monday 11 October 2004 20:27, Pekka Nikander wrote: > Some details Taking Pekka's comments in account, and adding a rule for transition to I2_SENT while receiving R1 in CLOSING or CLOSED, the new modified text should include what follows (I didn't modified the state diagram to reflect transition to I2-SENT and R2-SENT from CLOSING/CLOSED). Thanks, --julien ----------------------------------------------------------------------- --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw) Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK3 Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=CLOSEACK3 Taking Pekka's comments in account, and adding a rule for transition=20 to I2_SENT while receiving R1 in CLOSING or CLOSED, the new modified text should include the following (I didn't modified the state diagram to reflect transition to I2-SENT and R2-SENT from CLOSING/CLOSED) : =2D---------------------------------------------------------------- 5.4.2 =A0HIP State Processes =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED| =A0Start state =A0 =A0 +------------+ =A0 =A0 Datagram to send requiring a new SA, send I1 and go to I1-SENT =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at UNASSOCIATED =A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined =A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED Receive CLOSE, UPDATE, or PAYLOAD, optionally send ICMP Parameter Problem and stay in UNASSOCIATED. =A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED =A0 =A0 +------------+ =A0 =A0 |ESTABLISHED | HIP SA established =A0 =A0 +------------+ =A0 =A0 Receive I1, send R1 and stay at ESTABLISHED =A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0 Receive I2, process with cookie and possible Opaque data verificati= on =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2, drop old SAs, establish new= SA, go to =A0=A0=A0=A0=A0=A0=A0=A0R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at ESTABLISHED =A0 =A0 Receive R1, drop and stay at ESTABLISHED =A0 =A0 Receive R2, drop and stay at ESTABLISHED =A0 =A0 Receive ESP for SA, process and stay at ESTABLISHED =A0 =A0 Receive UPDATE, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send UPDATE in reply and go to REKEY= ING =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 Need rekey, send UPDATE and go to REKEYING =A0 =A0 No packet sent/received during UAL minutes, send CLOSE and =A0 =A0 =A0=A0=A0=A0go to CLOSING. =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK and go to CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at ESTABLISHED =A0 =A0 +---------+ =A0 =A0 | CLOSING | HIP association has not been used for UAL (Unused =A0 =A0 +---------+ Association Lifetime) minutes. =A0 =A0 Datagram to send, requires the creation of another incarnation of the HIP association, started by sending an I1, and stay at CLOSING =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSING Receive R1, process if successful, send I2 and go to I2-SENT if fail, stay at CLOSING =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, discard state and go to = CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSING =A0 =A0 Receive ANYOTHER, drop and stay at CLOSING =A0 =A0 Timeout, increment timeout sum, reset timer =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is less than UAL+MSL minutes, retran= smit CLOSE =A0=A0=A0=A0=A0=A0=A0=A0 =A0and stay at CLOSING =A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is greater than UAL+MSL minutes, go = to =A0 =A0 =A0 =A0 =A0 =A0UNASSOCIATED =A0 =A0 +--------+ =A0 =A0 | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary =A0 =A0 +--------+ =A0 =A0 Datagram to send, requires the creation of another incarnation of the HIP association, started by sending an I1, and stay at CLOSED =A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED =A0 =A0 Receive I2, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT =A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSED Receive R1, process if successful, send I2 and go to I2-SENT if fail, stay at CLOSED =A0 =A0 Receive CLOSE, process =A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, stay at CLOSED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive CLOSE_ACK, process =A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED =A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED =A0 =A0 Receive ANYOTHER, drop and stay at CLOSED Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED =2D---------------------------------------------------------------- 5.4.3 =A0Simplified HIP State Diagram =A0 =A0 =A0 =A0 +-+ =A0 =A0 =A0 =A0 | | CLOSE received, send NOTIFY =A0 =A0 =A0 =A0 V ^ =A0 =A0 +------------+ =A0 =A0 |UNASSOCIATED|<----------------------+ =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| Timeout, move to =A0 =A0 =A0 =A0 =A0 | CLOSE_ACK received, or =A0 =A0 =A0 | UNASSOCIATED =A0 =A0 =A0 =A0 =A0 | timeout sum > UAL+MSL =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-= =2D------+ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0rec CLOSE, =A0 =A0 +--->| CLOSED |----+ =A0 =A0 =A0+---------+ send CLOSE_ACK | =A0 =A0+--------+ =A0 =A0| CLOSE re= ceived, =A0 =A0 =A0| CLOSING |----------------+ =A0 =A0 =A0 =A0| =A0 ^ =A0 =A0 | se= nd CLOSE_ACK =A0 =A0 =A0| =A0 =A0 =A0 =A0 |-----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | = =A0 | =A0 =A0 | =A0 =A0 =A0+---------+ =A0 =A0 | timeout sum =A0 =A0 =A0 | =A0 +-----+ =A0 =A0 =A0 =A0 =A0 ^ =A0 ^ =A0 =A0 =A0| < UAL+MSL, =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 +------+ retransmit CLOSE =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 | No packet sent/received =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | for UAL min, send CLOSE =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| CLOSE received, =A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | send C= LOSE_ACK =A0 =A0 |ESTABLISHED |>----------------------+ =A0 =A0 +------------+ =2D---------------------------------------------------------------- 6.3.5. Non-existing HIP association If a HIP implementation receives a CLOSE, UPDATE, or PAYLOAD packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate limited, with an ICMP packet with the type Parameter Problem, the Pointer pointing to the the beginning of the first HIT that does not match. A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, BOS, CER, and NOTIFY. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP replies. =2D---------------------------------------------------------------- 8.11 Processing UPDATE packets 0. If there is no corresponding HIP association, the implementation MAY reply with an ICMP Parameter Problem, as specified in 6.3.5. =2D---------------------------------------------------------------- 7.11 =A0CLOSE_ACK - the HIP closing acknowledgment packet =A0 =A0 The HIP header values for the CLOSE_ACK packet: =A0 =A0 Header: =A0=A0=A0=A0=A0=A0=A0=A0Packet Type =3D XXX Tbd. =A0=A0=A0=A0=A0=A0=A0=A0SRC HIT =3D Sender's HIT =A0=A0=A0=A0=A0=A0=A0=A0DST HIT =3D Recipient's HIT =A0 =A0 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) ) =A0 =A0 Valid control bits: none =A0 =A0 The sender MUST include both an HMAC and signature (calculated over =A0 =A0 the whole HIP envelope). =A0 =A0 The receiver peer MUST validate both the HMAC and the signature. =2D---------------------------------------------------------------- 8.16 Processing CLOSE packets =A0 =A0 When the host receives a CLOSE message it responds with a CLOSE_ACK =A0 =A0 message and moves to CLOSED state. =A0(The authenticity of the CLOSE =A0 =A0 message is verified using both HMAC and SIGNATURE). This processing =A0 =A0 applies whether or not the HIP association state is CLOSING in order =A0 =A0 to handle CLOSE messages from both ends crossing in flight. =A0 =A0 The HIP association is not discarded before the host moves from the =A0 =A0 UNASSOCIATED state. =A0 =A0 Once the closing process has started, any need to send data packets =A0 =A0 will trigger creating and establishing of a new HIP association, =A0 =A0 starting with sending an I1. If there is no corresponding HIP association, the implementation MAY reply to a CLOSE with an ICMP Parameter Problem, as i specified in 6.3.5. =2D---------------------------------------------------------------- 8.17 Processing CLOSE_ACK packets =A0 =A0 When a host receives a CLOSE_ACK message it verifies that it is in =A0 =A0 CLOSING or CLOSED state and that the CLOSE_ACK was in response to t= he =A0 =A0 CLOSE (using the included ECHO_REPLY in response to the sent =A0 =A0 ECHO_REQUEST). =A0 =A0 The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state =A0 =A0 is discarded when the state changes to UNASSOCIATED and, after that, =A0 =A0 NOTIFY is sent as a response to a CLOSE message. =2D---------------------------------------------------------------- A fourth form of DoS attack is emulating the end of state. HIP has no end of state packet. It relies on a local policy timer to end state. A fourth form of DoS attack is emulating the end of state. HIP relies on= timers plus a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be= cause both CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a= connection. The presence of an additional SIGNATURE allows middle-boxes to inspect t= hese messages and discard the associated state (for e.g., firewalling, SPI-based NATin= g, etc.). However, the optionnal behavior of replying to CLOSE with an ICMP Parame= ter Problem=20 packet (as described in Section 6.3.5), might allow an IP spoofer sendin= g CLOSE messages to launch reflexion attacks.=20 =2D------------------------------------------------------------------------= =2D---= --Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)-- From pekka.nikander@nomadiclab.com Tue Oct 12 07:17:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Oct 12 06:17:01 2004 Subject: [Hipsec] A new pre version of the HIP arch draft available Message-ID: <78067BDE-1C41-11D9-97E8-000D9331AFB0@nomadiclab.com> Folks, We agreed with the ADs that the HIP architecture draft will become a WG item, with the intention of going through a WG LC and then proceeding quickly to the IESG. A preliminary version of the draft is now available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-pre-Oct12.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-pre-Oct12.html I plan to submit it within a few days to the repositories, and expect the chairs to announce a WG LC soon after that. --Pekka From Julien.Laganier@Sun.COM Tue Oct 12 07:41:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Oct 12 06:41:01 2004 Subject: [Hipsec] Pre-version of 'HIP DNS Extensions' I-D Message-ID: <200410121350.22666.julien.laganier@sun.com> Folks, We plan to submit this draft as a WG item (draft-ietf-hip-rvs-00) within a few days (deadline is on Monday, 9:00 ET). In the meantime, it is available here: Thanks, -- Julien Laganier SUN Microsystems Laboratories From Julien.Laganier@Sun.COM Tue Oct 12 07:44:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Oct 12 06:44:01 2004 Subject: [Hipsec] Pre-version of 'HIP Rendezvous Extensions' I-D Message-ID: <200410121353.57902.julien.laganier@sun.com> Folks, We plan to submit this draft as a WG item (draft-ietf-hip-rvs-00) within a few days (deadline is on Monday, 9:00 ET). In the meantime, it is available here: Thanks, -- Julien Laganier SUN Microsystems Laboratories From Julien.Laganier@Sun.COM Tue Oct 12 12:49:03 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Tue Oct 12 11:49:03 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <416543F8.6040006@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <416543F8.6040006@piuha.net> Message-ID: <200410121858.38644.julien.laganier@sun.com> On Thursday 07 October 2004 15:26, Jari Arkko wrote: > There used to be IPR concerns with RSA, but I believe > the patents expired. ECC is a mine field of IPR, so > I'd rather stay out of it if possible. > > I'd go for RSA, personally. > > --Jari So how does people feel about making both DSA and RSA mandatory in HIP? Thanks, --julien > Julien Laganier wrote: > > Hi Folks, > > > > Looking at the paper "Experience with the Host Identity Protocol > > for Secure Mobility and Multihoming" by Henderson et al., I found > > that DSA signing and verification account for a huge part of the > > association set-up latency. > > > > Hence, I am wondering what is the rationale for HIP to specify > > DSA as a MANDATORY algorithm, although RSA signatures > > verification might be ten times faster than DSA? > > > > Also what about using Elliptic Curve Cryptography (e.g., EC-DSA) > > which has reduced P.K. and signatures size, and can be as fast or > > faster than RSA? > > > > Thanks, > > > > --julien From yushunwa@ISI.EDU Tue Oct 12 13:07:03 2004 From: yushunwa@ISI.EDU (Yu-Shun Wang) Date: Tue Oct 12 12:07:03 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <416C1106.6050609@isi.edu> This is a cryptographically signed message in MIME format. --------------ms050302090005000406040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Pekka & all, Jumping into this really, really late. Aplogized in advance if I missed some previous context. I am not a big fan of IKE (v1/v2), but just feel something is still missing in the reasoning below. Pekka Nikander wrote: > Here is the revised text: > > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for this, > and there are also a few architectural reasons. First, the > authors feel that the way IKE uses UDP is architecturally wrong. > A protocol controlling another protocol (like ICMP controlling > IP) should be located either at the same layer with or the layer > immediately above the controlled protocol, unless there are > important reasons for doing otherwise. I am not sure about this argument. In a way, the HIP exchange is analogous to DNS, you contact somebody to resolve an identity in one domain into an identity in another domain. It just happens in this case the 'somebody' is also the destination you want to communicate with. This exchange should be considered a separate communication, and is free to use whatever protocol or even out- of-band information if available. It is just a process of resolving identities, I am a bit unsure about the phrase "A protocol controlling another protocol..." Maybe I miss something here? > Second, IKE and IKEv2 were not design with middle boxes in > mind. As adding a new naming layer allows one to potentially add > a new forwarding layer (see Section , below), > it is very important that the HIP protocols are friendly towards > any middle boxes. Not a very strong one, but I agree. > Third, from a conceptual point of view, the IPsec Security > Parameter Index (SPI) in ESP provides a simple compression of > the HITs. This does require per-HIT-pair SAs (and SPIs), and a > decrease of policy granularity over other Key Management > Protocols, such as IKE and IKEv2. In particular, the current > thinking is limited to a situation where, conceptually, there is > only one pair of SAs between any given pair of HITs. In other > words, from an architectural point of view, HIP only supports > host-to-host (or endpoint-to-endpoint) Security Associations. > If two hosts need more pairs of parallel SAs, they should use > separate HITs for that. However, future HIP extensions may > provide for more granularity and creation of several ESP SAs > between a pair of HITs. This sounds like what we want is a subset of what IKEv1/v2 have. This is an efficiency and optimization issue. I guess what I'd like to see is a more compelling reasoning why we have to use a different protocol. Otherwise another side of the argument would be why not define HIP exchange as a profile of IKE to save the trouble of inventing another protocol? (I'm sure you hear about all that by now. Maybe even an ID in the work?) (Again, I missed the previous discussion. Feel free to give me pointers if all have been said.) Thanks, yushun > --Pekka > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec -- Yu-Shun Wang USC Information Sciences Institute --------------ms050302090005000406040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MTAxMjE3MTQ0NlowIwYJKoZIhvcNAQkEMRYEFG17yjofeVfpU2qES3u5Lt9o 6zAqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBADDLoWv7fc59oLv47xgrVvwfT5OFAmwIuc4a unRvM54bjOG4NjEzVenrKvXWKMs46e+XknBK2r2Cbn/QJJVJx6szcuzD+WuM1yfSXRAsIMgt sofKoBu4M8fxM0jrLRvwhuhted/Am29oO6f+FUvY8Z1PkCHO6Nn29+1qcTZNKVaQczOXU2M+ cxgaswcStWmYIIxsOoDRkw53cp7yaD+NDviQkqlTtT9Dasiqk6MeU6vSq9yyyOissRd3V4MM AOGk61eddlpc7Pt5emT7vTa401e0Ll6knYDktsDOR/6L8FWHrgk2BwJSfxh+vbzMc6qfJb1T Z2/XQrqMcBjW4VUvj4sAAAAAAAA= --------------ms050302090005000406040106-- From yogesh.swami@acm.org Wed Oct 13 00:28:00 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Tue Oct 12 23:28:00 2004 Subject: HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward In-Reply-To: References: <20040911232318.87825.qmail@web81205.mail.yahoo.com> <23ADD52E-057C-11D9-A8F6-000D9331AFB0@nomadiclab.com> <4145F262.8090805@acm.org> <414DF55F.7020802@acm.org> <6DEED73C-1924-11D9-BF2A-000D9331AFB0@nomadiclab.com> <4169F281.8000703@acm.org> Message-ID: <416CB0B0.6010500@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1BB8A63B49EB151A6E76C45D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > I think I misunderstood the notation here. g^ir (or g^xy) is the shared > Diffie-Hellman secret, not the concatenation of the Diffie-Hellman > parameters. Just forget my alternative above =) > > So, I guess we need to include the shared secret in the calculation of the > HMAC in I2 and R2? Still, I am a bit confused why this should be done. > Yogesh, would you care to explain this point in more depth? I am not a > crypto specialist... > Well, I am not a crypto expert either :-) The signature and HMAC are complementary. Signature prevents from MITM; HMAC ensures that the people who are verified to be alice and bob actually know the session key. I guess SIGMA paper is the best place for in depth analysis of all this. Yogesh --------------enig1BB8A63B49EB151A6E76C45D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWywtXkjMhOId4nzAQJ42QgApwC7ZHZUO15bHmpnTsYEhGNSRBVogBSE mAJmw03Iws9tQ7smvngbRSJTpSTeJoYQOxUFgNyvEoh3MLLtTbtSfcg7EPT+q57Y U0sUXX54DC5q+in/kK9zp2JIp8h+uxoZt3npKBVJgQRDvJy+WYih6u4wtFw4wihZ rPx1PHH2vQnFiUZPYHt9SRqzD7jv3EALbskTrUHmU4KkFqq1jjRNbOroMm25GVDM 8viui6oFi3iJUbXYJ5w5Dz+GANNsFMEb+mWusbHAEJuq12+jF05ru+OPUDKmzOCS w1dgZrFWSm0T8t8vj27b9Nr9UlAUyRdEiUcPLLnZVJKs0Hk/yw8Pww== =4k3T -----END PGP SIGNATURE----- --------------enig1BB8A63B49EB151A6E76C45D-- From thomas.r.henderson@boeing.com Wed Oct 13 00:48:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Oct 12 23:48:00 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> > > First, the > > authors feel that the way IKE uses UDP is=20 > architecturally wrong. > > A protocol controlling another protocol (like ICMP controlling > > IP) should be located either at the same layer with=20 > or the layer > > immediately above the controlled protocol, unless there are > > important reasons for doing otherwise. >=20 > I am not sure about this argument.=20 FWIW, I tend to agree. Do the authors feel the same way about BGP using = TCP? If control plane protocols can make use of existing transport protocols, = so much the better. Tom =20 From thomas.r.henderson@boeing.com Wed Oct 13 00:50:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Oct 12 23:50:00 2004 Subject: [Hipsec] review of comments on draft-ietf-hip-mm-00 preview Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452271B@xch-nw-27.nw.nos.boeing.com> Mika, I agree that we can generalize these figures, and=20 will adapt some of them along the lines that you suggested, or else point it out in the corresponding text. Tom > -----Original Message----- > From: Mika Kousa [mailto:mkousa@cc.hut.fi] > Sent: Monday, October 11, 2004 4:46 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] review of comments on=20 > draft-ietf-hip-mm-00 preview >=20 >=20 > 5.1 Mobility with single SA pair >=20 > Mobile Host Peer Host >=20 > UPDATE(REA, SEQ) > -----------------------------------> > UPDATE(SPI, SEQ, ACK, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> >=20 > Figure 3: Readdress without rekeying, but with address check >=20 >=20 >=20 > Now that we have seen the change needed for address check procedure=20 > (ECHO_REQUESTs are sent to each of the addresses listed in=20 > the REA, see=20 > this same thread), this section needs some editing. >=20 > Peer Host does not need to send ACK for the REA-UPDATE in=20 > every UPDATE it=20 > sends related to address check procedure, it could send just=20 > ACK-UPDATE=20 > and after that the Peer Host sends the ECHO_REQUEST-UPDATEs: >=20 > For example: >=20 >=20 > Mobile Host Peer Host >=20 > UPDATE(REA(addr_1,addr_2), SEQ) > -----------------------------------> > UPDATE(ACK) > <----------------------------------- >=20 > sent to addr_1: UPDATE(SPI, SEQ, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> >=20 > sent to addr_2: UPDATE(SPI, SEQ, ECHO_REQUEST) > <----------------------------------- > UPDATE(ACK, ECHO_RESPONSE) > -----------------------------------> > ... >=20 >=20 > Maybe the other figures and related texts in section 5 need similar=20 > changes when there is a possibility that REA contains many=20 > addresses, too. > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec >=20 From yogesh.swami@acm.org Wed Oct 13 01:06:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Wed Oct 13 00:06:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <416CB921.2060700@acm.org> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD470BD3312D66E2E992CA37 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ext Pekka Nikander wrote: > Tnx, Jari. > > Here is the revised text: > > While it would be possible, at least in theory, to use some > existing cryptographic protocol, such as IKEv2, together with > Host Identifiers to establish the needed SAs, HIP defines a new > protocol. There are a number of historical reasons for this, > and there are also a few architectural reasons. First, the > authors feel that the way IKE uses UDP is architecturally wrong. I think you also need to say something about connection-less-ness and connection-oriented-ness. The way HIP is right now, it makes layer 3.5 connection oriented, and honestly, I don't like it. (I remember you said ESP is connection oriented because of sequence number. But I checked rfc2401bis and it says sequence numbers are optional. ESP supports multicast, so it has to be connectionless.) Also, the draft needs to say how HIP architecture affect multicast. If HIP doesn't target multicast, then that should also be stated, IMO. Yogesh --------------enigCD470BD3312D66E2E992CA37 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) iQEVAwUBQWy5JXkjMhOId4nzAQIwaQf/VmkkpIE6SFcbT30Rt9CVUnphYWkdgOuR QAliHuoyNzSVd/biZdsLAUrpN4PrcArGd6DmH078BQICPpUK45FG30eRcQQ1y/3y +PBdX8/BFwEJD8G5NrvIRWbkiliWMpAWnsK3tLvR8mEBKwTKMlYvJrJs7wLYMCw2 k8ukN2403llcgcNiZYWxqCTbF72HO2Mu6HPgki6BpfIKmyeC5Y4fVtWNOwzIhB3o V/jaH0vHEZgZoUVAiHaNHkDomgRsmM6BDd1piHaAtmoPIna5HrtqGHuVE9wvRQ+o KZXmkhkSTsbEKv4NAhelqQd5Gfvha09HUCJW6Lkf5Udm4L8IoNdlVg== =MU32 -----END PGP SIGNATURE----- --------------enigCD470BD3312D66E2E992CA37-- From pekka.nikander@nomadiclab.com Wed Oct 13 01:54:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 13 00:54:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <200410121858.38644.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <416543F8.6040006@piuha.net> <200410121858.38644.julien.laganier@sun.com> Message-ID: <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> > So how does people feel about making both DSA and RSA mandatory in > HIP? I don't have any strong opinions. IIRC, the usual IETF crypto guidelines state that a) there must be at least one common MUST implement algorithm that is considered secure enough b) the algorithms must be negotiable so that if the currently MUST implement turns out to be insecure, the implementations can be easily upgraded to use some other, new MUST implement algorithm Anyone care to check what the guidelines and other documents actually say? draft-ietf-ipsec-ikev2-algorithms-05.txt draft-iab-auth-mech-03.txt crypto forum? From a robustness point of view, it would of course good to have multiple MUST implement algorithms. OTOH, I think that there should also be some guidelines how to use them so that the chances of interoperability are maintained even in the case that one of the hosts only supports one algorithm, e.g., due to policy reasons. Maybe we could have DSA as MUST and RSA as SHOULD? --Pekka From pekka.nikander@nomadiclab.com Wed Oct 13 04:03:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 13 03:03:00 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608A7@xch-nw-27.nw.nos.boeing.com> Message-ID: <81E5C2E2-1CEF-11D9-97E8-000D9331AFB0@nomadiclab.com> On Oct 13, 2004, at 7:55, Henderson, Thomas R wrote: >>> First, the >>> authors feel that the way IKE uses UDP is architecturally >>> wrong. >>> A protocol controlling another protocol (like ICMP controlling >>> IP) should be located either at the same layer with or the >>> layer >>> immediately above the controlled protocol, unless there are >>> important reasons for doing otherwise. >> >> I am not sure about this argument. > > FWIW, I tend to agree. Do the authors feel the same way about BGP > using TCP? Personally, I do. I haven't got any answer from Bob on this, yet. In the BGP case, there is this "important reason for doing otherwise", which is reusing TCP's reliability mechanism. FWIW, I think it would probably be better to run BGP over the top of SCTP; maybe some people are already thinking along those lines. > If control plane protocols can make use of existing transport > protocols, > so much the better. Actually, that makes a lot of things harder. You have to have special rules in firewalls and middle boxes, etc. As a result, building intelligent routers that separate fast path and slow path becomes slightly more involved. In this respect, the current HIP design is quite elegant, while e.g. IKE is not. But maybe I should tone down the argument and replace "architecturally wrong" with "architecturally inelegant"? --Pekka From pekka.nikander@nomadiclab.com Wed Oct 13 04:21:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 13 03:21:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <416C1106.6050609@isi.edu> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> Message-ID: > I am not a big fan of IKE (v1/v2), but just feel something > is still missing in the reasoning below. Well, as Bob has written before, there is a largish number of historical reasons. First, I don't even know them all. Second, even if I did, I am not sure if we should list them in the draft. As Bob wrote, he was told to remove any argumentation about HIP vs. IKE from the earlier versions of the architecture document. However, lately people have asked about this, and therefore IMHO it would be a good idea to say something. But I don't know what. One of my personal problems is that I've been doing this HIP thing now for a little bit too long. I start to be blind to many things. That is, I take some things for granted, while they are not that for people coming from outside. Hence, community feedback in getting this argument right is very important. I already answered to a part of this argument in a separate mail. Let me consider the rest here: > In a way, the HIP exchange is > analogous to DNS, you contact somebody to resolve an identity in > one domain into an identity in another domain. It just happens > in this case the 'somebody' is also the destination you want to > communicate with. This exchange should be considered a separate > communication, and is free to use whatever protocol or even out- > of-band information if available. Hmm... Interesting thought. Yes, HIP does involve a resolution or translation concept, and even more so in the case of Hi3. It is a nice idea that maybe we could disentangle the HIP protocol from the rest of HIP architecture. In a way, both BEET and CELP are steps into that direction (though in almost completely different levels.) Perhaps we need a kind of API that could be used both to control BEET IPsec based translation and CELP like translation? However, IIRC, we were not in that level last fall. As the intention is to publish the architecture document as reflecting our thoughts as they were a year ago, it may not be possible to include anything about this into the draft. > It is just a process of resolving identities, I am a bit unsure > about the phrase "A protocol controlling another protocol..." > Maybe I miss something here? Well, the HIP protocol is more than just identity translation. It is also about maintaining those translations in the face of mobility and multi-homing. Some people have thought about adding QoS signalling features to HIP. And so on. Besides, if we think about some other "control plane" or "signalling" protocols, such as SIP, their primary function seems to be creating connection (id to address translation, if you will), and then maintenance of the session. >> Third, from a conceptual point of view, the IPsec Security >> Parameter Index (SPI) in ESP provides a simple compression of >> the HITs. This does require per-HIT-pair SAs (and SPIs), and a >> decrease of policy granularity over other Key Management >> Protocols, such as IKE and IKEv2. ... > > This sounds like what we want is a subset of what IKEv1/v2 have. > This is an efficiency and optimization issue. I guess what I'd > like to see is a more compelling reasoning why we have to use > a different protocol. Otherwise another side of the argument > would be why not define HIP exchange as a profile of IKE to save > the trouble of inventing another protocol? (I'm sure you hear > about all that by now. Maybe even an ID in the work?) I think it would be a very useful exercise to try to write an IKEv2 profile that would allow HIP-like SA creation. You probably also need MOBIKE extensions. Indeed, if that would become good enough, it might be even good to trash the current HIP protocol almost completely and move to IKEv2. However, I'm almost sure that some important aspects of the current HIP design would probably be lost. It is then another question to decide whether such loss is important enough to retain a separate protocol or not. However, even if such an exercise would be quite useful, that should not slow down current progress with HIP. It is most important to get some deployment experience. Only that helps us with the next stages of design. --Pekka From pekka.nikander@nomadiclab.com Wed Oct 13 08:06:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 13 07:06:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <416CB921.2060700@acm.org> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416CB921.2060700@acm.org> Message-ID: <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> >> While it would be possible, at least in theory, to use some >> existing cryptographic protocol, such as IKEv2, together with >> Host Identifiers to establish the needed SAs, HIP defines a new >> protocol. There are a number of historical reasons for this, >> and there are also a few architectural reasons. First, the >> authors feel that the way IKE uses UDP is architecturally wrong. > > I think you also need to say something about connection-less-ness and > connection-oriented-ness. The way HIP is right now, it makes layer 3.5 > connection oriented, and honestly, I don't like it. (I remember you > said ESP is connection oriented because of sequence number. But I > checked rfc2401bis and it says sequence numbers are optional. ESP > supports multicast, so it has to be connectionless.) We didn't think in that way back last fall. It is hard to say anything about that in the draft, as that was not thought about. Going to the actual issue, host IP is not stateless. In addition to the ESP state, it has quite a lot of state, e.g. ND cache, routing entries, etc. When people speak about the stateless nature of IP, they typically mean that there is no per-connection state, especially in the network. Some IP implementations do maintain some state per active peer IP address, e.g. MTU, cached best route, etc. See e.g. BSD sources. That is soft state. In HIP case, there is still no per-connection state, there is just host-to-host (or end-point-to-end-point) state, and that is soft. It can be taken down and re-created independent on the upper layer state. The only real exception where I do see a difference is the HIT->IP mapping, which currently needs to be maintained at the HIP layer. But that kind of mapping you do need to maintain on any layer 3.5 solution. But apparently you mean something else by HIP being connection-oriented. Could you be more specific? > Also, the draft needs to say how HIP architecture affect multicast. If > HIP doesn't target multicast, then that should also be stated, IMO. I'm adding a statement that back in 2003 nobody, AFAIK, had thought about HIP and multicast. --Pekka From yogesh.swami@acm.org Wed Oct 13 09:57:01 2004 From: yogesh.swami@acm.org (Yogesh Prem Swami) Date: Wed Oct 13 08:57:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416CB921.2060700@acm.org> <6018C5F4-1D11-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <416D35C7.1030801@acm.org> > >> Also, the draft needs to say how HIP architecture affect multicast. >> If HIP doesn't target multicast, then that should also be stated, IMO. > > > I'm adding a statement that back in 2003 nobody, AFAIK, had thought > about HIP and multicast. This should be good enough. Yogesh From Julien.Laganier@Sun.COM Wed Oct 13 10:14:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Oct 13 09:14:00 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: <212DBB48-1BAF-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <200410051944.56646.julien.laganier@sun.com> <200410111912.37238.julien.laganier@sun.com> <212DBB48-1BAF-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <200410131623.48807.julien.laganier@sun.com> Folks, In a private conversation (excerpt included at the end of the mail), Pekka and I talked about making HITs stored in the DNS type-opaque (the HIT doesn't contains bits telling its type), i.e.: Type1_HIT = SHA1_128(HI) Type2_HIT = HAA_64 + SHA1_64(HI) While the HIP base spec currently specifies that HITs used in the base protocol are of the form: Type1_HIT = 01 + SHA1_126(HI) Type2_HIT = 10 + HAA_62 + SHA1_64(HI) So at this point, I'd like to know what the WG consensus is w.r.t. the following questions: o Should we store 128 and 64+64 bits HITs in the DNS? o Should we use 128 and 64+64 bits HITs in the HIP header? o Should we derive and use 127 and 63+64 bits HITs in the legacy IPv6-compatible API for IPv6 apps? (This would be similar to the HIP-internal NATing that some people evocate about LSIs, or IP addresses as AIDs) o Should we think now to use longer HITs (e.g. using SHA256) in the protocol and the DNS? Thanks, --julien Pekka Nikander wrote: > >Julien Laganier wrote: > > > >Pekka Nikander wrote: > >> If we remove the HIT vs IPv6 LSI discussion from earlier on, > >> we have to change 5.1.3. My suggestion is that we store the > >> full 128 bit hash into the Type 1 HIT field, and define the > >> Type 2 and HAA fields to have 64 bits of HAA, where the HAA > >> includes the prefix (if any). > > > > If I understand correctly, that means that HITs would be > > type-opaque, right? Is this not a problem if one wants to perform > > HIT-based access control? Also, how does a node verify its peer's > > HIT with the current protocol (the exchange doesn't include the > > peers' HIT type) ? > > Remember that we are defining only DNS use, not how HITs are used, > e.g., in the base spec. We can use 128-bit hashes in the DNS, > as the RR explicitly lists the HIT type, and then use only 126-bit > hashes in the base exchange. Maybe add: > > Note that the format how HITs are stored in the DNS may be > different form the format actually used in protocols, the > HIP base exchange included. This is because the DNS > RR explicitly contains the HIT type, while some protocols > may prefer to use a prefix to indicate the HIT type. The > implementations are expected to use the actual HI when > comparing Host Identities. > > >> But this seems to be something that we probably have to discuss > >> at the WG. > > > > Should I send an email to the ML? > > Yes. I think the suggestion is that > > - use 128 or 64+64 bit HITs in the DNS > - continue using 2+126 and 2+62+64 bit HITs in the > base specification, for now > - be open to even longer HITs, e.g. 256-bit long -- Julien Laganier SUN Microsystems Laboratories From shep@alum.mit.edu Wed Oct 13 10:44:01 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Wed Oct 13 09:44:01 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: Your message of Wed, 13 Oct 2004 16:23:48 +0200. <200410131623.48807.julien.laganier@sun.com> Message-ID: > o Should we think now to use longer HITs (e.g. using SHA256) in the > protocol and the DNS? > I don't know if we want to change the base spec at this particular point in time, but I believe a deployable HIP will need to support longer HITs. There was also an understanding (in hallway conversations at IETF meetings) that the LSI's passed accross IPv6 APIs would be a few to a dozen bits shorter than 128 bits (with a constant prefix prepended to fill 128 bits), so as not to consume too much of the IPv6 address space with this hack to allow references to HITs to be passed where APIs already support IPv6 addresses. The kernel could maintain a table maping these LSIs to the acutal HITs, whatever there lenght may be, and would presumably use the bottom 120 or so bits of the HIT as the bottom bits of the LSI. (Collisions would be unlikely.) At least that's my memory of this issue. -Tim Shepard shep@alum.mit.edu From thomas.r.henderson@boeing.com Wed Oct 13 10:44:06 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 13 09:44:06 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608A9@xch-nw-27.nw.nos.boeing.com> >=20 > > If control plane protocols can make use of existing transport=20 > > protocols, > > so much the better. >=20 > Actually, that makes a lot of things harder. You have to have special > rules in firewalls and middle boxes, etc. As a result, building > intelligent routers that separate fast path and slow path becomes > slightly more involved. >=20 > In this respect, the current HIP design is quite elegant, while e.g. > IKE is not. >=20 > But maybe I should tone down the argument and replace "architecturally > wrong" with "architecturally inelegant"? >=20 I agree with your argument about middleboxes-- that HIP admits new=20 architectural solutions that are middlebox-oriented. But that was made in a separate point in your proposed text. I think that it would suffice to say that IKE's use of UDP makes it architecturally more difficult to incorporate middleboxes. Tom=20 From Julien.Laganier@Sun.COM Wed Oct 13 11:33:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Oct 13 10:33:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> Message-ID: <200410131742.54278.julien.laganier@sun.com> On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: > > So how does people feel about making both DSA and RSA mandatory > > in HIP? > > I don't have any strong opinions. IIRC, the usual IETF crypto > guidelines state that > > a) there must be at least one common MUST implement > algorithm that is considered secure enough > > b) the algorithms must be negotiable so that if the > currently MUST implement turns out to be insecure, > the implementations can be easily upgraded to use > some other, new MUST implement algorithm > > Anyone care to check what the guidelines and other > documents actually say? > > draft-ietf-ipsec-ikev2-algorithms-05.txt This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA=20 and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt.=20 However, an interesting thing is the new requirements keywords defined=20 in draft-ietf-ipsec-ikev2-algorithms-05.txt: SHOULD+ This term means the same as SHOULD. However it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This terms means the same as SHOULD. However an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time,it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD-. >=A0 =A0draft-iab-auth-mech-03.txt It said: =2D------------------- While the desire to support legacy authentication systems is under- standable, it should be resisted to the extent possible. Having mul- tiple equivalent mechanisms dramatically increases both implementa- tion complexity and interoperability problems. When designing a new system, designers should choose a very small number of authentication mechanisms, with no more than one of any given class. =2D------------------- And later =2D------------------- 13.2. Use As Few Mechanisms as You Can Preferably, systems should have only one form of authentication. The more methods of authentication a system allows, the more things there are to go wrong. Remember that a chain is only as strong as its weak- est link. In general, there are two reasons why systems allow more than one authentication mechanism. The first is that you're retrofitting a system which already has a large number of authentica- tion mechanisms which cannot be displaced. The second is that users have widely different environments which for some reason cannot use the same authentication mechanism conveniently (e.g. some users have tokens and some do not). Naturally, designers need to take such considerations into account but they should take reasonable steps to minimize the number of mech- anisms. Designers should take special care to minimize the number of equivalent mechanisms. For instance, a system that provides a chal- lenge/response mechanism and a public key based mechanism is a rea- sonable design, one that provides three different challenge/response mechanisms is not. This doesn't mean that designers should not use security frameworks where multiple mechanisms are appropriate, but it does mean that they should be avoided unless necessary. Where generic security frameworks are used, they supported mechanisms should be carefully profiled to a minimal set. =2D------------------- >=A0 =A0crypto forum? I can ask them. > From a robustness point of view, it would of course good to > have multiple MUST implement algorithms. OTOH, I think > that there should also be some guidelines how to use them > so that the chances of interoperability are maintained > even in the case that one of the hosts only supports one > algorithm, e.g., due to policy reasons. > > Maybe we could have DSA as MUST and RSA as SHOULD? > > --Pekka I'm a bit confused by what I've read on the subject: IKEv2 has DSA as=20 MUST and RSA as MUST, but draft-iab-auth-mech says that it should be=20 avoided unless necessary. If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI=20 algorithm capabilities (between RSA and DSA), so I tend to think that=20 we should have both as MUST. Is there any other opinions the subject? Thanks, =2D-julien From Julien.Laganier@Sun.COM Wed Oct 13 11:45:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Wed Oct 13 10:45:01 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: References: Message-ID: <200410131754.31591.julien.laganier@sun.com> On Wednesday 13 October 2004 16:52, Tim Shepard wrote: > > o Should we think now to use longer HITs (e.g. using SHA256) in > > the protocol and the DNS? > > I don't know if we want to change the base spec at this particular > point in time, but I believe a deployable HIP will need to support > longer HITs. I agree that changing the base spec at this point might be problematic (especially because HITs are in the base header which is supposed to have a fixed length). I think, however, that we can easily introduce variable length data structure to store HIT in the DNS, which might be useful in the future. Thanks, --julien From jari.arkko@piuha.net Wed Oct 13 12:16:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed Oct 13 11:16:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <200410131742.54278.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> Message-ID: <416D566A.4070909@piuha.net> I'd be fine with just one algorithm (for now). And my slight preference for that algorithm is RSA... --Jari Julien Laganier wrote: > On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: > >>>So how does people feel about making both DSA and RSA mandatory >>>in HIP? >> >>I don't have any strong opinions. IIRC, the usual IETF crypto >>guidelines state that >> >> a) there must be at least one common MUST implement >> algorithm that is considered secure enough >> >> b) the algorithms must be negotiable so that if the >> currently MUST implement turns out to be insecure, >> the implementations can be easily upgraded to use >> some other, new MUST implement algorithm >> >>Anyone care to check what the guidelines and other >>documents actually say? >> >> draft-ietf-ipsec-ikev2-algorithms-05.txt > > > This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA > and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt. > > However, an interesting thing is the new requirements keywords defined > in draft-ietf-ipsec-ikev2-algorithms-05.txt: > > SHOULD+ This term means the same as SHOULD. However it is > likely that an algorithm marked as SHOULD+ will be > promoted at some future time to be a MUST. > SHOULD- This terms means the same as SHOULD. However an > algorithm marked as SHOULD- may be deprecated to a > MAY in a future version of this document. > MUST- This term means the same as MUST. However we > expect at some point that this algorithm will no > longer be a MUST in a future document. Although > its status will be determined at a later time,it > is reasonable to expect that if a future revision > of a document alters the status of a MUST- > algorithm, it will remain at least a SHOULD or a > SHOULD-. > > >> draft-iab-auth-mech-03.txt > > > It said: > > -------------------- > While the desire to support legacy authentication systems is under- > standable, it should be resisted to the extent possible. Having mul- > tiple equivalent mechanisms dramatically increases both implementa- > tion complexity and interoperability problems. When designing a new > system, designers should choose a very small number of authentication > mechanisms, with no more than one of any given class. > -------------------- > > And later > > -------------------- > 13.2. Use As Few Mechanisms as You Can > > Preferably, systems should have only one form of authentication. The > more methods of authentication a system allows, the more things there > are to go wrong. Remember that a chain is only as strong as its weak- > est link. In general, there are two reasons why systems allow more > than one authentication mechanism. The first is that you're > retrofitting a system which already has a large number of authentica- > tion mechanisms which cannot be displaced. The second is that users > have widely different environments which for some reason cannot use > the same authentication mechanism conveniently (e.g. some users have > tokens and some do not). > > Naturally, designers need to take such considerations into account > but they should take reasonable steps to minimize the number of mech- > anisms. Designers should take special care to minimize the number of > equivalent mechanisms. For instance, a system that provides a chal- > lenge/response mechanism and a public key based mechanism is a rea- > sonable design, one that provides three different challenge/response > mechanisms is not. > > This doesn't mean that designers should not use security frameworks > where multiple mechanisms are appropriate, but it does mean that they > should be avoided unless necessary. Where generic security frameworks > are used, they supported mechanisms should be carefully profiled to a > minimal set. > -------------------- > > >> crypto forum? > > > I can ask them. > > >> From a robustness point of view, it would of course good to >>have multiple MUST implement algorithms. OTOH, I think >>that there should also be some guidelines how to use them >>so that the chances of interoperability are maintained >>even in the case that one of the hosts only supports one >>algorithm, e.g., due to policy reasons. >> >>Maybe we could have DSA as MUST and RSA as SHOULD? >> >>--Pekka > > > I'm a bit confused by what I've read on the subject: IKEv2 has DSA as > MUST and RSA as MUST, but draft-iab-auth-mech says that it should be > avoided unless necessary. > > If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI > algorithm capabilities (between RSA and DSA), so I tend to think that > we should have both as MUST. > > Is there any other opinions the subject? > > Thanks, > > --julien > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From yushunwa@ISI.EDU Wed Oct 13 13:12:00 2004 From: yushunwa@ISI.EDU (Yu-Shun Wang) Date: Wed Oct 13 12:12:00 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> Message-ID: <416D63A6.6090904@isi.edu> This is a cryptographically signed message in MIME format. --------------ms080800080009040505040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> I am not a big fan of IKE (v1/v2), but just feel something >> is still missing in the reasoning below. > As Bob wrote, he was told to remove any argumentation about HIP vs. > IKE from the earlier versions of the architecture document. However, > lately people have asked about this, and therefore IMHO it would be > a good idea to say something. But I don't know what. Understood. I suspect not all reasons back then were technical. >> In a way, the HIP exchange is >> analogous to DNS, you contact somebody to resolve an identity in >> one domain into an identity in another domain. It just happens >> in this case the 'somebody' is also the destination you want to >> communicate with. This exchange should be considered a separate >> communication, and is free to use whatever protocol or even out- >> of-band information if available. > Hmm... Interesting thought. Yes, HIP does involve a resolution > or translation concept, and even more so in the case of Hi3. Yes, I know most people don't think of IKE-style of exchanging keys as a form of resolution, but in the aspect of HIP, the result of exchange is then used as a form of IDs. That's why. > It is a nice idea that maybe we could disentangle the HIP protocol > from the rest of HIP architecture. In a way, both BEET and CELP > are steps into that direction (though in almost completely different > levels.) Perhaps we need a kind of API that could be used both > to control BEET IPsec based translation and CELP like translation? Another part is to re-use existing protocols if it's good enough to support what we want. > However, IIRC, we were not in that level last fall. As the intention > is to publish the architecture document as reflecting our thoughts > as they were a year ago, it may not be possible to include anything > about this into the draft. Fair enough. I wasn't aware of this context. >> It is just a process of resolving identities, I am a bit unsure >> about the phrase "A protocol controlling another protocol..." >> Maybe I miss something here? > Well, the HIP protocol is more than just identity translation. It is > also about maintaining those translations in the face of mobility and > multi-homing. Some people have thought about adding QoS signalling > features to HIP. And so on. > > Besides, if we think about some other "control plane" or "signalling" > protocols, such as SIP, their primary function seems to be creating > connection (id to address translation, if you will), and then > maintenance of the session. Actually, I was expecting something closer to what you said above as the argument of why IKE isn't enough. (But then you also mentioned MOBIKE below which sort of fill this gap...:-) Anyways, this type of reasoning is imho stronger than the architectural point of view at the beginning. >>> Third, from a conceptual point of view, the IPsec Security >>> Parameter Index (SPI) in ESP provides a simple compression of >>> the HITs. This does require per-HIT-pair SAs (and SPIs), and a >>> decrease of policy granularity over other Key Management >>> Protocols, such as IKE and IKEv2. ... >> This sounds like what we want is a subset of what IKEv1/v2 have. >> This is an efficiency and optimization issue. I guess what I'd >> like to see is a more compelling reasoning why we have to use >> a different protocol. Otherwise another side of the argument >> would be why not define HIP exchange as a profile of IKE to save >> the trouble of inventing another protocol? (I'm sure you hear >> about all that by now. Maybe even an ID in the work?) > I think it would be a very useful exercise to try to write an > IKEv2 profile that would allow HIP-like SA creation. You probably > also need MOBIKE extensions. Indeed, if that would become good > enough, it might be even good to trash the current HIP protocol > almost completely and move to IKEv2. However, I'm almost sure > that some important aspects of the current HIP design would probably > be lost. It is then another question to decide whether such loss > is important enough to retain a separate protocol or not. Yes, I don't know HIP well enough to enumerate what could be lost if we use IKE. But the comparison and what's lost if IKEv2 is used are what most of us would really like to see. Though it doesn't have to be in this document as it would surely delay the process. > However, even if such an exercise would be quite useful, that > should not slow down current progress with HIP. It is most > important to get some deployment experience. Only that helps > us with the next stages of design. Good enough for me. As a practical suggestion, I think your original first reason (the arch point of view) should probably be removed. Then we just need a simple, high level list of what could be lost or hard to do if using IKEv2 in place of HIP exchange with the statement that we are not closing the door on future development of HIP exchange as an IKE profile. Though this seems like a reverse of what brought on this whole discussion, the original text IMO does not really serve the purpose of explaining "why not IKE(v2)". Thanks, yushun -- Yu-Shun Wang USC Information Sciences Institute --------------ms080800080009040505040401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MTAxMzE3MTkzNFowIwYJKoZIhvcNAQkEMRYEFBuKxiwOfhjM+Wx+U7FxS8QE v2OtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBAGb8P5xgBTh6KhgTpUg+jmQ88TZOn100lRNs 3KWzSfsZcsjgXP0xZFxBeYdXntxSRFD/i76mtL/ZQnx1s/iY2P827tZtxIRvXNTJOkOeom6K LYMoaJtsIJbNHXEMPk2TjnVNbXC/xL4P0V2/0RzG+MtEhFeYq+N/QRHboNHSqP3yqgtCPkRX LyRAk+69gdkQCunrAae1rihOM9Vmezyd4YOpopI9kp1u/wx6ofaD7eCi5JEO58BjBgFQHh0l M4qhLwEqzKDoPxUtbuqS/NBIaoglyjdpsO0+/8JpDjuqEYWGLRlTpGqdzfrqsUdmlb8JFLEO ZzFv4cQF0kIVp6qBKSUAAAAAAAA= --------------ms080800080009040505040401-- From pekka.nikander@nomadiclab.com Thu Oct 14 01:59:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 14 00:59:00 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <416D63A6.6090904@isi.edu> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> <416D63A6.6090904@isi.edu> Message-ID: <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> > Actually, I was expecting something closer to what you said > above as the argument of why IKE isn't enough. (But then you > also mentioned MOBIKE below which sort of fill this gap...:-) > Anyways, this type of reasoning is imho stronger than the > architectural point of view at the beginning. Well, AFAIK, the real reasons for a separate protocol were mostly political (attitude at IPsec WG, among other things) and architectural. Back when Bob began, technically it would have been fairly easy to develop IKE into a direction where it would have also served HIP purposes. Unfortunately, few people understood the HIP idea, and quite a few people opposed it, some bitterly. Hence, making IKE HIP-friendly would never have worked out politically. Hence, if we now list technical arguments why we need a separate protocol, that is more an afterthought than the original, architectural baseline. The architectural stance towards middle boxes is one big difference, the other one being policy granularity. Both are _architectural_ in nature. The third issue, a separate protocol instead of running on the top of UDP, is also architectural in nature, but much harder to argue about. Here people seem to have widely different opinions. My firm belief is that we've made the right choice. As an indication of this is that we don't need separate IPsec policy rules to except some UDP ports from others. That may seem as a minor issue, but getting the architecture right often manifests itself initially in very subtle ways, and the big picture becomes fully visible only later on. Other people believe that the choice is detrimental since it makes it harder to work with current NATs. As I have repeatedly stated, from a practical point of view I agree with the UDP proponents, but I can't agree from an architectural point of view. Maybe I am stubborn, dull, and stupid. Or maybe I'm just dense and got my intuition right. Anyway, I think it is useless to argue too much about this point now. We'll have much better perspective once we have some initial deployment experience. > Yes, I don't know HIP well enough to enumerate what could be > lost if we use IKE. But the comparison and what's lost if IKEv2 > is used are what most of us would really like to see. Please go ahead. There may be other people that are interested. At this point, the results belong to the HIP RG. However, I presume that they would be very useful at the next HIP WG re-chartering time. > ... As a practical suggestion, I think your original > first reason (the arch point of view) should probably be removed. I understand. It looks like that people agree with - the middle box friendliness argument (enable layer 3.5 routing) - the policy granularity argument (layer 3.5 is end-point- to-end-point, as connection multiplexing happens only on layer 4) I can certainly remove the separate protocol argument. However, if we are able to find a wording that the WG deems easy enough to understand, I'd like to preserve something of it. What I want to say, basically, is that most "signalling" protocols either - use in-line signalling (TCP, SCTP, SSH, ...) - are directly on the top of controlled protocol (ICMP, portmapper, SIP, PPP control protocols, ...) - and this seems to be right. There are a few notable exceptions, BGP and IKE being the prime examples. They both may get it "right", given their requirements, but I doubt the IKE case. In the BGP case, my (perhaps flawed) understanding is that they wanted to use the reliability mechanisms from TCP. I don't remember what (if any) the arguments were in the IKE case. I'm sure there are other exceptions, but I can't remember them now. Now, the real question is why would it be better to place the signalling protocols either in-line or directly on the top? Here I am more on my own wits than on anything that I've heard or read, hence be careful. But let's go. 1. If there is a protocol X between the protocol P and its control protocol S, the protocol X may have its own control functions that make the system complex and unstable. [In the IKE case, UDP has little control at all. In the BGP case, TCP control is in-line. Hence, this problem doesn't manifest itself there.] 2. If the protocol P somehow controls the functions of the protocol X on the top of it, the system becomes complicated. This is the case for IKE. This complication manifests itself in the exception policy rules; see above. [This would not be a big deal if we considered HIP alone. However, some people (me included) would want to be able to run HIP in parallel with IKE, and there this is an issue.] 3. When designing fast middle boxes, it often becomes important to separate the data plane and control plane from each other. One wants to process data plane packets using the fast path, e.g., a few tens or hundreds of micro code instructions per packet, while the control protocol goes to slow path. [This requires more complex micro code for IKE, since you have to check UDP ports, while in HIP case you don't.] There are probably other technical issues embedded in this, but they evade my mind now. Now, the question is how to put this all in a succinct way to the architecture document. I don't want to go in this detail there, as the document is also otherwise quite content laden, and expanding all the details wouldn't serve the purpose. I'd be grateful if someone could propose some text. I'll try to do it myself tomorrow, but help is appreciated. --Pekka From pekka.nikander@nomadiclab.com Thu Oct 14 06:06:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 14 05:06:01 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: References: Message-ID: >> o Should we think now to use longer HITs (e.g. using SHA256) in the >> protocol and the DNS? > > I don't know if we want to change the base spec at this particular > point in time, but I believe a deployable HIP will need to support > longer HITs. I concur. > There was also an understanding (in hallway conversations at IETF > meetings) that the LSI's passed accross IPv6 APIs would be a few to a > dozen bits shorter than 128 bits (with a constant prefix prepended to > fill 128 bits), so as not to consume too much of the IPv6 address > space with this hack to allow references to HITs to be passed where > APIs already support IPv6 addresses. The kernel could maintain a > table maping these LSIs to the acutal HITs, whatever there lenght may > be, and would presumably use the bottom 120 or so bits of the HIT as > the bottom bits of the LSI. (Collisions would be unlikely.) > > At least that's my memory of this issue. Your memory matches closely with mine. IIRC, we also felt that for practical purposes, we could continue with the HIT prefixes for then, and review the issue when we get close to publication. Maybe we are now closer to publication. If the WG feels so, I would suggest the following changes to the base and DNS specs: 1. Change the common header to include HIT types in Control: The following fields have been defined: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHT | DHT | | | | | | | | |C|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SHT Sender's HIT Type. Currently the following values are specified: 0 RESERVED 1 Type 1 HIT 2 Type 2 HIT 3-6 UNASSIGNED 7 RESERVED DHT Destionation's HIT type. 2. Change the DNS draft so that HAA has the HIT type of 7: 5.1.1 RDATA format HIT type .... 2 A 128-bit Type 2 HIT is present. 7 A 128-bit HAA is present. The idea is that there is only one IANA registry for the values 1-6, and values 0 and 7 are reserved in the IANA registry. 3. Change the text so that Type 1 HITs don't have any prefix at all, Type 2 HITs have a prefix TBD of length TBD. (To be assigned by IANA) > There are two types of HITs. HITs of the first type, called *type 1 > HIT*, consist of an initial 2 bit prefix of 01, followed by 126 bits consist of 128 bits > of the SHA-1 hash of the public key. HITs of the second type > consist > of an initial 2 bit prefix of 10, a Host Assigning Authority (HAA) TBD-bit prefix of TBD, > field, and only the last 64 bits come from a SHA-1 hash of the Host > Identity. This latter format for HIT is recommended for 'well known' > systems. It is possible to support a resolution mechanism for these > names in hierarchical directories, like the DNS. Another use of HAA > is in policy controls, see Section 12. Add: As the type of a HIT cannot be determined by inspecting its contents, the HIT type must be communicated by some external means. Historically, some early implementations had a 2-bit prefix of 01 for Type 1 HITs. It is expected to be a common practice to use that or a similar but longer prefix at the legacy IPv6 API; see Appendix A. Consequently, it is RECOMMENDED that implementations ignore the left most TBD bits when comparing HITs for equality. 4. Add some text about IPv6 LSIs to Appendix A (I think the -00 version of the DNS draft has text that might fit in there, at least if slightly edited.) Opinions? --Pekka From Julien.Laganier@Sun.COM Thu Oct 14 09:22:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Thu Oct 14 08:22:01 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: References: Message-ID: <200410141531.37251.julien.laganier@sun.com> Hi Pekka, I basically agree with the changes you are proposing. I modified the IPv6 LSI text of the -00 of the DNS draft, included below, On Thursday 14 October 2004 12:13, Pekka Nikander wrote: > If the WG feels so, I would suggest the following changes to the > base and DNS specs: > > 1. Change the common header to include HIT types in Control: > > The following fields have been defined: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SHT | DHT | | | | | | | | |C|A| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > SHT Sender's HIT Type. Currently the following values are > specified: > > 0 RESERVED > 1 Type 1 HIT > 2 Type 2 HIT > 3-6 UNASSIGNED > 7 RESERVED > > DHT Destionation's HIT type. > > 2. Change the DNS draft so that HAA has the HIT type of 7: > > 5.1.1 RDATA format HIT type > > .... > > 2 A 128-bit Type 2 HIT is present. > 7 A 128-bit HAA is present. > > The idea is that there is only one IANA registry for the values > 1-6, and values 0 and 7 are reserved in the IANA registry. > > 3. Change the text so that Type 1 HITs don't have any prefix at > all, Type 2 HITs have a prefix TBD of length TBD. (To be assigned > by IANA) > > > There are two types of HITs. HITs of the first type, called > > *type 1 HIT*, consist of an initial 2 bit prefix of 01, followed > > by 126 bits > > consist of 128 bits > > > of the SHA-1 hash of the public key. HITs of the second type > > consist > > of an initial 2 bit prefix of 10, a Host Assigning Authority > > (HAA) > > TBD-bit prefix of TBD, > > > field, and only the last 64 bits come from a SHA-1 hash of the > > Host Identity. This latter format for HIT is recommended for > > 'well known' systems. It is possible to support a resolution > > mechanism for these names in hierarchical directories, like the > > DNS. Another use of HAA is in policy controls, see Section 12. > > Add: > > As the type of a HIT cannot be determined by inspecting its > contents, > the HIT type must be communicated by some external means. > > Historically, some early implementations had a 2-bit prefix of > 01 for Type 1 HITs. It is expected to be a common practice to use > that or a similar but longer prefix at the legacy IPv6 API; see > Appendix A. Consequently, it is RECOMMENDED that implementations > ignore the left most TBD bits when comparing HITs for equality. > > 4. Add some text about IPv6 LSIs to Appendix A > > (I think the -00 version of the DNS draft has text that might > fit in there, at least if slightly edited.) => Here's a modified excerpt matching the modifications you proposed: The first bit of a HIT is used to differentiate between Type 1 and Type 2 format. If the first bit is 0 then the rest of a HIT is the 127 upper bits of a SHA-1 hash of the Host Identity. If the first bit is 1 then the next 63 bits is the HAA field, and only the last 64 bits come from the hash of the Host Identity. Additionnaly, this document defines an internal IPv6-compatible LSI representation format, to be used within the legacy IPv6-compatible API (e.g., socket over AF_INET6). The format of these IPv6-compatible LSIs is designed to avoid the most commonly occurring IPv6 addresses in RFC3596 [9]. An IPv6-compatible LSI representation is easily computed by replacing the first TBDth bits of the corresponding HIT by the TBD bits long prefix "0xTBD". Allocation Prefix Fraction of IPv6 (binary) Address Space ------------------------ -------- ------------- IPv6 Address space 00 1/4 IPv6-compatible LSI TBD 1/2^TBD IPv6 Address space 11 1/4 => Question: Do we need to include the type of the HIT in one of the IPv6 LSI bits? If so, replace the last sentence and the table of the text above by: An IPv6-compatible LSI representation is easily computed by replacing the first TBDth bits of the corresponding HIT by the TBD-2 bits long prefix "0xTBD", while TBD-1th and TBDth bits are set to 01 for a Type 1 HIT, and 10 for a Type2 HIT Allocation Prefix Fraction of IPv6 (binary) Address Space ------------------------ -------- ------------- IPv6 Address space 00 1/4 Type 1 IPv6-compatible LSI TBD:01 1/2^(TBD+2) Type 2 IPv6-compatible LSI TBD:10 1/2^(TBD+2) IPv6 Address space 11 1/4 > Opinions? IMHO the following changes are worth. If the WG agrees, I'll also modify the DNS draft accordingly. Thanks, > --Pekka --julien From shep@alum.mit.edu Thu Oct 14 10:25:00 2004 From: shep@alum.mit.edu (Tim Shepard) Date: Thu Oct 14 09:25:00 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: Your message of Thu, 14 Oct 2004 15:31:37 +0200. <200410141531.37251.julien.laganier@sun.com> Message-ID: > (binary) Address Space > ------------------------ -------- ------------- > > IPv6 Address space 00 1/4 > Type 1 IPv6-compatible LSI TBD:01 1/2^(TBD+2) > Type 2 IPv6-compatible LSI TBD:10 1/2^(TBD+2) > IPv6 Address space 11 1/4 > I would guess that if we get a prefix in the IPv6 address space allocated for this purpose, it would start with 00 or 11. In particular, looking at http://www.iana.org/assignments/ipv6-address-space and thinking about what's already been allocated, it would seem to make the best sense would be something inside of (binary) 0000 0000. So I guess what I'm saying is that does not make sense to include the first and last lines in that table. -Tim Shepard shep@alum.mit.edu From Julien.Laganier@Sun.COM Fri Oct 15 07:58:01 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 15 06:58:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <200410131742.54278.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> Message-ID: <200410151408.04279.julien.laganier@sun.com> Folks, About the DSA vs RSA issue, here's an excerpt of a CFRG email mentionning an opinion about what algorithm should be used in existing, and new protocol/applications. --julien ---------- Forwarded Message ---------- Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory Date: Thursday 26 August 2004 19:32 From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , "Hughes, James P" Cc: "'saag@mit.edu'" , "'cfrg@ietf.org'" , "'kent@bbn.com'" I think that we should track status of crypto algs independently of their standards status. In particular I think that we should distinguish between Recommended and Acceptable status. New applications should specify algorithms with Recommended status Continued use of algorithms with Acceptable status should not raise concern. So I would classify as follows: Proposed: SHA-2 Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024 Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4 Depricated: IDEA, RSA1024+MD5 Obsolete: MD4, MD5, RSA-512, DES The reason that I distinguish between Depricated and obsolete is that there are uses of RSA signatures with MD5 hash that are still acceptably secure and the applications concerned do not support SHA1. The reason I put DSA as acceptable rather than recommended is that it does need a good random seed, the key size is small and it is unlikely at this point to see much use. RC4 has been compromised by Shamir & co, but as a general rule I don't think any stream cipher should ever get a higher status than acceptable. A stream cipher always allows a person who has a plaintext and ciphertext corresponding to a key to encode or decode all messages with that key that are shorter or the same size. In effect all stream ciphers are vulnerable to a trivial form of known plaintext attack, the attack does not reveal the key but this is not necessary. I do not feel confident in recommending moving to SHA2 at this point. Before jumping I want to see that the place we are going to is better than where we left. SHA2 is not currently widely used. If it turns out that the recent cryptanalysis of SHA1 is also applicable to the structures used in SHA2 then the rationale for a change is lost. I would feel happier moving to a hash function based on AES encryption (which i had eroneously assumed had been the point of the SHA2 work). From pekka.nikander@nomadiclab.com Sat Oct 16 01:34:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Sat Oct 16 00:34:01 2004 Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2) In-Reply-To: <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> References: <697D88EA-1C23-11D9-97E8-000D9331AFB0@nomadiclab.com> <416BA1F7.50608@piuha.net> <6B3309DC-1C31-11D9-97E8-000D9331AFB0@nomadiclab.com> <416C1106.6050609@isi.edu> <416D63A6.6090904@isi.edu> <65EA04A0-1DA7-11D9-B20B-000D9331AFB0@nomadiclab.com> Message-ID: <3ABC363C-1F36-11D9-861F-000D9331AFB0@nomadiclab.com> > It looks like that people agree with > > - the middle box friendliness argument (enable layer 3.5 > routing) > - the policy granularity argument (layer 3.5 is end-point- > to-end-point, as connection multiplexing happens only on > layer 4) > > I can certainly remove the separate protocol argument. However, > if we are able to find a wording that the WG deems easy enough > to understand, I'd like to preserve something of it. I decided to remove the argument about any architectural needs for a separate protocol. After contemplating it a little bit, I came to the conclusion that a) the argument is not very well baked, at least not yet b) historically, it was not really so in the beginning of the HIP process As a result, the proposed text now looks like the following: While it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2 together with Host Identifiers, to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few architectural reasons. First, IKE (and IKEv2) were not design with middle boxes in mind. As adding a new naming layer allows one to potentially add a new forwarding layer (see , below), it is very important that the HIP protocols are friendly towards any middle boxes. Second, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy granularity over other Key Management Protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, HIP only supports host-to-host (or endpoint-to-endpoint) Security Associations. If two hosts need more pairs of parallel SAs, they should use separate HITs for that. However, future HIP extensions may provide for more granularity and creation of several ESP SAs between a pair of HITs. I'm now posting the draft to the repositories. If anyone feels so, we can return to this issue during the forthcoming WC LC. --Pekka From pekka.nikander@ericsson.com Sat Oct 16 02:02:00 2004 From: pekka.nikander@ericsson.com (Pekka Nikander) Date: Sat Oct 16 01:02:00 2004 Subject: [Hipsec] draft-ietf-hip-arch-00.txt posted Message-ID: <312A5693-1F3A-11D9-861F-000D9331AFB0@ericsson.com> I have posted draft-ietf-hip-arch-00.txt. Due to the large number of -00 drafts posted at this time, it may take a few days before it appears in the repositories. In the meanwhile, the draft is available at http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00.html http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00.txt There are also diffs available against draft-moskowitz-hip-arch-06.txt: http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-chbar.txt http://www.tml.hut.fi/~pnr/HIP/draft-ietf-hip-arch-00-diff.html As you can see from the diff, there are a number of mostly editorial changes in the introduction, and two more substantial changes - a new section saying that Multicast was not considered back then - new text in the IPsec section trying to clarify the relationship to IKEv2 --Pekka Nikander From Gonzalo.Camarillo@ericsson.com Sat Oct 16 03:41:01 2004 From: Gonzalo.Camarillo@ericsson.com (Gonzalo Camarillo) Date: Sat Oct 16 02:41:01 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> Message-ID: <4170D296.5060909@ericsson.com> Folks, I would like to start the WGLC on the architecture draft. This WGLC will finish on November 15th. The draft will appear shortly in the archives. In the meantime, you can fetch it from: http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt A few words on the scope of this WGLC. This draft was originally intended to be published before WG formation, but it has been delayed for a number of reasons. As the draft states, the purpose of the document is to document the architectural reasoning as it was stated during the time of WG formation, and therefore the draft is informational or almost historical in nature. Hence, we ask people for clarifications, so that the content is understandable and easy to comprehend. However, asking for new argumentation (that did not exist back in fall 2003) or inclusion of new text may not be appropriate. Please, send you comments to the authors and to the mailing list. Thanks, Gonzalo HIP co-chair From petri.jokela@nomadiclab.com Mon Oct 18 07:24:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Oct 18 06:24:00 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <416D566A.4070909@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> Message-ID: <4173A99D.6000303@nomadiclab.com> So, what people think? We have (at least) four alternatives: 1) Stay at current: DSA mandatory 2) Both DSA and RSA mandatory 3) DSA mandatory, RSA SHOULD 4) Change the mandatory to RSA Opinions? /petri Jari Arkko wrote: > I'd be fine with just one algorithm (for now). > And my slight preference for that algorithm is > RSA... > > --Jari > > Julien Laganier wrote: > >> On Wednesday 13 October 2004 08:02, Pekka Nikander wrote: >> >>>> So how does people feel about making both DSA and RSA mandatory >>>> in HIP? >>> >>> >>> I don't have any strong opinions. IIRC, the usual IETF crypto >>> guidelines state that >>> >>> a) there must be at least one common MUST implement >>> algorithm that is considered secure enough >>> >>> b) the algorithms must be negotiable so that if the >>> currently MUST implement turns out to be insecure, >>> the implementations can be easily upgraded to use >>> some other, new MUST implement algorithm >>> >>> Anyone care to check what the guidelines and other >>> documents actually say? >>> >>> draft-ietf-ipsec-ikev2-algorithms-05.txt >> >> >> >> This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA >> and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt. >> However, an interesting thing is the new requirements keywords defined >> in draft-ietf-ipsec-ikev2-algorithms-05.txt: >> >> SHOULD+ This term means the same as SHOULD. However it is >> likely that an algorithm marked as SHOULD+ will be >> promoted at some future time to be a MUST. >> SHOULD- This terms means the same as SHOULD. However an >> algorithm marked as SHOULD- may be deprecated to a >> MAY in a future version of this document. >> MUST- This term means the same as MUST. However we >> expect at some point that this algorithm will no >> longer be a MUST in a future document. Although >> its status will be determined at a later time,it >> is reasonable to expect that if a future revision >> of a document alters the status of a MUST- >> algorithm, it will remain at least a SHOULD or a >> SHOULD-. >> >> >>> draft-iab-auth-mech-03.txt >> >> >> >> It said: >> >> -------------------- >> While the desire to support legacy authentication systems is under- >> standable, it should be resisted to the extent possible. Having mul- >> tiple equivalent mechanisms dramatically increases both implementa- >> tion complexity and interoperability problems. When designing a new >> system, designers should choose a very small number of authentication >> mechanisms, with no more than one of any given class. >> -------------------- >> >> And later >> >> -------------------- >> 13.2. Use As Few Mechanisms as You Can >> >> Preferably, systems should have only one form of authentication. The >> more methods of authentication a system allows, the more things there >> are to go wrong. Remember that a chain is only as strong as its weak- >> est link. In general, there are two reasons why systems allow more >> than one authentication mechanism. The first is that you're >> retrofitting a system which already has a large number of authentica- >> tion mechanisms which cannot be displaced. The second is that users >> have widely different environments which for some reason cannot use >> the same authentication mechanism conveniently (e.g. some users have >> tokens and some do not). >> >> Naturally, designers need to take such considerations into account >> but they should take reasonable steps to minimize the number of mech- >> anisms. Designers should take special care to minimize the number of >> equivalent mechanisms. For instance, a system that provides a chal- >> lenge/response mechanism and a public key based mechanism is a rea- >> sonable design, one that provides three different challenge/response >> mechanisms is not. >> >> This doesn't mean that designers should not use security frameworks >> where multiple mechanisms are appropriate, but it does mean that they >> should be avoided unless necessary. Where generic security frameworks >> are used, they supported mechanisms should be carefully profiled to a >> minimal set. >> -------------------- >> >> >>> crypto forum? >> >> >> >> I can ask them. >> >> >>> From a robustness point of view, it would of course good to >>> have multiple MUST implement algorithms. OTOH, I think >>> that there should also be some guidelines how to use them >>> so that the chances of interoperability are maintained >>> even in the case that one of the hosts only supports one >>> algorithm, e.g., due to policy reasons. >>> >>> Maybe we could have DSA as MUST and RSA as SHOULD? >>> >>> --Pekka >> >> >> >> I'm a bit confused by what I've read on the subject: IKEv2 has DSA as >> MUST and RSA as MUST, but draft-iab-auth-mech says that it should be >> avoided unless necessary. >> >> If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI >> algorithm capabilities (between RSA and DSA), so I tend to think that >> we should have both as MUST. >> >> Is there any other opinions the subject? >> >> Thanks, >> >> --julien >> _______________________________________________ >> Hipsec mailing list >> Hipsec@honor.trusecure.com >> http://honor.trusecure.com/mailman/listinfo/hipsec >> >> > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From pekka.nikander@nomadiclab.com Mon Oct 18 07:34:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 18 06:34:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <200410151408.04279.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> Message-ID: My sense from the discussion so far is that people slightly favour RSA. Hence, apparently we should go for - RSA MUST implement algorithm - DSA SHOULD implement algorithm What comes to algorithm negotiation, I think that we can go with the following approach: 1. In the case where the Initiator pre-fetches the Responder's HIT from somewhere (DNS, DHT, local storage), it can select a HIT that uses the desirable algorithm. That is, if the Initiator wants to use RSA, it selects an RSA based HIT for the Responder. 2. In the case where the Initiator sends a NULL HIT in I1 (opportunistic mode), we can simply state that the Initiator MUST support both RSA and DSA, and that the Responder SHOULD use a MUST algorithm (RSA) based key. To facilitate that, it seems that changing Step 4 in Section 8.5 is enough: -- 4. The R1 MUST contain the received responder HIT, unless the received HIT is NULL, in which case the Responder SHOULD select a HIT that is constructed with the MUST algorithm in Section 3, which is currently RSA. Other than that, selecting the HIT is a local policy matter. -- Adding some text to 7.1 doesn't seem to hurt: Add after "NULL (all zeros) as the Responder's HIT": -- If the Initiator send a NULL as the Responder's HIT, it MUST be able to handle all MUST and SHOULD algorithms from Section 3, which are currently RSA and DSA. -- If everybody is happy with that, we apparently need the following changes: - change second paragraph of Section 3 as follows: -- HIP implementations MUST support the Rivest Shamir Adelman (RSA) [XXX] public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) [13] algorithm; other algorithms MAY be supported. -- - new text to 3.1.1 to define, exactly, how to compute a HIT from a given RSA key. [I'm off-line so I can't prepare a proposal.] - fix the references in 6.2.10 - change the example text in the end of 6.2.13 to include text for RSA. - Add RFC 3110 reference which seems to be missing. I couldn't find any other places in the base spec, but may be there are others. --Pekka From pekka.nikander@nomadiclab.com Mon Oct 18 07:36:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 18 06:36:01 2004 Subject: [Hipsec] Is a HIT 126 or 128 bits long? In-Reply-To: <200410141531.37251.julien.laganier@sun.com> References: <200410141531.37251.julien.laganier@sun.com> Message-ID: > I basically agree with the changes you are proposing. I modified the > IPv6 LSI text of the -00 of the DNS draft, included below, Ok. Unless someone objects, IMHO you and Petri could edit in the changes to the -01 versions. To reduce secretariat load, it may not be necessary to post an -01 version of the dns draft, but it would be good if a pre-01 version was available prior to the meeting. But then, I'm afraid, we have to be prepared at the meeting that some people have only read -00 version, and adjust the presentation accordingly. >> 4. Add some text about IPv6 LSIs to Appendix A >> >> (I think the -00 version of the DNS draft has text that might >> fit in there, at least if slightly edited.) > > => Here's a modified excerpt matching the modifications you proposed: > > The first bit of a HIT is used to differentiate between Type 1 and > Type 2 format. If the first bit is 0 then the rest of a HIT is the > 127 upper bits of a SHA-1 hash of the Host Identity. If the first bit > is 1 then the next 63 bits is the HAA field, and only the last 64 > bits come from the hash of the Host Identity. Actually my suggestion was that there is no content differences between Type 1 and Type 2, but that the difference is always communicated by some external means. In the DNS it is the type field, in the HIP protocol the proposed SHT and DHT control fields. Hence, I would rewrite the paragraph, and what followed, as follows: -- Historically, the first two bits of a HIT were used to differentiate between Type 1, Type 2, and IPv6 address formats. This was changed in October 2004, when the Working Group decided that all (currently defined) HITs are 128-bit long. Hence, a Type 1 HIT consists of 128 bits of the SHA-1 hash of the public key, and a Type 2 HIT consists of a 64-bits long HAA field, followed by a 64-bits of the SHA-1 hash. [The format of the HAA field is left undefined in this document.] In this document, we additionally define an internal IPv6-compatible LSI- representation format, to be used within the legacy IPv6-compatible API (e.g., socket over AF_INET6). The format of these IPv6-compatible LSIs is designed to avoid the most commonly occurring IPv6 addresses in RFC3596 [9]. An IPv6-compatible LSI representation of a HIT can be easily computed by replacing the first TBDth bits of the HIT by the TBD bits long prefix "0xTBD". Accordingly, this specification also RECOMMENDS that conforming implementations ignore the TBD prefix bits when comparing HITs for equality; see Section XXX. -- As the text above is supposed to be in an appendix, we have to add in the HIT section of the base document text like the following: -- When comparing HITs for equality, it is RECOMMENDED that conforming implementations ignore the TBD top most bits. This is to allow better compatibility for legacy IPv6 applications; see Appendix A. However, independent of how many bits are actually used for HIT comparison, it is also RECOMMENDED that the final equality decision is based on the public key and not the HIT, if possible. See also Section for related discussion. -- I don't think we need the HIT space allocation table, but separately seek for IANA registration for the prefix, perhaps writing a brief separate document (one page long?) that defines IPv6 LSI usage and the prefix. > => Question: Do we need to include the type of the HIT in one of the > IPv6 LSI bits? If so, replace the last sentence and the table of the > text above by: IMHO, no. If we decide to get rid of the prefix, IMHO we should get rid of it altogether, and use all of the 128 bits of a (Type 1) HIT for hash. > IMHO the following changes are worth. If the WG agrees, I'll also > modify the DNS draft accordingly. Hence, opinions, others? --Pekka From petri.jokela@nomadiclab.com Mon Oct 18 07:58:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Oct 18 06:58:00 2004 Subject: [Hipsec] Base draft - 01-pre2 Message-ID: <4173B17C.9@nomadiclab.com> The 01-pre2 version of the base draft is available at http://hip4inter.net/drafts.php /petri From jeffrey.m.ahrenholz@boeing.com Mon Oct 18 11:51:01 2004 From: jeffrey.m.ahrenholz@boeing.com (Ahrenholz, Jeffrey M) Date: Mon Oct 18 10:51:01 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> (4) sounds fine to me. Pekka's text on negotiation seems reasonable. After reading the excerpts that Julien had posted, (2) does not sound desirable. -Jeff > So, what people think? We have (at least) four alternatives: >=20 > 1) Stay at current: DSA mandatory >=20 > 2) Both DSA and RSA mandatory >=20 > 3) DSA mandatory, RSA SHOULD >=20 > 4) Change the mandatory to RSA >=20 > Opinions? >=20 > /petri From jari.arkko@piuha.net Mon Oct 18 14:09:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon Oct 18 13:09:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> Message-ID: <41740896.2080905@piuha.net> 4 is OK for me. Ahrenholz, Jeffrey M wrote: > (4) sounds fine to me. Pekka's text on negotiation seems reasonable. > After reading the excerpts that Julien had posted, (2) does not sound > desirable. > > -Jeff > > >>So, what people think? We have (at least) four alternatives: >> >>1) Stay at current: DSA mandatory >> >>2) Both DSA and RSA mandatory >> >>3) DSA mandatory, RSA SHOULD >> >>4) Change the mandatory to RSA >> >>Opinions? >> >>/petri > > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From Julien.Laganier@Sun.COM Mon Oct 18 15:47:00 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Mon Oct 18 14:47:00 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <41740896.2080905@piuha.net> References: <2B3DC5CC87DC754E8EF8B9271F91AA2702361EF5@xch-nw-09.nw.nos.boeing.com> <41740896.2080905@piuha.net> Message-ID: <200410182157.48001.julien.laganier@sun.com> 4 is also OK for me. --julien On Monday 18 October 2004 20:16, Jari Arkko wrote: > 4 is OK for me. > > Ahrenholz, Jeffrey M wrote: > > (4) sounds fine to me. Pekka's text on negotiation seems > > reasonable. After reading the excerpts that Julien had posted, > > (2) does not sound desirable. > > > > -Jeff > > > >>So, what people think? We have (at least) four alternatives: > >> > >>1) Stay at current: DSA mandatory > >> > >>2) Both DSA and RSA mandatory > >> > >>3) DSA mandatory, RSA SHOULD > >> > >>4) Change the mandatory to RSA > >> > >>Opinions? > >> > >>/petri From Internet-Drafts@ietf.org Tue Oct 19 07:37:01 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue Oct 19 06:37:01 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-arch-00.txt Message-ID: <200410191146.HAA13897@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Architecture Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-arch-00.txt Pages : 24 Date : 2004-10-18 This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18172758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18172758.I-D@ietf.org> --OtherAccess-- --NextPart-- From lars.eggert@netlab.nec.de Tue Oct 19 10:29:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Tue Oct 19 09:29:01 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <4170D296.5060909@ericsson.com> References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> <4170D296.5060909@ericsson.com> Message-ID: <417526CC.3070502@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms040300000408010609010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gonzalo, Gonzalo Camarillo wrote: > > I would like to start the WGLC on the architecture draft. This WGLC will > finish on November 15th. The draft will appear shortly in the archives. > In the meantime, you can fetch it from: > > http://hip.piuha.net/drafts/draft-ietf-hip-arch-00.txt ... > As the draft states, the purpose of the document is to document the > architectural reasoning as it was stated during the time of WG > formation, and therefore the draft is informational or almost historical > in nature. Hence, we ask people for clarifications, so that the content > is understandable and easy to comprehend. However, asking for new > argumentation (that did not exist back in fall 2003) or inclusion of new > text may not be appropriate. what are we shooting for here, standards track or other? Thanks, Lars -- Lars Eggert NEC Network Laboratories --------------ms040300000408010609010902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMTkxNDM4MDRaMCMGCSqGSIb3DQEJBDEWBBSE8HxYbp7RMqgOSEhvF+l5Rzy+bzBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQB7l/Txf+RYtrpjQPNMl50pi6yhTdhwLgafjjCn3Rzd+h6X 1E5D1h2xQUzi8yTjeaHHgmmjwp0bjKNfS9wVUvS2aTFr9Rjv8DkbW0iLb/Ebu2dA556IDDt8 uSRDLPRC21sm4DXx/FVYmzruIGYXxendLJSwJK1OoVaxsWJKSc6vrRE+94CL79KLDP0sxNvj uZWE40v92c3pNvtCMvaHLZw8ASGEougoOSKHT6vkkezGp/Em4nwdxpsvq2tUgJil/k/zTkNn 0o7osmK5OZGDteQcM00DsMtXCi5R09EB+B/1bP2olg9bYmkxCK9wjjn2LMMSsQg9SvmpqrqJ LOGuU+MpAAAAAAAA --------------ms040300000408010609010902-- From miika@iki.fi Tue Oct 19 14:24:03 2004 From: miika@iki.fi (Miika Komu) Date: Tue Oct 19 13:24:03 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <4173A99D.6000303@nomadiclab.com> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> Message-ID: On Mon, 18 Oct 2004, Petri Jokela wrote: > So, what people think? We have (at least) four alternatives: > > 1) Stay at current: DSA mandatory > > 2) Both DSA and RSA mandatory > > 3) DSA mandatory, RSA SHOULD > > 4) Change the mandatory to RSA > > Opinions? First, I was going to say that I have had already enough fun with debugging host identifiers, and that changing the RSA as the default in our implementation will be a pain in you-know-where, but then I came up with something more productive :) There are some performance measurements on DSA and RSA e.g. in http://www.eskimo.com/~weidai/benchmarks.html: DSA 1024 Signature 2.18 ms RSA 1024 Signature 4.75 ms => DSA signing is 2.2 faster DSA 1024 Verification 2.49 ms RSA 1024 Verification 0.18 ms => RSA verification is 13.9 faster The initiator does two verifications (on R1 and R2) and one signature (I2). Since the RSA verification is much more faster, and the initiator does two of them, the initiator would get the most benefit. Without precreated R1s, the responder does one verification (I2) and two signatures (R1, R2). As the RSA signature creation is slower than with DSA, the responder has to do more work when using RSA. Intuitively, changing the default algorithm from DSA to RSA favours more initiators. We can verify this with a quick-and-dirty calculation based on the number of the cryptographic operations, and the time required for the cryptographic operations: initiator(dsa): 2 * 2.49 ms + 2.18 ms = 7.16 ms responder(dsa): 2 * 2.18 ms + 2.49 ms = 6.85 ms ==== total = 14.01 ms initiator(rsa): 2 * 0.18 ms + 4.75 ms = 5.11 ms responder(rsa): 2 * 4.75 ms + 0.18 ms = 9.68 ms ==== total = 14.79 ms We can see the favouring of the initiator of the above figures quite clearly. It should be noticed that the total time spent for signing and verifying remains almost the same with both the RSA and DSA. Of course, the figures are greater when a real HIP base exchange is conserned, but still proportional to the figures above. With precreated R1s the figures are as follows (responder "skips" one signature): initiator(dsa): 2 * 2.49 ms + 2.18 ms = 7.16 ms responder(dsa): 2.18 ms + 2.49 ms = 4.67 ms ==== total = 11.83 initiator(rsa): 2 * 0.18 ms + 4.75 ms = 5.11 ms responder(rsa): 4.75 ms + 0.18 ms = 4.93 ms ==== total = 10.04 ms The total time is almost the same with RSA and DSA. The initiator is now half the faster using RSA and responder is only slightly slower. This is a much better situation than before from the viewpoint of the responder, but performance obtained by the initiator is still quite minimal. In the light of these performance estimation figures, I still prefer the DSA because it is more friendly for the responders (i.e. busy servers) in the case where R1s are created on-the-fly; this is also coherent with the current architecture in which the initiators should do more work than responders due to DoS protection. On the other hand, we may have the increase the cookie size artificially in the implementation when using RSA because the responder will be doing more work in such a case. As a result, the *total* amount of work done by both the initiator and responder increases, and it is a bad idea IMHO. We should also notice that DSA is about 60 times faster in the key generation than RSA. Maybe this is useful e.g. for hosts that create lots of anonymous identifiers on the fly. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From jari.arkko@piuha.net Tue Oct 19 15:05:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue Oct 19 14:05:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> Message-ID: <41756725.1060002@piuha.net> Hi Miika, and thanks for doing the math for the rest of us! Your numbers are indeed interesting, and somewhat surprising, taking into account the difference between initiators and responders. Just one comment: > In the light of these performance estimation figures, I still prefer the > DSA because it is more friendly for the responders (i.e. busy servers) in > the case where R1s are created on-the-fly; this is also coherent with the I think the precreated R1 case is the default assumption, and should be at any rate if performance is a concern. So I'd like us to consider that situation as our primary problem. If I understood your numbers right, there was a minor increase dsa->rsa for responders in this case and a bigger decrease dsa->rsa for initiators. Based on this, RSA appears better from my point of view, though certainly not quite as much as I initially thought. --Jari From andrew@indranet.co.nz Tue Oct 19 16:17:01 2004 From: andrew@indranet.co.nz (Andrew McGregor) Date: Tue Oct 19 15:17:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <41756725.1060002@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> Message-ID: If I recall correctly, Miika has done the same math as Bob did when he was designing this. In other words, that DSA is lighter on the responder is the reason for DSA being the default at present. Bob's opinion was, I seem to recall, that the difference wasn't large but did slightly favour DSA. Andrew --On Tuesday, October 19, 2004 10:12 PM +0300 Jari Arkko wrote: > Hi Miika, and thanks for doing the math for > the rest of us! Your numbers are indeed interesting, > and somewhat surprising, taking into account the > difference between initiators and responders. > > Just one comment: > >> In the light of these performance estimation figures, I still prefer the >> DSA because it is more friendly for the responders (i.e. busy servers) in >> the case where R1s are created on-the-fly; this is also coherent with the > > I think the precreated R1 case is the default assumption, > and should be at any rate if performance is a concern. > So I'd like us to consider that situation as our primary > problem. If I understood your numbers right, there was a > minor increase dsa->rsa for responders in this case and > a bigger decrease dsa->rsa for initiators. Based on this, > RSA appears better from my point of view, though certainly > not quite as much as I initially thought. > > --Jari > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec > > From pekka.nikander@ericsson.com Tue Oct 19 23:39:01 2004 From: pekka.nikander@ericsson.com (Pekka Nikander) Date: Tue Oct 19 22:39:01 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <417526CC.3070502@netlab.nec.de> References: NEC Network Laboratories <417526CC.3070502@netlab.nec.de> Message-ID: > what are we shooting for here, standards track or other? Informative, or if not even that is possible, Historical. AFAIK, nothing from HIP WG is currently chartered for Standards Track. The base spec etc. are chartered for Experimental, but with standards track quality; the reason for Experimental being that we don't understand the consequences of id/loc split. --Pekka From lars.eggert@netlab.nec.de Wed Oct 20 08:53:01 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Wed Oct 20 07:53:01 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <4170D296.5060909@ericsson.com> References: <2CF6D718-1F3B-11D9-861F-000D9331AFB0@ericsson.com> <4170D296.5060909@ericsson.com> Message-ID: <417661E2.90003@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms060805050200000908080404 Content-Type: multipart/mixed; boundary="------------050906060906000206070309" This is a multi-part message in MIME format. --------------050906060906000206070309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > I would like to start the WGLC on the architecture draft. This WGLC will > finish on November 15th. The draft will appear shortly in the archives. ... > Please, send you comments to the authors and to the mailing list. I have some comments and some editing nits. I'll summarize the comments below, the attached diff has both them and the nits. Section 2, 2nd paragraph: "A Host Identity is assigned to each host. Each host will have at least one Host Identity..." So does it get a single one, or at least one? I think the latter, and would just remove the first sentence. Section 2, 2nd paragraph: "which can either be public (e.g. published in DNS), or unpublished." If one is "public", shouldn't we call the other kind "private" instead of "unpublished?" Section 2, 4th paragraph: A sentence on why we didn't go with IKE may be useful. Page 8: "Sometimes the names may contain a delegation component." Formatting is weird. Is this a new bullet or belongs to the previous one? Section 8, last paragraph: Uses upper-case "MAY" without referring to RFC 2119. We should probably change all RFC 2119 terms to lower case for this document. Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs and the corresponding IPsec SPIs to an IP address." Not sure what this sentence is supposed to mean. All section headings: Use consistent capitalization througout the document. -- Lars Eggert NEC Network Laboratories --------------050906060906000206070309 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="draft-ietf-hip-arch-00-diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-hip-arch-00-diff.txt" --- draft-ietf-hip-arch-00.txt Wed Oct 20 15:00:26 2004 +++ draft-ietf-hip-arch-00-le.txt Wed Oct 20 14:59:55 2004 @@ -40,15 +40,15 @@ Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2004.) Abstract This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the - Host Identity Protocol, between the internetworking and transport - layers. Herein are presented the basics of the current namespaces, - strengths and weaknesses, and how a new namespace will add + Host Identity Protocol, between the network and transport + layers. It describes the Internet's current namespaces, their + strengths and weaknesses, and how the new Host Identity namespace integrates with them. @@ -57,8 +57,7 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - completeness to them. The roles of this new namespace in the - protocols are defined. The memo describes the thinking of the + The memo describes the thinking of the authors as of Fall 2003. Table of Contents @@ -118,28 +117,27 @@ The purpose of this memo is to provide a stable reference point in the development of the Host Identity Protocol architecture. This memo describes the thinking of the authors as of Fall 2003; their - thinking may have evolved since then. In occasions, this memo may be + thinking may have changed since then. Occasionally, this memo may be confusing or self-contradicting. That is (partially) intentional, and reflects the snapshot nature of this memo. 2. Introduction - The Internet has created two important global namespaces: Internet + The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These - two namespaces have a set of features and abstractions that have - powered the Internet to what it is today. They also have a number of - weaknesses. Basically, since they are all we have, we try and do too + two namespaces have sets of features and abstractions that have + enabled the growth of the Internet to this day. They also have a number of + weaknesses. Basically, because they are all we have, we try to do too much with them. Semantic overloading and functionality extensions - have greatly complicated these namespaces. + have greatly complicated interactions with or changes to these namespaces. The proposed Host Identity namespace fills an important gap between the IP and DNS namespaces. The Host Identity namespace consists of - Host Identifiers (HI). A Host Identifier is cryptographic in its - nature; it is the public key of an asymmetric key-pair. A Host - Identity is assigned to each host. Each host will have at least one - Host Identity and a corresponding Host Identifier, which can either - be public (e.g. published in DNS), or unpublished. Client systems - will tend to have both public and unpublished Identities. + Host Identifiers (HI.) A Host Identifier is cryptographic; + it is the public key of an asymmetric key-pair. Each host will have at least one + Host Identity and at least one corresponding Host Identifier, which can either + be public (e.g., published in DNS), or private. Client systems + will tend to have both public and private Identities. There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that @@ -284,10 +282,10 @@ 4. Background The Internet is built from three principal components: computing - platforms (end-points), packet transport (i.e. internetworking) - infrastructure, and services (applications). The Internet exists to + platforms (end-points), packet transport (i.e., internetworking) + infrastructure, and services (applications.) The Internet exists to service two principal components: people and robotic services - (silicon based people, if you will). All these components need to be + (silicon based people, if you will.) All these components need to be named in order to interact in a scalable manner. Here we concentrate on naming computing platforms and packet transport elements. @@ -298,7 +296,7 @@ IP numbers are a confounding of two namespaces, the names of a host's networking interfaces and the names of the locations ('confounding' is a term used in statistics to discuss metrics that are merged into - one with a gain in indexing, but a loss in informational value). The + one with a gain in indexing, but a loss in informational value.) The names of locations should be understood as denoting routing direction vectors, i.e., information that is used to deliver packets to their destinations. @@ -345,7 +343,7 @@ This could support rapid readdressing of the internetworking layer because of mobility, rehoming, or renumbering. - If the namespace for computing platforms is based on public key + If the namespace for computing platforms is based on public-key cryptography, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity. @@ -359,7 +357,7 @@ o The namespace should fully decouple the internetworking layer from the higher layers. The names should replace all occurrences of IP - addresses within applications (like in the TCB). This may require + addresses within applications (like in the TCB.) This may require changes to the current APIs. In the long run, it is probable that some new APIs are needed. @@ -369,7 +367,7 @@ o The names should have a fixed length representation, for easy inclusion in datagram headers and existing programming interfaces - (e.g the TCB). + (e.g the TCB.) o Using the namespace should be affordable when used in protocols. This is primarily a packet size issue. There is also a @@ -409,7 +407,7 @@ In this document, a new namespace approaching these ideas is called the Host Identity namespace. Using Host Identities requires its own protocol layer, the Host Identity Protocol, between the - internetworking and transport layers. The names are based on public + internetworking and transport layers. The names are based on public- key cryptography to supply authentication services. Properly designed, it can deliver all of the above stated requirements. @@ -430,11 +428,11 @@ unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As documented in the Host Identity Protocol - specification [4], a public key based HI can authenticate the HIP - packets and protect them for man-in-the-middle attacks. Since + specification [4], a public-key-based HI can authenticate the HIP + packets and protect them for man-in-the-middle attacks. Because authenticated datagrams are mandatory to provide much of HIP's denial-of-service protection, the Diffie-Hellman exchange in HIP has - to be authenticated. Thus, only public key HI and authenticated HIP + to be authenticated. Thus, only public-key HI and authenticated HIP messages are supported in practice. In this document, the non-cryptographic forms of HI and HIP are presented to complete the theory of HI, but they should not be implemented as they could @@ -462,7 +460,7 @@ The only completely defined structure of the Host Identity is that of a public/private key pair. In this case, the Host Identity is referred to by its public component, the public key. Thus, the name - representing a Host Identity in the Host Identity namespace, i.e. + representing a Host Identity in the Host Identity namespace, i.e., the Host Identifier, is the public key. In a way, the possession of the private key defines the Identity itself. If the private key is possessed by more than one node, the Identity can be considered to be @@ -491,12 +489,12 @@ The public Host Identifiers should be stored in DNS; the unpublished Host Identifiers should not be stored anywhere (besides the - communicating hosts themselves). The (public) HI is stored in a new + communicating hosts themselves.) The (public) HI is stored in a new RR type, to be defined. This RR type is likely to be quite similar to the IPSECKEY RR [5]. Alternatively, or in addition to storing Host Identifiers in the DNS, - they may be stored in various kinds of Public Key Infrastructure + they may be stored in various kinds of public-key infrastructure @@ -505,7 +503,7 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - (PKI). Such a practice may allow them to be used for purposes other + (PKI.) Such a practice may allow them to be used for purposes other than pure host identification. 5.3 Host Identity Tag (HIT) @@ -590,14 +588,14 @@ 6.1 Transport associations and end-points - Architecturally, HIP provides for a different binding of transport - layer protocols. That is, the transport layer associations, i.e., + Architecturally, HIP provides for a different binding of transport- + layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but to Host Identities. It is possible that a single physical computer hosts several logical end-points. With HIP, each of these end-points would have a distinct - Host Identity. Furthermore, since the transport associations are + Host Identity. Furthermore, because the transport associations are bound to Host Identities, HIP provides for process migration and clustered servers. That is, if a Host Identity is moved from one physical computer to another, it is also possible to simultaneously @@ -621,7 +619,7 @@ HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities (through actually - either the HIT or LSI). Consequently, HIP can provide for a degree + either the HIT or LSI.) Consequently, HIP can provide for a degree of internetworking mobility and multi-homing at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if its IP address @@ -643,7 +641,7 @@ that the mobile node is reachable through these addresses. This is especially helpful for those situations where the peer node is sending data periodically to the mobile node (that is re-starting a - connection after the initial connection). + connection after the initial connection.) 7.1 Rendezvous mechanism @@ -655,7 +653,7 @@ new static infrastructure to facilitate rendezvous between HIP nodes. The mobile node keeps the rendezvous infrastructure continuously - updated with its current IP address(es). The mobile nodes must trust + updated with its current IP address(es.) The mobile nodes must trust the rendezvous mechanism to properly maintain their HIT and IP address mappings. @@ -678,7 +676,7 @@ 7.2 Protection against Flooding Attacks - While the idea of informing about address changes by simply sending + Although the idea of informing about address changes by simply sending packets with a new source address appears appealing, it is not secure enough. That is, even if HIP does not rely on the source address for anything (once the base exchange has been completed), it appears to @@ -717,7 +715,7 @@ enable ESP in an end-to-end manner. This is implemented in a way that can span addressing realms. - While it would be possible, at least in theory, to use some existing + Although it would be possible, at least in theory, to use some existing cryptographic protocol, such as IKEv2 together with Host Identifiers, to establish the needed SAs, HIP defines a new protocol. There are a number of historical reasons for this, and there are also a few @@ -729,16 +727,15 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - architectural reasons. First, IKE (and IKEv2) were not design with - middle boxes in mind. As adding a new naming layer allows one to + architectural reasons. First, IKE (and IKEv2) were not designed with + middleboxes in mind. Because adding a new naming layer allows one to potentially add a new forwarding layer (see Section 9, below), it is - very important that the HIP protocols are friendly towards any middle - boxes. + very important that the HIP protocols can traverse any middleboxes. Second, from a conceptual point of view, the IPsec Security Parameter Index (SPI) in ESP provides a simple compression of the HITs. This does require per-HIT-pair SAs (and SPIs), and a decrease of policy - granularity over other Key Management Protocols, such as IKE and + granularity over other key-management protocols, such as IKE and IKEv2. In particular, the current thinking is limited to a situation where, conceptually, there is only one pair of SAs between any given pair of HITs. In other words, from an architectural point of view, @@ -748,24 +745,24 @@ may provide for more granularity and creation of several ESP SAs between a pair of HITs. - Since HIP is designed for host usage, not for gateways or so called - Bump-in-the-Wire (BITW) implementations, only ESP transport mode is + Because HIP is designed for host usage, not for gateways or so called + bump-in-the-wire (BITW) implementations, only ESP transport mode is supported. An ESP SA pair is indexed by the SPIs and the two HITs - (both HITs since a system can have more than one HIT). The SAs need + (both HITs, because a system can have more than one HIT.) The SAs need not to be bound to IP addresses; all internal control of the SA is by the HITs. Thus, a host can easily change its address using Mobile IP, DHCP, PPP, or IPv6 readdressing and still maintain the SAs. - Since the transports are bound to the SA (via an LSI or a HIT), any + Because the transports are bound to the SA (via an LSI or a HIT), any active transport is also maintained. Thus, real world conditions like loss of a PPP connection and its re-establishment or a mobile handover will not require a HIP negotiation or disruption of - transport services. [12] + transport services [12]. - Since HIP does not negotiate any SA lifetimes, all lifetimes are + Because HIP does not negotiate any SA lifetimes, all lifetimes are local policy. The only lifetimes a HIP implementation MUST support are sequence number rollover (for replay protection), and SA - timeout[4]. An SA times out if no packets are received using that - SA. Implementations MAY support lifetimes for the various ESP + timeout [4]. An SA times out if no packets are received using that + SA. Implementations may support lifetimes for the various ESP transforms. 9. HIP and NATs @@ -785,35 +782,35 @@ Internet-Draft Host Identity Protocol Architecture October 2004 - In a network environment where the identification is based on the IP + In a network environment where identification is based on IP addresses, identifying the communicating nodes is difficult when NAT - is used. With HIP, the transport layer end-points are bound to the + is used. With HIP, the transport-layer end-points are bound to Host Identities. Thus, a connection between two hosts can traverse many addressing realm boundaries. The IP addresses are used only for - routing purposes; the IP addresses may be changed freely during + routing purposes; IP addresses may be changed freely during packet traversal. - For a HIP based flow, a HIP-aware NAT or NAT-PT system tracks the + For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs and the corresponding IPsec SPIs to an IP address. Many HITs can map to a single IP address on a NAT, simplifying connections on address poor NAT interfaces. The NAT can gain much of its knowledge from the HIP packets themselves; however, some NAT configuration may be necessary. - The NAT systems cannot touch the datagrams within the IPsec envelope, - thus application specific address translation must be done in the end + NAT systems cannot touch datagrams within the IPsec envelope, + thus application-specific address translation must be done in the end systems. HIP provides for 'Distributed NAT', and uses the HIT or the - LSI as a place holder for embedded IP addresses. + LSI as a placeholder for embedded IP addresses. -9.1 HIP and TCP Checksum +9.1 HIP and TCP Checksums - There is no way for a host to know if any of the IP addresses in the + There is no way for a host to know if any of the IP addresses in an IP header are the addresses used to calculate the TCP checksum. That is, it is not feasible to calculate the TCP checksum using the actual IP addresses in the pseudo header; the addresses received in the incoming packet are not necessarily the same as they were on the - sending host. Furthermore, it is not possible to recompute the upper - layer checksums in the NAT/NAT-PT system, since the traffic is IPsec + sending host. Furthermore, it is not possible to recompute the upper- + layer checksums in the NAT/NAT-PT system, because the traffic is IPsec protected. Consequently, the TCP and UDP checksums are calculated using the HITs in the place of the IP addresses in the pseudo header. Furthermore, only the IPv6 pseudo header format is used. This @@ -821,16 +818,16 @@ 10. Multicast - Back in fall 2003, there was little if any concrete thoughts about - how HIP might affect IP or application layer multi-cast. + Back in the fall of 2003, there were little if any concrete thoughts about + how HIP might affect IP or application-layer multicast. 11. HIP Policies - There are a number of variables that will influence the HIP exchanges + There are a number of variables that influence the HIP exchanges that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS and an unpublished one for anonymous usage. Although unpublished HIs will be rarely used as - responder HIs, they are likely be common for initiators. Support for + responder HIs, they are likely common for initiators. Support for multiple HIs is recommended. @@ -852,7 +849,7 @@ 12. Benefits of HIP - In the beginning, the network layer protocol (i.e. IP) had the + In the beginning, the network layer protocol (i.e., IP) had the following four "classic" invariants: o Non-mutable: The address sent is the address received. @@ -869,26 +866,26 @@ Actually, the fourth can be inferred from 1 and 3, but it is worth mentioning for reasons that will be obvious soon if not already. - In the current "post-classic" world, we are trying intentionally to + In the current "post-classic" world, we are intentionally trying to get rid of the second invariant (both for mobility and for multi-homing), and we have been forced to give up the first and the - fourth. Realm Specific IP [3] is an attempt to reinstate the fourth + fourth. Realm-Specific IP [3] is an attempt to reinstate the fourth invariant without the first invariant. IPv6 is an attempt to reinstate the first invariant. - Few systems on the Internet have DNS names that are meaningful to - them. That is, if they have a Fully Qualified Domain Name (FQDN), - that typically belongs to a NAT device or a dial-up server, and does + Few systems on the Internet have DNS names that are meaningful. + That is, if they have a Fully Qualified Domain Name (FQDN), + that name typically belongs to a NAT device or a dial-up server, and does not really identify the system itself but its current connectivity. - FQDN names (and their extensions as email names) are Application - Layer names; more frequently naming services than a particular - system. This is why many systems on the internet are not registered - in DNS; they do not have services of interest to other Internet + FQDNs (and their extensions as email names) are application- + layer names; more frequently naming services than a particular + system. This is why many systems on the Internet are not registered + in the DNS; they do not have services of interest to other Internet hosts. DNS names are references to IP addresses. This only demonstrates the interrelationship of the networking and application layers. DNS, as - the Internet's only deployed, distributed, database is also the + the Internet's only deployed, distributed database is also the @@ -905,14 +902,14 @@ The Host Identity (HI) namespace fills an important gap between the IP and DNS namespaces. An interesting thing about the HI is that it - actually allows one to give-up all but the 3rd Network Layer + actually allows one to give up all but the 3rd network-layer invariant. That is to say, as long as the source and destination - addresses in the network layer protocol are reversible, then things + addresses in the network-layer protocol are reversible, then things work ok because HIP takes care of host identification, and reversibility allows one to get a packet back to one's partner host. - You don't care if the network layer address changes in transit - (mutable) and you don't care what network layer address the partner - is using (non-omniscient). + You do not care if the network-layer address changes in transit + (mutable) and you do not care what network-layer address the partner + is using (non-omniscient.) 12.1 HIP's Answers to NSRG questions @@ -943,7 +940,7 @@ HIP provides both stable and temporary Host Identifiers. Stable HIs are typically long lived, with a lifetime of years or more. The lifetime of temporary HIs depends on how long - the upper layer connections and applications need them, and + the upper-layer connections and applications need them, and can range from a few seconds to years. @@ -962,7 +959,7 @@ The Host Identifiers may be used directly or indirectly (in the form of HITs or LSIs) by applications when they access network services. Additionally, the Host Identifiers, as - public keys, are used in the built in key agreement protocol, + public keys, are used in the built in key-agreement protocol, called the HIP base exchange, to authenticate the hosts to each other. @@ -986,8 +983,8 @@ HIP reduces dependency on IP addresses, making the so called address ownership [11] problems easier to solve. In practice, HIP provides security for end-host mobility and multi-homing. - Furthermore, since HIP Host Identifiers are public keys, - standard public key certificate infrastructures can be applied + Furthermore, because Host Identifiers are public keys, + standard public-key certificate infrastructures can be applied on the top of HIP. 9. What would the resolution mechanisms be, or what characteristics @@ -998,7 +995,7 @@ However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be - based on the ideas of Distributed Hash Tables, but would + based on the ideas of distributed hash tables, but would require significant new development and deployment. @@ -1019,7 +1016,7 @@ that potentially could be more damaging to a host's ability to conduct business as usual. - Resource exhausting Denial-of-service attacks take advantage of the + Resource exhausting denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP allows a responder to increase the cost of the start of state on the initiator and makes an @@ -1036,7 +1033,7 @@ method to force the start of HIP is expensive on either host, the attacker need only spoof a TCP SYN. This would put both systems into the expensive operations. HIP avoids this attack by having the - responder send a simple HIP packet that it can pre-build. Since this + responder send a simple HIP packet that it can pre-build. Because this packet is fixed and easily replayed, the initiator only reacts to it if it has just started a connection to the responder. @@ -1048,14 +1045,14 @@ initiator can use this to authenticate the signed HIP packets. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it and validate the signed HIP packets. - However, since an initiator may choose to use an unpublished HI, it + However, because an initiator may choose to use an unpublished HI, it knowingly risks a MitM attack. The responder may choose not to accept a HIP exchange with an initiator using an unknown HI. In HIP, the Security Association for IPsec is indexed by the SPI; the source address is always ignored, and the destination address may be - ignored as well. Therefore, HIP enabled IPsec Encapsulated Security - Payload (ESP) is IP address independent. This might seem to make it + ignored as well. Therefore, HIP enabled IPsec encapsulated security + payload (ESP) is IP address independent. This might seem to make it easier for an attacker, but ESP with replay protection is already as @@ -1068,7 +1065,7 @@ well protected as possible, and the removal of the IP address as a check should not increase the exposure of IPsec ESP to DoS attacks. - Since not all hosts will ever support HIP, ICMPv4 'Destination + Because not all hosts will ever support HIP, ICMPv4 'Destination Unreachable, Protocol Unreachable' and ICMPv6 'Parameter Problem, Unrecognized Next Header' messages are to be expected and present a DoS attack. Against an initiator, the attack would look like the @@ -1088,7 +1085,7 @@ the defense against this attack is for the initiator to wait a reasonable time period to get a valid HIP packet. If one does not come, then the initiator has to assume that the ICMP message is - valid. Since this is the only point in the HIP base exchange where + valid. Because this is the only point in the HIP base exchange where this ICMP message is appropriate, it can be ignored at any other point in the exchange. @@ -1098,20 +1095,20 @@ use HITs to control egress and ingress to networks, with an assurance level difficult to achieve today. As discussed above in Section 8, once a HIP session has been established, the SPI value in an IPsec - packet may be used as an index, indicating the HITs. In practise, - the firewalls can inspect the HIP packets to learn of the bindings + packet may be used as an index, indicating the HITs. In practice, + firewalls can inspect HIP packets to learn of bindings between HITs, SPI values, and IP addresses. They can even explicitly control IPsec usage, dynamically opening IPsec ESP only for specific - SPI values and IP addresses. The signatures in the HIP packets allow - a capable firewall to make sure that the HIP exchange is indeed + SPI values and IP addresses. The signatures in HIP packets allow + a capable firewall to ensure that the HIP exchange is indeed happening between two known hosts. This may increase firewall security. There has been considerable bad experience with distributed ACLs that - contain public key related material, for example, with SSH. If the - owner of the key needs to revoke it for any reason, the task of + contain public-key-related material, for example, with SSH. If the + owner of a key needs to revoke it for any reason, the task of finding all locations where the key is held in an ACL may be - impossible. If the reason for the revocation is due to private key + impossible. If the reason for the revocation is due to private-key theft, this could be a serious issue. @@ -1129,10 +1126,10 @@ HIP-aware NATs, however, are transparent to the HIP aware systems by design. Thus, the host may find it difficult to notify any NAT that - is using a HIT in an ACL. Since most systems will know of the NATs + is using a HIT in an ACL. Because most systems will know of the NATs for their network, there should be a process by which they can notify these NATs of the change of the HIT. This is mandatory for systems - that function as responders behind a NAT. In a similar vein, if a + that function as responders behind a NAT. Similarly, if a host is notified of a change in a HIT of an initiator, it should notify its NAT of the change. In this manner, NATs will get updated with the HIT change. @@ -1141,21 +1138,21 @@ The definition of the Host Identifier states that the HI need not be a public key. It implies that the HI could be any value; for example - an FQDN. This document does not describe how to support such a + a FQDN. This document does not describe how to support such a non-cryptographic HI. A non-cryptographic HI would still offer the - services of the HIT or LSI for NAT traversal. It would be possible - carry the HITs in HIP packets that had neither privacy nor - authentication. Since such a mode would offer so little additional - functionality for so much addition to the IP kernel, it has not been - defined. Given how little public key cryptography HIP requires, HIP - should only be implemented using public key Host Identities. + services of the HIT or LSI for NAT traversal. It would be possible to + carry HITs in HIP packets that have neither privacy nor + authentication. Because such a mode would offer so little additional + functionality for the complexities it adds to an IP kernel, it has not been + defined. Given how little public-key cryptography HIP requires, HIP + should only be implemented using public-key Host Identities. If it is desirable to use HIP in a low security situation where - public key computations are considered expensive, HIP can be used + public-key computations are considered expensive, HIP can be used with very short Diffie-Hellman and Host Identity keys. Such use - makes the participating hosts vulnerable to MitM and connection + makes the participating hosts vulnerable to MitM and connection- hijacking attacks. However, it does not cause flooding dangers, - since the address check mechanism relies on the routing system and + because the address check mechanism relies on the routing system and not on cryptographic strength. 14. Acknowledgments @@ -1327,7 +1324,7 @@ Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2004.) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. --------------050906060906000206070309-- --------------ms060805050200000908080404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMjAxMzAyMjZaMCMGCSqGSIb3DQEJBDEWBBRXbHmECVQhLcDjaNr/XdJFsgKy5TBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQCsUWhcysG5aZYBxzFtwj5qD4g9JXeZfbRb3jKQ6Z+COSa4 u3qajfBJnYsf0C5xmEHDMbElo6B12wDFaN9Qd6gSVBMEgKejYAm7o6Joyb2rAMASBHj5FouU RuuZgYDOFOGcz8WeNOyUTeIFWTTXFb69yId+cJIjD0LYoOH+fzXbJAAB0JDt97gkMARwMc9l 8J0nP991b4KrHMFXYz8Vbw6FsCwn4xJJKneZ+wvJ5Q4dofMQU5rMuXNIr7YW2nd4i4Ct6JNy znBBz3N0b3GxzK/NC1ISO+VwF2DyGzFVOjOWH4DXNyQrihlaKsvAeOycr8TMNf2YLtvqRpka dlXSQA3NAAAAAAAA --------------ms060805050200000908080404-- From Internet-Drafts@ietf.org Wed Oct 20 10:18:01 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed Oct 20 09:18:01 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-mm-00.txt Message-ID: <200410201426.KAA08010@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : End-Host Mobility and Multi-Homing with Host Identity Protocol Author(s) : P. Nikander, et al. Filename : draft-ietf-hip-mm-00.txt Pages : 34 Date : 2004-10-19 This document specifies basic end-host mobility and multi-homing mechanisms for the Host Identity Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-mm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-mm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-mm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-mm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104709.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Oct 20 10:18:06 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed Oct 20 09:18:06 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-dns-00.txt Message-ID: <200410201426.KAA08042@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Author(s) : P. Nikander, J. Laganier Filename : draft-ietf-hip-dns-00.txt Pages : 24 Date : 2004-10-19 This document specifies two new resource records for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These records allow a HIP node to store in the DNS its Host Identity (its public key), Host Identity Tag (a truncated hash of its public key), and Rendezvous Servers (RVS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-dns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104715.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Oct 20 10:18:09 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed Oct 20 09:18:09 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-00.txt Message-ID: <200410201427.KAA08093@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extensions Author(s) : J. Laganier, L. Eggert Filename : draft-ietf-hip-rvs-00.txt Pages : 33 Date : 2004-10-19 This document discusses rendezvous extensions for the Host Identity Protocol (HIP). Rendezvous mechanisms extend HIP for communication with HIP Rendezvous Servers. Rendezvous Servers improve operation when HIP nodes are multi-homed or mobile. The first part of his document motivates the need for rendezvous mechanisms; the second part describes the protocol extensions in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-rvs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-rvs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20104720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-rvs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-rvs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20104720.I-D@ietf.org> --OtherAccess-- --NextPart-- From pekka.nikander@nomadiclab.com Wed Oct 20 11:03:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Wed Oct 20 10:03:00 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <417661E2.90003@netlab.nec.de> References: NEC Network Laboratories <417661E2.90003@netlab.nec.de> Message-ID: <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> > I have some comments and some editing nits. I'll summarize the comments > below, the attached diff has both them and the nits. Thanks. I'll return to the nits later. > Section 2, 2nd paragraph: "A Host Identity is assigned to each host. > Each host will have at least one Host Identity..." So does it get a > single one, or at least one? I think the latter, and would just remove > the first sentence. As far as I can understand what Bob has meant, the first sentence says that the HI->host direction of the relationship is unary and non-zero, and the second says that the HI<-host direction is not unary but there may be multiple IDs per host. IMHO, both are needed. OTOH, the sentences could be certainly reformulated, if people find them confusing. Any suggestions for rewording? > Section 2, 2nd paragraph: "which can either be public (e.g. published > in > DNS), or unpublished." If one is "public", shouldn't we call the other > kind "private" instead of "unpublished?" The term that we user before was "anonymous", but some people felt that it was inappropriate. "private" was also thought to be bad, since an unpublished HI may not be secret, and "private" in that sense. As a compromise, I chose "unpublished", which I agree to be bad, but maybe less bad than the others. Anyway, I don't that much care about what term we use, as long as we are consistent. Any suggestions or opinions? > Section 2, 4th paragraph: A sentence on why we didn't go with IKE may > be > useful. Would a reference to Section 8 do? > Page 8: "Sometimes the names may contain a delegation component." > Formatting is weird. Is this a new bullet or belongs to the previous > one? It belongs to a previous one. Any suggestions on how to change the formatting? > Section 8, last paragraph: Uses upper-case "MAY" without referring to > RFC 2119. We should probably change all RFC 2119 terms to lower case > for > this document. Ok, that is an oversight by me. I will fix it. I didn't find anything else but one MUST. Did I miss something? > Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or > NAT-PT system tracks the mapping of HITs and the corresponding IPsec > SPIs to an IP address." Not sure what this sentence is supposed to > mean. I'll take this up separately as this may need some discussion. (Later, now I must go.) > All section headings: Use consistent capitalization througout the > document. Ok, I will fix that. --Pekka From lars.eggert@netlab.nec.de Wed Oct 20 12:17:00 2004 From: lars.eggert@netlab.nec.de (Lars Eggert) Date: Wed Oct 20 11:17:00 2004 Subject: [Hipsec] WG LC on architecture draft In-Reply-To: <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> References: NEC Network Laboratories <417661E2.90003@netlab.nec.de> <742BAFE4-22AA-11D9-B72A-000D9331AFB0@nomadiclab.com> Message-ID: <417691AD.2090505@netlab.nec.de> This is a cryptographically signed message in MIME format. --------------ms080900090701080707040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pekka Nikander wrote: >> I have some comments and some editing nits. I'll summarize the comments >> below, the attached diff has both them and the nits. > > > Thanks. I'll return to the nits later. > >> Section 2, 2nd paragraph: "A Host Identity is assigned to each host. >> Each host will have at least one Host Identity..." So does it get a >> single one, or at least one? I think the latter, and would just remove >> the first sentence. > > As far as I can understand what Bob has meant, the first sentence > says that the HI->host direction of the relationship is unary and > non-zero, and the second says that the HI<-host direction is not unary > but there may be multiple IDs per host. IMHO, both are needed. OTOH, > the sentences could be certainly reformulated, if people find > them confusing. Any suggestions for rewording? How about: "Each host will have at least one host identity, but may have multiple ones. Each host identity uniquely identifies a single host, i.e., no two hosts have the same host identity." >> Section 2, 2nd paragraph: "which can either be public (e.g. published in >> DNS), or unpublished." If one is "public", shouldn't we call the other >> kind "private" instead of "unpublished?" > > The term that we user before was "anonymous", but some people felt > that it was inappropriate. "private" was also thought to be bad, > since an unpublished HI may not be secret, and "private" in that sense. > As a compromise, I chose "unpublished", which I agree to be bad, > but maybe less bad than the others. > > Anyway, I don't that much care about what term we use, as long as > we are consistent. Any suggestions or opinions? Didn't know these had been discussed. The comment was based on the observation that "unpublished" isn't the natural opposite of "public." Anyhow, I don't think this is really too important. >> Section 2, 4th paragraph: A sentence on why we didn't go with IKE may be >> useful. > > Would a reference to Section 8 do? Yup, saw that there is more on that later. >> Page 8: "Sometimes the names may contain a delegation component." >> Formatting is weird. Is this a new bullet or belongs to the previous >> one? > > It belongs to a previous one. Any suggestions on how to change the > formatting? Move it under the previous bullet then? Currently it looks like this, which is probably an xml2rfc issue: o It must be possible to create names locally. This can provide anonymity at the cost of making resolvability very difficult. Sometimes the names may contain a delegation component. This is the cost of resolvability. >> Section 8, last paragraph: Uses upper-case "MAY" without referring to >> RFC 2119. We should probably change all RFC 2119 terms to lower case for >> this document. > > Ok, that is an oversight by me. I will fix it. I didn't find anything > else but one MUST. Did I miss something? Didn't find anything else either. >> Section 9, third pararaph: "For a HIP-based flow, a HIP-aware NAT or >> NAT-PT system tracks the mapping of HITs and the corresponding IPsec >> SPIs to an IP address." Not sure what this sentence is supposed to mean. > > I'll take this up separately as this may need some discussion. > (Later, now I must go.) On second reading, it makes sense. When I first read it, I wasn't able to parse the sentence. Lack of coffee, probably. >> All section headings: Use consistent capitalization througout the >> document. > > Ok, I will fix that. Lars -- Lars Eggert NEC Network Laboratories --------------ms080900090701080707040800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDEwMjAxNjI2MjFaMCMGCSqGSIb3DQEJBDEWBBToN9FXSxIGvxDdyPN1Efrv+olbGjBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQA1hIHZh1KVZZyuXWIRNwEkYph8mhnAxjdMMtX6RBD3UfbD lqXUQGKJ63oGlaEnF70EhvTgBYGZEro1lQy6uga+hbWiIH7kCYNCRREs675QfW+nNpwJaT3R unPPrt03EhZXiv2wbVjj++1pfI0rSrrd5X4U/TFwMnfoDDpOyh5aFl88eb0UANBHYB5z455s hc4jo9BA7cx5mghnnNQIPs4c6l8TYlGt8gm5PvcR0/JkfqFA0aVGeV5Z0hn25p88uiQVj10a G79IA7FADYUeLdHoMxgURSiS1v5Kn4uYd2uuWhVs3ArASUa9BjFo2PHsn9R8o0Ubun5B67GA /v75BbRJAAAAAAAA --------------ms080900090701080707040800-- From thomas.r.henderson@boeing.com Wed Oct 20 21:42:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 20 20:42:01 2004 Subject: [Hipsec] Base draft - 01-pre2 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> > The 01-pre2 version of the base draft is available at >=20 > http://hip4inter.net/drafts.php >=20 A few comments: Section 5: 5.4.1-- CLOSED HIP SA clos, no data (ESP) can be sent ^^ed =20 in state CLOSING, receive I1, stay at UNASSOCIATED ^^^^^^^^^^^^ CLOSING (same copy and paste error for state CLOSED) =20 Section 6: Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try to = interoperate these packets. Can we pick some values now?=20 Section 8.16: as i specified in Section 6.3.5. ^^ (delete) Section 13: =20 NATing, etc.). However, the optionnal behavior of replying to CLOSE ^^^^^^^^^ optional =20 reflexion attacks. ^^^^^^^^^ reflection From thomas.r.henderson@boeing.com Thu Oct 21 00:27:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Wed Oct 20 23:27:01 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Monday, October 18, 2004 3:46 AM > To: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > My sense from the discussion so far is that people slightly > favour RSA. Hence, apparently we should go for >=20 > - RSA MUST implement algorithm > - DSA SHOULD implement algorithm I support that. >=20 > What comes to algorithm negotiation, I think that we can > go with the following approach: I am not worried about negotiation or evolving this for now, but it seems difficult, if only HITs are known before the handshake, to use anything but RSA. If we ever go away from "MUST" RSA, we may have to consider some extensions for negotiation. Tom From pekka.nikander@nomadiclab.com Thu Oct 21 01:34:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 21 00:34:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608C7@xch-nw-27.nw.nos.boeing.com> Message-ID: <0A8E72BE-2324-11D9-B72A-000D9331AFB0@nomadiclab.com> Tom, > I am not worried about negotiation or evolving this > for now, but it seems difficult, if only HITs are known > before the handshake, to use anything but RSA. If we > ever go away from "MUST" RSA, we may have to consider > some extensions for negotiation. I don't quite understand this. If all you have is a HIT, you can't do anything else but use the algorithm associated with the HIT. If you don't know the key type of the HI from which the remote HIT was generated from, you can always test. You'll get the key in an R1. If you get a HI that you can't handle, you have no other option but trying another HIT. So, as far as I can see, there is no need for a negotiation. The problematic case is the opportunistic mode, but for that we outlined the interoperability requirements. --Pekka From petri.jokela@nomadiclab.com Thu Oct 21 02:25:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Thu Oct 21 01:25:00 2004 Subject: [Hipsec] Base draft - 01-pre2 In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> Message-ID: <417757F0.8020303@nomadiclab.com> Thanks for the fixes! Henderson, Thomas R wrote: > Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try to interoperate these packets. Can we pick some values now? How about 10 and 11? /petri From miika@iki.fi Thu Oct 21 02:48:01 2004 From: miika@iki.fi (Miika Komu) Date: Thu Oct 21 01:48:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <41756725.1060002@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> Message-ID: On Tue, 19 Oct 2004, Jari Arkko wrote: > Just one comment: > > > In the light of these performance estimation figures, I still prefer the > > DSA because it is more friendly for the responders (i.e. busy servers) in > > the case where R1s are created on-the-fly; this is also coherent with the > > I think the precreated R1 case is the default assumption, > and should be at any rate if performance is a concern. > So I'd like us to consider that situation as our primary > problem. If I understood your numbers right, there was a > minor increase dsa->rsa for responders in this case and > a bigger decrease dsa->rsa for initiators. Based on this, > RSA appears better from my point of view, though certainly > not quite as much as I initially thought. Using RSA as the default algorithm makes dynamically created R1s less appealing from a performance point of view. In a way, this limits the way implementations will be done in the real world. I have understood that most of the current (research prototype) implementations create R1s on-the-fly rather than off-the-shelf. The reason for this is that the precreated R1s are tricky due to numerous variables involved. Introducing the rendezvous server does not help either; it introduces new permutations, and increases the complexity of precreated R1s. But may be this a problem that needs to be solved separately from the DSA/RSA matter. Other than that, I am fine with the change to RSA. I just want us to do it with an understandment of the little trade-offs involved. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From jari.arkko@piuha.net Thu Oct 21 02:59:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu Oct 21 01:59:01 2004 Subject: Difficulty of off-the-shelf R1s (Was: Re: [Hipsec] Digital Signature Algorithms) In-Reply-To: References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> Message-ID: <4177600A.6010509@piuha.net> Miika Komu wrote: > I have understood that most of the current (research prototype) > implementations create R1s on-the-fly rather than off-the-shelf. The > reason for this is that the precreated R1s are tricky due to numerous > variables involved. Just for my education, can you elaborate a bit more about these problems? --Jari From miika@iki.fi Thu Oct 21 03:28:00 2004 From: miika@iki.fi (Miika Komu) Date: Thu Oct 21 02:28:00 2004 Subject: Difficulty of off-the-shelf R1s (Was: Re: [Hipsec] Digital Signature Algorithms) In-Reply-To: <4177600A.6010509@piuha.net> References: <200410071521.16054.julien.laganier@sun.com> <200410121858.38644.julien.laganier@sun.com> <6AA91027-1CDD-11D9-97E8-000D9331AFB0@nomadiclab.com> <200410131742.54278.julien.laganier@sun.com> <416D566A.4070909@piuha.net> <4173A99D.6000303@nomadiclab.com> <41756725.1060002@piuha.net> <4177600A.6010509@piuha.net> Message-ID: On Thu, 21 Oct 2004, Jari Arkko wrote: > Miika Komu wrote: > > > I have understood that most of the current (research prototype) > > implementations create R1s on-the-fly rather than off-the-shelf. The > > reason for this is that the precreated R1s are tricky due to numerous > > variables involved. > > Just for my education, can you elaborate a bit more about > these problems? http://honor.trusecure.com/pipermail/hipsec/2004-June/000789.html (especially the third message in the thread) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Thu Oct 21 11:06:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 21 10:06:01 2004 Subject: [Hipsec] Base draft - 01-pre2 In-Reply-To: <417757F0.8020303@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04522797@xch-nw-27.nw.nos.boeing.com> <417757F0.8020303@nomadiclab.com> Message-ID: <0FD6414C-2374-11D9-B6FB-000D9331AFB0@nomadiclab.com> >> Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it tough to try >> to interoperate these packets. Can we pick some values now? > > How about 10 and 11? I would suggest the following values, and also reordering Sections 7 and 8 to reflect the same logic. I1 1 R1 2 I2 3 R2 4 CER 5 UPDATE 6 NOTIFY 7 CLOSE 8 CACK 9 BOS --remove-- (should be an extension, separate document) PAYLOAD --remove-- (should be an extension, separate document) I do see some strange beauty in the above series, but that is minor. If people prefer to retain existing packet types, I don't have anything against it. 10 and 11 are fine. --Pekka From thomas.r.henderson@boeing.com Thu Oct 21 12:09:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 21 11:09:00 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Wednesday, October 20, 2004 10:43 PM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > Tom, >=20 > > I am not worried about negotiation or evolving this > > for now, but it seems difficult, if only HITs are known > > before the handshake, to use anything but RSA. If we > > ever go away from "MUST" RSA, we may have to consider > > some extensions for negotiation. >=20 > I don't quite understand this. If all you have is a HIT, > you can't do anything else but use the algorithm associated > with the HIT. If you don't know the key type of the HI > from which the remote HIT was generated from, you can always > test. You'll get the key in an R1. If you get a HI that > you can't handle, you have no other option but trying another > HIT. So, as far as I can see, there is no need for a negotiation. Yes, I agree with this. If an initiator wants to talk HIP with this responder, it has no other choice than to send opportunistic I1, and hope that the R1 comes from the same machine (maybe there might be some way to securely establish linkage between this RSA HI and the first HIT, specified in some future extension). >=20 > The problematic case is the opportunistic mode, but for that > we outlined the interoperability requirements. >=20 My only point on that outline was that, unless there was some=20 negotiation extension, it would be difficult to move away from=20 DSA or RSA in opportunistic mode in the future, while maintaining backward compatibility. Maybe this is obvious, but I was just=20 pointing out the implication. I don't think we need more complexity than what you proposed. Tom From thomas.r.henderson@boeing.com Thu Oct 21 12:42:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 21 11:42:01 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608CA@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Wednesday, October 20, 2004 11:57 PM > To: Jari Arkko > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms > Using RSA as the default algorithm makes dynamically created R1s less > appealing from a performance point of view. In a way, this=20 > limits the way > implementations will be done in the real world. I am not convinced that the above is true. The tradeoff seems to=20 be about a factor of two in sign performance in software=20 implementations, but some cycles will be recouped by faster verification, and in hardware, it might be a wash (e.g., http://www.safenet-inc.com/Library/3/SafeXcel-1741_ProductBrief.pdf). Tom From thomas.r.henderson@boeing.com Thu Oct 21 12:44:00 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 21 11:44:00 2004 Subject: [Hipsec] Base draft - 01-pre2 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452279F@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, October 21, 2004 8:16 AM > To: Petri Jokela > Cc: Henderson, Thomas R; hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Base draft - 01-pre2 >=20 >=20 > >> Why is CLOSE/CLOSE_ACK Packet Type value TBD? Makes it=20 > tough to try=20 > >> to interoperate these packets. Can we pick some values now? > > > > How about 10 and 11? >=20 > I would suggest the following values, and also reordering > Sections 7 and 8 to reflect the same logic. >=20 > I1 1 > R1 2 > I2 3 > R2 4 > CER 5 > UPDATE 6 > NOTIFY 7 > CLOSE 8 > CACK 9 > BOS --remove-- (should be an extension, separate=20 > document) > PAYLOAD --remove-- (should be an extension, separate document) >=20 I agree with the above renumbering and dropping BOS and PAYLOAD for now. Tom=20 From pekka.nikander@nomadiclab.com Thu Oct 21 13:26:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Thu Oct 21 12:26:01 2004 Subject: [Hipsec] Digital Signature Algorithms In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C040608C9@xch-nw-27.nw.nos.boeing.com> Message-ID: > My only point on that outline was that, unless there was some > negotiation extension, it would be difficult to move away from > DSA or RSA in opportunistic mode in the future, while maintaining > backward compatibility. Maybe this is obvious, but I was just > pointing out the implication. I see. But, if we need to move away from DSA or RSA for security reasons, I'm afraid that we can't maintain backward compatibility. Independent of what kind of a negotiation mechanism you would have, you would be vulnerable to bidding-down attacks. Maybe we should add a paragraph to the security considerations section: If an initiator wants to use opportunistic mode, it is vulnerable to man-in-the-middle attacks. Furthermore, the available HI types are limited to the MUST implement algorithms, as per . Hence, if a future specification deprecates the current MUST implement algorithm(s) and replaces it (them) with some new one(s), backward compatibility cannot be preserved. However, given the generally insecure nature of the opportunistic mode, this is not considered to be a serious problem. Or something like that? The above text is slightly vague, but I'm just too tired right now to provide a better one. Any takers? > I don't think we need more complexity than what you proposed. Good. --Pekka From thomas.r.henderson@boeing.com Thu Oct 21 14:12:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Thu Oct 21 13:12:01 2004 Subject: [Hipsec] Digital Signature Algorithms Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C040608CB@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, October 21, 2004 10:36 AM > To: Henderson, Thomas R > Cc: hipsec@honor.trusecure.com > Subject: Re: [Hipsec] Digital Signature Algorithms >=20 >=20 > > My only point on that outline was that, unless there was some > > negotiation extension, it would be difficult to move away from > > DSA or RSA in opportunistic mode in the future, while maintaining > > backward compatibility. Maybe this is obvious, but I was just > > pointing out the implication. >=20 > I see. But, if we need to move away from DSA or RSA for > security reasons, I'm afraid that we can't maintain backward > compatibility. Independent of what kind of a negotiation > mechanism you would have, you would be vulnerable to > bidding-down attacks. good point. >=20 > Maybe we should add a paragraph to the security considerations > section: >=20 > If an initiator wants to use opportunistic mode, it is > vulnerable to man-in-the-middle attacks. Furthermore, > the available HI types are limited to the MUST implement > algorithms, as per . Hence, if a future > specification deprecates the current MUST implement algorithm(s) > and replaces it (them) with some new one(s), backward=20 > compatibility > cannot be preserved. However, given the generally insecure > nature of the opportunistic mode, this is not considered to > be a serious problem. >=20 I would delete the last sentence (opportunistic is not "generally insecure" although it has a specific security vulnerability),=20 otherwise I would support adding that paragraph. Tom =20 From petri.jokela@nomadiclab.com Fri Oct 22 04:51:01 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Fri Oct 22 03:51:01 2004 Subject: [Hipsec] HIP base draft 01 - preliminary version 3 Message-ID: <4178CBB8.7010202@nomadiclab.com> Hello everyone, I uploaded base draft 01 pre3 version to our server. Thanks to Julien for his efforts on these editions. The deadline for submitting 01 draft is on Monday, so I will make last editions before the deadline and after that submit the 01 version. (Sorry, it was not purpose to generate work for you for the weekend, but... :-) http://hip4inter.net/drafts.php Some comments: - New state picture. - HIP packet numbering changed (payload, bos removed and close, close_ack added) - One paragraph added in Security Considerations. Issue #44: SIGMA An additional HMAC in I2 and changed HMAC in R2. The HMAC in R2 covers, in addition to the packet, the HOST_ID of the Responder. I changed this type now to HMAC_2. Are the changes ok, or are there errors: o SIGMA vs. current HIP o packet definitions o packet handling o ... Issue #47: DSA/RSA The RSA is now defined as MUST, DSA as RECOMMENDED. Issue #46: HIT 126 vs. 128 bits Text edited. Issue #48: PAYLOAD + BOS PAYLOAD and BOS packets were removed from the draft (as proposed by Pekka). Left for future drafts. Any comments on this? Text still missing / open things: 1) There was discussion about the D-H usage. Shall we edit the base spec text related to this? Base spec (Miika 11.10): "The Diffie-Hellman value is ephemeral, but can be reused over a number of connections. In fact, as a defense against I1 storms, an implementation MAY use the same Diffie-Hellman value for a period of time, for example, 15 minutes." Pekka in one of his mails (11.10.2004): "Well, my understanding has been that you shouldn't reuse your DH-key, ever. (Maybe the docs don't say that.)" 2) Random value: text still to be added to base spec Yogesh (20.9.2004) o In the draft it's important to say that the responder should keep the random value r for at least 2*MSL (and possibly longer) from the last time it sent message 2. In case Message 3 arrives after 2*MSL, and no random number r can be found, it should be dropped and an ICMP message should be sent. If the Initiator receives an ICMP after sending message-3, it should not assume that the responder sent the message, and should not close that session. An Initiator MAY however start with a new parallel I1 with a new nonce value. From Julien.Laganier@Sun.COM Fri Oct 22 11:02:52 2004 From: Julien.Laganier@Sun.COM (Julien Laganier) Date: Fri Oct 22 10:02:52 2004 Subject: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) In-Reply-To: <200410151408.04279.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> Message-ID: <200410221628.40425.julien.laganier@sun.com> On Friday 15 October 2004 14:08, Julien Laganier wrote: > Folks, > > About the DSA vs RSA issue, here's an excerpt of a CFRG email > mentionning an opinion about what algorithm should be used in > existing, and new protocol/applications. > > --julien BTW, I=A0just thought about having as mandatory encryption algorithm=20 "AES-CBC with HMAC-SHA1" instead of "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? =2D-julien > ---------- Forwarded Message ---------- > > Subject: RE: [Cfrg] Re: [saag] Bad day at the hash function factory > Date: Thursday 26 August 2004 19:32 > From: "Hallam-Baker, Phillip" > To: "'Steven M. Bellovin'" , "Hughes, James > P" > Cc: "'saag@mit.edu'" , "'cfrg@ietf.org'" > , "'kent@bbn.com'" > > I think that we should track status of crypto algs independently of > their standards status. In particular I think that we should > distinguish between Recommended and Acceptable status. > > New applications should specify algorithms with Recommended status > Continued use of algorithms with Acceptable status should not raise > concern. > > > So I would classify as follows: > > Proposed: SHA-2 > Recommended: SHA-1, HMAC-SHA1, RSA-2048, RSA-4096, AES, DH-1024 > Acceptable: HMAC-MD5, RSA-1024, 3DES, DSA, DH-512, RC4 > Depricated: IDEA, RSA1024+MD5 > Obsolete: MD4, MD5, RSA-512, DES > > The reason that I distinguish between Depricated and obsolete is > that there are uses of RSA signatures with MD5 hash that are still > acceptably secure and the applications concerned do not support > SHA1. The reason I put DSA as acceptable rather than recommended is > that it does need a good random seed, the key size is small and it > is unlikely at this point to see much use. > > RC4 has been compromised by Shamir & co, but as a general rule I > don't think any stream cipher should ever get a higher status than > acceptable. A stream cipher always allows a person who has a > plaintext and ciphertext corresponding to a key to encode or > decode all messages with that key that are shorter or the same > size. In effect all stream ciphers are vulnerable to a trivial form > of known plaintext attack, the attack does not reveal the key but > this is not necessary. > > I do not feel confident in recommending moving to SHA2 at this > point. Before jumping I want to see that the place we are going to > is better than where we left. SHA2 is not currently widely used. If > it turns out that the recent cryptanalysis of SHA1 is also > applicable to the structures used in SHA2 then the rationale for a > change is lost. I would feel happier moving to a hash function > based on AES encryption (which i had eroneously assumed had been > the point of the SHA2 work). > _______________________________________________ > Hipsec mailing list > Hipsec@honor.trusecure.com > http://honor.trusecure.com/mailman/listinfo/hipsec =2D-=20 Julien Laganier=20 SUN Microsystems Laboratories "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian W. Kernighan *NOTICE*: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. From jari.arkko@piuha.net Fri Oct 22 11:57:01 2004 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri Oct 22 10:57:01 2004 Subject: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) In-Reply-To: <200410221628.40425.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> <200410221628.40425.julien.laganier@sun.com> Message-ID: <41792F86.9040500@piuha.net> Julien Laganier wrote: > BTW, I just thought about having as mandatory encryption algorithm > "AES-CBC with HMAC-SHA1" instead of > "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? Yes. --Jari From pekka.nikander@nomadiclab.com Fri Oct 22 12:11:00 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Oct 22 11:11:00 2004 Subject: [Hipsec] Encryption Transform (Was: Digital Signature Algorithms) In-Reply-To: <200410221628.40425.julien.laganier@sun.com> References: <200410071521.16054.julien.laganier@sun.com> <200410131742.54278.julien.laganier@sun.com> <200410151408.04279.julien.laganier@sun.com> <200410221628.40425.julien.laganier@sun.com> Message-ID: <3A3C8F30-2446-11D9-B6FB-000D9331AFB0@nomadiclab.com> > BTW, I=A0just thought about having as mandatory encryption algorithm > "AES-CBC with HMAC-SHA1" instead of > "3DES-CBC with HMAC-SHA1". Do you guys think it's worth? Ok to me. --Pekka From petri.jokela@nomadiclab.com Mon Oct 25 08:05:00 2004 From: petri.jokela@nomadiclab.com (Petri Jokela) Date: Mon Oct 25 07:05:00 2004 Subject: [Hipsec] Base draft -01 submitted Message-ID: <417CED96.6050407@nomadiclab.com> Hello folks, I submitted the base draft version -01 to IETF. The draft and diffs to previous versions can be found from: http://hip4inter.net/drafts.php I made the proposed change from mandatory 3DES to AES (key length 128 bits). This issue is still open for comments and discussion. /Petri From miika@iki.fi Mon Oct 25 09:12:01 2004 From: miika@iki.fi (Miika Komu) Date: Mon Oct 25 08:12:01 2004 Subject: [Hipsec] SIGMA and ECHO_REQUEST/REPLY in base-01 In-Reply-To: <417CED96.6050407@nomadiclab.com> References: <417CED96.6050407@nomadiclab.com> Message-ID: There may be a slight problem with SIGMA compliancy in base-01. I think the ECHO_REQUEST/REPLY must be mandatory, or otherwise the base exchange is not SIGMA compliant. The SIGMA papers states (page 18, first paragraph) that the messages should carry either a fresh nonce (i.e. ECHO_REQUEST/REPLY), or the peer DH should be included in the signature. As the latter is not true in the base exchange, we need to make the former mandatory. (Also, the ECHO needs to be included in the signature.) However, I don't think that we need to have a two-way ECHO (i.e. the initiator send its own echo) if we intepret HIP as SIGMA-I with the peer awareness property (= R2 packet). On the figure on page 19 in the SIGMA paper, we can subsitute g^x in the second packet with ECHO_REQUEST and g^y in the third packet with ECHO_REPLY in SIGMA-I. Agree? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From pekka.nikander@nomadiclab.com Mon Oct 25 10:50:01 2004 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Mon Oct 25 09:50:01 2004 Subject: [Hipsec] Re: HIP base draft 01 - preliminary version 3 In-Reply-To: <4178CBB8.7010202@nomadiclab.com> References: <4178CBB8.7010202@nomadiclab.com> Message-ID: <9101DB2E-2696-11D9-AFFD-000D9331AFB0@nomadiclab.com> Some comments on base-01-pre3. I'm late, I know, and these probably won't make it to -01, but maybe then to -02. --Pekka More substantial: - Rename the REKEYING state into a more generic one, like UPDATE pending or UPDATING or something? - HMAC_2 description must be fixed. Here is my initial proposal 160 low order bits of the HMAC computed over a given set of data, which includes some data that is NOT in the packet that carries this payload. The exact contents is defined case-by-case; see the relevant packet description. - The HMAC_2 calculation in 7.4 is too vague. It needs to have a picture of what to hash etc. - We need a proper IANA Considerations section. - Remove Appendix E. This needs to be a separate specification. More editorial: - Section 5.4 seems to be slightly out of date. The state machine has grown into fairly complex, contrary to the claims in this section. - In 5.4.2, there is strange cross reference to Sec 6.3 in the HTML version - Same for 6.2.9. An idea: would it be better to move to a table presentation, or to include an appendix that gives a table with states as rows and incoming messsages as columns. There are now nine packets and nine states, so the table has 81 cells altogether. However, in many cases the response is identical for a number of messages or number of states, and therefore quite a number of the cells actual merge. - In 5.4.3 (state diagram), remove the phrase "and NES received", as it does not need to be there. That makes UPDATE more generic update mechanism, not NES specific. - the cases where the arcs cross each other are closing, as the diagram uses the same symbol for crossing arcs (+) and arc turns/joins. I think a crossing arc should be just a vertical bar, giving the visual image that the horisontal arc goes beneath the vertical one. - In 6.2.7, I think that the sentence "The OAKLEY well known group 5 is the same as the 1536-bit MODP group." is no longer needed and confusing - In order not the have to rewrite all "Valid Control Bits" text in Section 7, it may be better to make SHT and RHT not to be part of Controls? Or just update the various places in Section 7. - Move 8.12 (CER) after 8.8 (R2) - Move 8.9 (dropping) before 8.14 (CLOSE), and update it accordingly currently the text is not in line with the close mechanism From miika@iki.fi Tue Oct 26 01:49:01 2004 From: miika@iki.fi (Miika Komu) Date: Tue Oct 26 00:49:01 2004 Subject: [Hipsec] SIGMA and ECHO_REQUEST/REPLY in base-01 In-Reply-To: References: <417CED96.6050407@nomadiclab.com> Message-ID: On Mon, 25 Oct 2004, Miika Komu wrote: > There may be a slight problem with SIGMA compliancy in base-01. I think > the ECHO_REQUEST/REPLY must be mandatory, or otherwise the base exchange > is not SIGMA compliant. (Forget this - this wasn't true. I should not post messages when I am tired ;) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From Internet-Drafts@ietf.org Thu Oct 28 10:32:01 2004 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu Oct 28 09:32:01 2004 Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-01.txt Message-ID: <200410281441.KAA18682@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-01.txt Pages : 104 Date : 2004-10-27 This memo specifies the details of the Host Identity Protocol (HIP). The overall description of protocol and the underlying architectural thinking is available in the separate HIP architecture specification. The Host Identity Protocol is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The various forms of the Host Identity, Host Identity Tag (HIT) and Local Scope Identifier (LSI), are covered in detail. It is described how they are used to support authentication and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secured communication channel between the hosts. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many denial-of-service (DoS)attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28105621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28105621.I-D@ietf.org> --OtherAccess-- --NextPart-- From joseph-so@gmx.net Thu Oct 28 10:51:01 2004 From: joseph-so@gmx.net (Joseph) Date: Thu Oct 28 09:51:01 2004 Subject: [Hipsec] What is changed in draft-ietf-hip-base-01? Message-ID: <20041028135011.C7F3E7307@honor.icsalabs.com> This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4BD52.B07804C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, What is different between draft-ietf-hip-base-01 with 00? I cannot find the track of change in this draft. Thanks a lot. Yours faithfully, Joseph ------=_NextPart_000_0000_01C4BD52.B07804C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
    What is=20 different between draft-ietf-hip-base-01 with 00? I cannot find the = track of=20 change in this draft. Thanks a lot.
Yours=20 faithfully,
Joseph
------=_NextPart_000_0000_01C4BD52.B07804C0-- From miika@iki.fi Thu Oct 28 10:58:01 2004 From: miika@iki.fi (Miika Komu) Date: Thu Oct 28 09:58:01 2004 Subject: [Hipsec] What is changed in draft-ietf-hip-base-01? In-Reply-To: <20041028135011.C7F3E7307@honor.icsalabs.com> References: <20041028135011.C7F3E7307@honor.icsalabs.com> Message-ID: On Fri, 29 Oct 2004, Joseph wrote: > Dear All, > What is different between draft-ietf-hip-base-01 with 00? I cannot find > the track of change in this draft. Thanks a lot. > Yours faithfully, http://hip4inter.net/documentation/drafts/diff_00_01.html -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From halestino@ipb.pt Fri Oct 29 18:57:01 2004 From: halestino@ipb.pt (Halestino Pimentel) Date: Fri Oct 29 17:57:01 2004 Subject: [Hipsec] Problem installing patched ipsec-tools-0.3.3 Message-ID: <200410300008.14731.halestino@ipb.pt> Hello, I'm trying to test the Boeing Linux HIP implementation. I compiled a new (patched) kernel and booted from. No problem till here. My problems started when I install ipsec-tools-0.3.3 (patched with ipsec-tools-0.3.3-hip.patch). I issue ./configure --with-openssl=/usr/local/ssl (the directory where I installed openssl-0.9.7a) and get no errors. When I issue make install I get the following: make[2]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src/include-glibc' Making install in libipsec make[2]: Entering directory `/usr/local/src/ipsec-tools-0.3.3/src/libipsec' if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_dump_policy.lo -MD -MP -MF ".deps/ipsec_dump_policy.Tpo" -c -o ipsec_dump_policy.lo ipsec_dump_policy.c; \ then mv -f ".deps/ipsec_dump_policy.Tpo" ".deps/ipsec_dump_policy.Plo"; else rm -f ".deps/ipsec_dump_policy.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_dump_policy.lo -MD -MP -MF .deps/ipsec_dump_policy.Tpo -c ipsec_dump_policy.c -o ipsec_dump_policy.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_get_policylen.lo -MD -MP -MF ".deps/ipsec_get_policylen.Tpo" -c -o ipsec_get_policylen.lo ipsec_get_policylen.c; \ then mv -f ".deps/ipsec_get_policylen.Tpo" ".deps/ipsec_get_policylen.Plo"; else rm -f ".deps/ipsec_get_policylen.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_get_policylen.lo -MD -MP -MF .deps/ipsec_get_policylen.Tpo -c ipsec_get_policylen.c -o ipsec_get_policylen.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_strerror.lo -MD -MP -MF ".deps/ipsec_strerror.Tpo" -c -o ipsec_strerror.lo ipsec_strerror.c; \ then mv -f ".deps/ipsec_strerror.Tpo" ".deps/ipsec_strerror.Plo"; else rm -f ".deps/ipsec_strerror.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT ipsec_strerror.lo -MD -MP -MF .deps/ipsec_strerror.Tpo -c ipsec_strerror.c -o ipsec_strerror.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT key_debug.lo -MD -MP -MF ".deps/key_debug.Tpo" -c -o key_debug.lo key_debug.c; \ then mv -f ".deps/key_debug.Tpo" ".deps/key_debug.Plo"; else rm -f ".deps/key_debug.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT key_debug.lo -MD -MP -MF .deps/key_debug.Tpo -c key_debug.c -o key_debug.o if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT pfkey.lo -MD -MP -MF ".deps/pfkey.Tpo" -c -o pfkey.lo pfkey.c; \ then mv -f ".deps/pfkey.Tpo" ".deps/pfkey.Plo"; else rm -f ".deps/pfkey.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I../.. -include ../../src/include-glibc/glibc-bugs.h -I../../src/include-glibc -I../../src/include-glibc -g -O2 -DINET6 -DIPSEC -DCONFIG_BOEING_HIP -DIPPROTO_HIP=99 -MT pfkey.lo -MD -MP -MF .deps/pfkey.Tpo -c pfkey.c -o pfkey.o pfkey.c: In function `pfkey_send_hip_x1': pfkey.c:1500: error: invalid application of `sizeof' to an incomplete type pfkey.c: In function `pfkey_setsadbhit': pfkey.c:2701: error: invalid application of `sizeof' to an incomplete type pfkey.c:2707: error: dereferencing pointer to incomplete type pfkey.c:2708: error: dereferencing pointer to incomplete type pfkey.c:2708: error: `SADB_EXT_HIT' undeclared (first use in this function) pfkey.c:2708: error: (Each undeclared identifier is reported only once pfkey.c:2708: error: for each function it appears in.) pfkey.c:2709: error: dereferencing pointer to incomplete type make[2]: *** [pfkey.lo] Error 1 make[2]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src/libipsec' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/ipsec-tools-0.3.3/src' make: *** [install-recursive] Error 1 The problem is with a function in directory libipsec. Does anybody knows why this happens? Thanks in advance, Halestino From thomas.r.henderson@boeing.com Fri Oct 29 19:00:01 2004 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Oct 29 18:00:01 2004 Subject: [Hipsec] Problem installing patched ipsec-tools-0.3.3 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0452283E@xch-nw-27.nw.nos.boeing.com> > -----Original Message----- > From: Halestino Pimentel [mailto:halestino@ipb.pt]=20 > Sent: Friday, October 29, 2004 4:08 PM > To: hipsec@honor.trusecure.com > Subject: [Hipsec] Problem installing patched ipsec-tools-0.3.3 >=20 >=20 > Hello, >=20 > I'm trying to test the Boeing Linux HIP implementation. I=20 > compiled a new=20 > (patched) kernel and booted from. No problem till here. > My problems started when I install ipsec-tools-0.3.3 (patched with=20 > ipsec-tools-0.3.3-hip.patch). I issue ./configure=20 > --with-openssl=3D/usr/local/ssl (the directory where I installed=20 > openssl-0.9.7a) and get no errors.=20 Please refer installation problems directly to the implementors = themselves. Thanks, Tom