Subject: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP]

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 02 Apr 2006 19:57:19 +0300

Hi,

we have already gotten the B-R analysis on the main spec.

Cheers,

Gonzalo

-------- Original Message --------
Subject: Fwd: Belovin-Rescorla analysis - HIP
Date: Sat, 01 Apr 2006 17:06:02 -0500
From: Russ Housley <[email-masked]>
To: [email-masked], [email-masked]
CC: [email-masked]

Charlie Kaufman did the security review for HIP.  Please take a look
at his review, and let us know your thoughts.

Russ

>From: Charlie Kaufman <[email-masked]>
>To: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
>CC: "[email-masked]" <[email-masked]>
>Date: Thu, 23 Mar 2006 12:49:35 -0800
>Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP
>
>I read draft-ietf-hip-base-05.txt, draft-ietf-hip-esp-02.txt, 
>draft-ietf-hip-arch-03.txt with a particular eye towards 
>shortcomings with crypto algorithm agility. The HIP design has 
>evolved considerably since I last read it. I can't in good 
>conscience tell you that this is a complete analysis - these 
>documents are primarily about security. HIP today looks a lot like IKEv2.
>
>Issues with crypto agility:
>
>While crypto algorithms are in some cases negotiated, there are 
>several places where use of SHA-1 is "wired in". In one very 
>important case, this would be very hard to fix.
>
>A central idea behind HIP is that a hash of a public key can be used 
>as a host identifier and that identifier can be used in place of an 
>IPv6 address in both internal data structures and in some cases on 
>the wire. Because IPv6 has a fixed address size of 128 bits, the 
>public key hash can be no larger than 128 bits. Because of address 
>allocation issues, the proposed actual size of the hash is 120 bits.
>
>The HIP base document makes a normative reference to 
>draft-laganier-ipv6-khi-01, and that document wires in both use of 
>SHA-1 and the extraction of a particular 120 bits of the SHA-1 hash. 
>Switching to use 120 bits of a SHA-256 hash would not be terribly 
>difficult, but it's not clear that would be any more secure.
>
>There are no real attacks on HIP based on finding collisions, but as 
>with many of these protocols there could be long theoretical 
>discussions about how finding collisions would be interesting. A 
>real attack would depend on the ability to find a second preimage.
>
>There are other places where SHA-1 is wired in with no mechanism for 
>negotiating anything else. None can be exploited given collision 
>attacks. They are:
>
>1) Key expansion: hash is not negotiated - SHA-1 wired in.
>
>2) Puzzles: SHA-1 is certainly "good enough" for puzzles, since any 
>weakness would have to find a first preimage more quickly than 
>computing a small number of hashes.
>
>3) HMAC and encryption algorithms are negotiated, but currently 
>SHA-1 and MD5 are the only registered options. In one place, the 
>size of the output of the HMAC is fixed at 160 bits. This is 
>probably a bug in the spec and easily fixed.
>
>4) When doing signatures, the HASH type is not negotiated but rather 
>is assumed to be determined by the signature algorithm (which is 
>also not negotiated). Each endnode decides the signature and hash 
>algorithms it is going to used and the other endnode can accept it 
>or not. The spec references RFCs 2536 and 3110 to match up signature 
>and hash algorithms. This is probably acceptable.
>
>There are other places where crypto-agility is not all that it might be:
>
>1) There is no negotiation of Diffie-Hellman groups. The responder 
>chooses. This means that if both ends support multiple groups and 
>there is some overlap, the negotiation could still fail if the 
>initiator does not support the responder's default group. As with 
>IKEv1, connections might succeed if initiated from one end but not 
>from the other. If an implementation compensates for this by trying 
>different groups upon retry, the protocol is subject to a downgrade 
>attack where a man-in-the-middle can get the two ends to use a group 
>weaker than one they would both prefer. This would be 
>straightforward (but not trivial) to fix.
>
>2) No key size is negotiated. Use of AES implies use of 128 bit 
>keys. This is not a serious problem - it just means that if support 
>of AES with bigger keys is desired, they must be treated as 
>different encryption algorithms.
>
>3) Fixing the "wired-in" uses of SHA-1 will require a new version 
>number in the protocol, but there is a version downgrade attack. The 
>current spec says that if the version number you get is not 
>supported, you reject it with an unsigned ICMP message. This means 
>two endnodes could likely be tricked by a man-in-the-middle to use 
>the older version of the protocol even if they both support the newer one.
>
>Other Security Concerns (beyond crypto-agility):
>
>Many packets are integrity protected with both an HMAC and a digital 
>signature. This is inefficient because it requires extra public key 
>operations. It is done for the benefit of middle-boxes that don't 
>know the HMAC keys but want to be able to verify the packet contents 
>for updating NAT and firewall configurations. As it stands, the 
>protocol is secure but slow. If the signatures were left out or 
>unverified, certain subtle vulnerabilities are introduced.
>
>There is mandatory support for ESP with HMAC-SHA1 and either Null or 
>AES128CBC encryption. This is mandatory not just in the 
>implementation but also in the configuration. (i.e., as written, the 
>spec says that one of those two suites must be offered in every negotiation).
>
>Assurance that two sessions will always use different session keys 
>is fragile. The keys are derived from the Diffie-Hellman keys and 
>puzzle challenges and responses, all of which can be reused. Perhaps 
>I missed it, but there should probably be more explicit guidance on 
>how to avoid this or explicit nonces should be added.
>
>Around line 1829, the base spec says "All HIP implementations MUST 
>employ a reassembly algorithm that is sufficiently resistant to DoS 
>attacks." This statement is too vague to be useful (and arguably 
>impossible). It should probably be changed to be implementer advice.
>
>Notifications are not acknowledged or protected from replay. Today, 
>notifications are only used for diagnostics, so a third party 
>filtering, duplicating, and reordering them probably can't do 
>substantial damage. It does seem suspicious though.
>
>When doing "opportunistic" HIP negotiation, when node A wants to 
>send to node B and doesn't know whether node B supports HIP, it has 
>three choices: 1) It can hold the first packet to B while it tries 
>to negotiate HIP, and if that fails send the first packet 
>unprotected; 2) It can forward the first packet unprotected and in 
>parallel try to negotiate HIP. If the negotiation succeeds, it can 
>start using the ESP tunnel; or 3) it can not try to negotiate HIP. 
>Each of these mechanisms has problems. The spec should offer some 
>guidance. It's possible this is provided in one of the other HIP documents.
>
>Non-security concerns:
>
>Use of Extended Sequence Numbers is not negotiated; either end can 
>mandate it. If all endpoints are required to support ESNs, it would 
>be simpler to just mandate their use all the time. If not, the 
>negotiation should allow one end to propose their use and the other 
>to accept it.
>
>         --Charlie

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Petri Jokela <[email-masked]>
Date: Thu, 06 Apr 2006 10:18:43 +0300

Hello everyone,

Thanks Charlie for the analysis!

Comments, questions, and possible actions in-line. Those issues that do 
not cause any actions should be described in the draft (Security 
considerations).

>> difficult, but it's not clear that would be any more secure.

The only way to solve this issue is to modify the ORCHID (KHI) draft. 
There is nothing we can do in the HIP base draft; we need those HITs 
defined somewhere.

>> discussions about how finding collisions would be interesting. A real 
>> attack would depend on the ability to find a second preimage.
>>

This could be changed to contain a non-fixed algorithm, possibly in a
similar way as in puzzle where the algorithm is defined to be the same
that is used in Responder's HIT generation.

>> computing a small number of hashes.

Ok.

>> 3) HMAC and encryption algorithms are negotiated, but currently SHA-1 
>> and MD5 are the only registered options. In one place, the size of the 
>> output of the HMAC is fixed at 160 bits. This is probably a bug in the 
>> spec and easily fixed.

I assume that this comment refers to the HMAC and HMAC_2 parameters. The 
160 limit comes from the HMAC RFC 2104 (reference missing from the 
draft) and the length for HMAC is 160 bits. The current
specification could work also with other algorithms, but in the HMAC 
field only the low-order 160 bits of the HMAC calculation are included.

This should be changed to a variable length field with the length
depending on the used hash algorithm.

>> is assumed to be determined by the signature algorithm (which is also 
>> not negotiated). Each endnode decides the signature and hash 
>> algorithms it is going to used and the other endnode can accept it or 
>> not. The spec references RFCs 2536 and 3110 to match up signature and 
>> hash algorithms. This is probably acceptable.

So this seems to be ok.

>> weaker than one they would both prefer. This would be straightforward 
>> (but not trivial) to fix.

This issue has been discussed earlier in the HIPSEC list (Dec. 2003).
The conclusion (at that time) was to use two mandatory Groups and rest
were defined as "SHOULD be implemented". Negotiation was discussed,
but never adopted; R1 would have contained for example two different DHs.

The current system is slightly weird: when the responder sends the 
(only) DH proposal, the initiator cannot have anything to say to that, 
except to accept or deny it. Especially when the initiator is a slow 
PDA, supporting only weak encryption, and the server offers something 
else the connection can never be established even the server might be 
willing to do that with lower security. But if it supports these PDAs, 
it must always send the weak group in the R1, and nobody can get better 
security when talking to the server. ( Was this confusing enough :-)

Link to the old discussion:
http://honor.trusecure.com/pipermail/hipsec/2003-December.txt.gz

Should we allow the server to send max two D-H groups in one 
DIFFIE_HELLMAN TLV, or shall we be happy with the current system, where 
almost all connections can be set up?

>> 2) No key size is negotiated. Use of AES implies use of 128 bit keys. 
>> This is not a serious problem - it just means that if support of AES 
>> with bigger keys is desired, they must be treated as different 
>> encryption algorithms.

No actions(?)

>> current spec says that if the version number you get is not supported, 
>> you reject it with an unsigned ICMP message. This means two endnodes 
>> could likely be tricked by a man-in-the-middle to use the older 
>> version of the protocol even if they both support the newer one.

Shall we leave these as a headache for the HIP v2 designers?

>> operations. It is done for the benefit of middle-boxes that don't know 
>> the HMAC keys but want to be able to verify the packet contents for 
>> updating NAT and firewall configurations. As it stands, the protocol 
>> is secure but slow. If the signatures were left out or unverified, 
>> certain subtle vulnerabilities are introduced.

Speeding up things and changing these issues would require a lot of
work. (Maybe something for HIP v2 ?)

>> AES128CBC encryption. This is mandatory not just in the implementation 
>> but also in the configuration. (i.e., as written, the spec says that 
>> one of those two suites must be offered in every negotiation).

The reason for this was that we would have something common between all 
nodes.

>> Assurance that two sessions will always use different session keys is 
>> fragile. The keys are derived from the Diffie-Hellman keys and puzzle 
>> challenges and responses, all of which can be reused. Perhaps I missed 
>> it, but there should probably be more explicit guidance on how to 
>> avoid this or explicit nonces should be added.

If we change some value in each of the R1s, we need to recalculate
R1s when we send them out. This opens some DoS attack possibilities. It 
means also that we lose the advantage of pre-generating R1 messages.

Currently there is a requirement that puzzles must be re-calculated
every few minutes (one possible way to implement is described in
Appendix A). The problem would exist only when two hosts negotiate the
association, close it, and renegotiate it within the time when the set 
of pre-generated R1s is valid.

>> impossible). It should probably be changed to be implementer advice.

Ok.

>> substantial damage. It does seem suspicious though.

At the minimum, we could add a warning that NOTIFY messages are not 
trustworthy.

>> When doing "opportunistic" HIP negotiation, when node A wants to send 
>> to node B and doesn't know whether node B supports HIP, it has three 
>> choices: 1) It can hold the first packet to B while it tries to 
>> negotiate HIP, and if that fails send the first packet unprotected; 2) 
>> It can forward the first packet unprotected and in parallel try to 
>> negotiate HIP. If the negotiation succeeds, it can start using the ESP 
>> tunnel; or 3) it can not try to negotiate HIP. Each of these 
>> mechanisms has problems. The spec should offer some guidance. It's 
>> possible this is provided in one of the other HIP documents.

Maybe a recommendation:

6.6. Initiating a HIP connection

The host should try to establish an opportunistic mode HIP association 
sending at most I1_RETRIES_MAX I1 packets. If it does not receive any 
R1s, it can try to initiate the  connection without HIP if local policy 
allows.

>> mandate it. If all endpoints are required to support ESNs, it would be 
>> simpler to just mandate their use all the time. If not, the 
>> negotiation should allow one end to propose their use and the other to 
>> accept it.

What do people think? Should we go for mandatory 64-bit sequence numbers
directly, or is there some advantage of staying at 32?

/petri

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 6 Apr 2006 20:13:54 +1200

On 06/04/2006, at 7:18 PM, Petri Jokela wrote:

> Comments, questions, and possible actions in-line. Those issues  
> that do not cause any actions should be described in the draft  
> (Security considerations).

I have a few further comments inline.

>>> Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP

<big snip>

>>> 1) There is no negotiation of Diffie-Hellman groups. The  
>>> responder chooses. This means that if both ends support multiple  
>>> groups and there is some overlap, the negotiation could still  
>>> fail if the initiator does not support the responder's default  
>>> group. As with IKEv1, connections might succeed if initiated from  
>>> one end but not from the other. If an implementation compensates  
>>> for this by trying different groups upon retry, the protocol is  
>>> subject to a downgrade attack where a man-in-the-middle can get  
>>> the two ends to use a group weaker than one they would both  
>>> prefer. This would be straightforward (but not trivial) to fix.
>

We implemented this at one stage before the big packet format  
change... IIRC it worked fine.  I think it should be resurrected.

<snip>

>>> keys. This is not a serious problem - it just means that if  
>>> support of AES with bigger keys is desired, they must be treated  
>>> as different encryption algorithms.
>
> No actions(?)

Just define the code points for them.

>>> number in the protocol, but there is a version downgrade attack.  
>>> The current spec says that if the version number you get is not  
>>> supported, you reject it with an unsigned ICMP message. This  
>>> means two endnodes could likely be tricked by a man-in-the-middle  
>>> to use the older version of the protocol even if they both  
>>> support the newer one.
>

I think we should fix this one.

>>> Many packets are integrity protected with both an HMAC and a  
>>> digital signature. This is inefficient because it requires extra  
>>> public key operations. It is done for the benefit of middle-boxes  
>>> that don't know the HMAC keys but want to be able to verify the  
>>> packet contents for updating NAT and firewall configurations. As  
>>> it stands, the protocol is secure but slow. If the signatures  
>>> were left out or unverified, certain subtle vulnerabilities are  
>>> introduced.
>

This is HIP v2 material, I think.

>
>>> There is mandatory support for ESP with HMAC-SHA1 and either Null  
>>> or AES128CBC encryption. This is mandatory not just in the  
>>> implementation but also in the configuration. (i.e., as written,  
>>> the spec says that one of those two suites must be offered in  
>>> every negotiation).
>
> The reason for this was that we would have something common between  
> all nodes.

But Null should not be mandatory to offer.  AES128CBC would do as a  
mandatory-to-offer.

<snip>

>>> send to node B and doesn't know whether node B supports HIP, it  
>>> has three choices: 1) It can hold the first packet to B while it  
>>> tries to negotiate HIP, and if that fails send the first packet  
>>> unprotected; 2) It can forward the first packet unprotected and  
>>> in parallel try to negotiate HIP. If the negotiation succeeds, it  
>>> can start using the ESP tunnel; or 3) it can not try to negotiate  
>>> HIP. Each of these mechanisms has problems. The spec should offer  
>>> some guidance. It's possible this is provided in one of the other  
>>> HIP documents.
>
> Maybe a recommendation:
>
> The host should try to establish an opportunistic mode HIP  
> association sending at most I1_RETRIES_MAX I1 packets. If it does  
> not receive any R1s, it can try to initiate the  connection without  
> HIP if local policy allows.

And use option 1 in the meantime.  2 has many problems, because  
migrating a non-HIP connection to HIP is probably hard to implement.

>
>>> Non-security concerns:
>>>
>>> Use of Extended Sequence Numbers is not negotiated; either end  
>>> can mandate it. If all endpoints are required to support ESNs, it  
>>> would be simpler to just mandate their use all the time. If not,  
>>> the negotiation should allow one end to propose their use and the  
>>> other to accept it.
>

Go straight to 64.

Andrew

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:29:06 +0300

>>>> 3) Fixing the "wired-in" uses of SHA-1 will require a new  
>>>> version number in the protocol, but there is a version downgrade  
>>>> attack. The current spec says that if the version number you get  
>>>> is not supported, you reject it with an unsigned ICMP message.  
>>>> This means two endnodes could likely be tricked by a man-in-the- 
>>>> middle to use the older version of the protocol even if they  
>>>> both support the newer one.
>>

I agree.

And I think we already decided to fix this by replacing all  
references to SHA-1 with a reference to the HIT hash algorithm.  HIT  
hash algorithm, OTOH, is currently being defined by the KHI prefix.   
Changing the algorithm requires changing the prefix; that is clearly  
defined in the Security Considerations part of the KHI draft.

The rationale here was that in non-opportunistic HIP the initiator  
can choose among the responder's HITs (if there are many), and  
thereby choose which hash algorithm to use, usually choosing the  
strongest one.  A counter argument would be that opportunistic HIP  
might have problems.  OTOH, in opportunistic HIP the responder could  
choose its HIT based on the Initiator's HIT if it recognises the  
prefix in the Initiator's HIT.  If it doesn't, it could use still use  
SHA-1.  That wouldn't most probably matter that much as opportunistic  
HIP is always vulnerable to man-in-the-middle attacks.

Looking at -05, always referring to the HIT hash algorithm hasn't  
been implemented.  Unfortunately I don't remember how we weighted the  
arguments and counter-arguments.  Maybe this is just an issue that  
has slipped through in the editing process?

My intention here was, IIRC, to refer to the HIT hash algorithm  
everywhere, but maybe in the puzzle.  The puzzle could still remain  
using PHASH, which would be, for now, SHA-1.  OTOH, for consistency's  
sake we should edit the document to refer to PHASH everywhere, and  
mention SHA-1 only in the definition of PHASH.  (Most of that has  
apparently been done but at least Para #1 in 4.1.2 and Para #2 in 6.3  
still refer to SHA-1.)

One more point is what to use for keymat generation.  My choice would  
be HIT hash algorithm, not SHA-1.

As a detail here, looking at 6.9 Point #7 we may have an  
inconsistency.  There we refer to the HIT hash algorithm in verifying  
the puzzle, not PHASH.  So, I become puzzled of what we really decided.

[Side note: KHI draft title has been changed; Petri please update  
Para #2 in Section 3.1]

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:41:25 +0300

>>>> can mandate it. If all endpoints are required to support ESNs,  
>>>> it would be simpler to just mandate their use all the time. If  
>>>> not, the negotiation should allow one end to propose their use  
>>>> and the other to accept it.
>>

I agree with Andrew.  Let's just go to 64.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:11:59 +0300

[Creating separate threads for separate issues.]

>>>> group. As with IKEv1, connections might succeed if initiated  
>>>> from one end but not from the other. If an implementation  
>>>> compensates for this by trying different groups upon retry, the  
>>>> protocol is subject to a downgrade attack where a man-in-the- 
>>>> middle can get the two ends to use a group weaker than one they  
>>>> would both prefer. This would be straightforward (but not  
>>>> trivial) to fix.
>>

IIRC, one of the reasons why we left this (and other similar  
negotiations) out was simplicity.  Back at that time, we (or at least  
I :-) wanted to keep the protocol simple to implement and understand.

What comes to downgrade attacks, IIRC the argumentation was that a  
man-in-the-middle that is sufficiently strong to launch such a  
downgrade attack can also launch a full DoS, which was considered  
worse.  OTOH, there may be scenarios where downgrade might be  
considered worse than DoS.

So, IMHO, if someone (Andrew?) cares to write text, we could consider  
including it.

Would simply including multiple D-H payloads in R1 do?  In that case  
the Initiator could choose instead of the Responder?  That would  
require more work from the Responder (keeping pools of multiple types  
D-H keys instead of just one pool), but AFAICS would be fairly simple  
at the Initiator end.  Or am I missing something?

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:39:48 +0300

>>>> There is mandatory support for ESP with HMAC-SHA1 and either  
>>>> Null or AES128CBC encryption. This is mandatory not just in the  
>> The reason for this was that we would have something common  
>> between all nodes.
>

I don't understand this comment.  Maybe the text is unclear (Section  
5.2.7 I think), but AFAICS it just requires that the responder  
includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC.   
Nothing prevents it from including both and perhaps others.

If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- 
SHA1-NULL.

What is wrong with this?  To me this approach seems to be fine with  
me; not all connections require encryption.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:39:29 +0300

>>>> in parallel try to negotiate HIP. If the negotiation succeeds,  
>>>> it can start using the ESP tunnel; or 3) it can not try to  
>>>> negotiate HIP. Each of these mechanisms has problems. The spec  
>>>> should offer some guidance. It's possible this is provided in  
>>>> one of the other HIP documents.
>>
>> Maybe a recommendation:
>>
>> not receive any R1s, it can try to initiate the  connection  
>> without HIP if local policy allows.
>

I would be tempted to make it explicit that this document does not  
define how to do opportunistic HIP but simply provides hooks for it,  
a full definition being expected to be available in some future  
document.

Opinions?

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:39:48 +0300

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 10:39:29 +0300

Opinions?

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 12:48:37 +0300

>>> The HIP base document makes a normative reference to draft- 
>>> laganier-ipv6-khi-01, and that document wires in both use of  
>>> SHA-1 and the extraction of a particular 120 bits of the SHA-1  
>>> hash. Switching to use 120 bits of a SHA-256 hash would not be  
>>> terribly difficult, but it's not clear that would be any more  
>>> secure.
>
> The only way to solve this issue is to modify the ORCHID (KHI)  
> draft. There is nothing we can do in the HIP base draft; we need  
> those HITs defined somewhere.

I am open to both options.  If people feel that now is the right time  
to move from SHA-1 to SHA-256, I'm sure we can update the ORCHID/KHI  
draft.  IF we decide to make PHASH independent of the HIT hash  
algorithm, then the base draft needs to be updated accordingly.   In  
any case, we need to figure out for the base draft from where the  
hash algorithms for various cases come.  Right now the draft is not  
in good enough shape.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 12:56:04 +0300

>>> Assurance that two sessions will always use different session  
>>> keys is fragile. The keys are derived from the Diffie-Hellman  
>>> keys and puzzle challenges and responses, all of which can be  
>>> reused. Perhaps I missed it, but there should probably be more  
>>> explicit guidance on how to avoid this or explicit nonces should  
>>> be added.
>
> R1s when we send them out. This opens some DoS attack  
> possibilities. It means also that we lose the advantage of pre- 
> generating R1 messages.
>
> association, close it, and renegotiate it within the time when the  
> set of pre-generated R1s is valid.

IIRC, the original intent was that a given D-H key half is used only  
once.  That is, it may be offered multiple times at different points  
of time, but once an Initiator accepts it, it is NOT used in any  
other HIP session.  In implementation terms, one would have a pool of  
R1s, with different D-H values, and send them selectively.

Under normal traffic there should be no problems.  You just send one  
D-H key half in one R1, you get the I2 and you deprecate the R1.   
Problems start to appear under I1 flooding, where you cannot afford  
keeping re-generating D-H key halves but must reuse them.

So, I agree with Charlie that there should be better guidance on how  
to re-use pre-generated R1s in order to avoid fragile session keys.   
Given the current design, I'm afraid we cannot avoid them completely;  
i.e., there will be some I1 flooding scenarios under which some D-H  
keys may be fragile.  That should be documented in the Security  
Considerations section.

Anyone willing to write text?

[I think this is the last issue that I wanted to raise separately.]

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Apr 2006 12:57:26 +0300

>>> There are no real attacks on HIP based on finding collisions, but  
>>> as with many of these protocols there could be long theoretical  
>>> There are other places where SHA-1 is wired in with no mechanism  
>>> for negotiating anything else. None can be exploited given  
>>> collision attacks. They are:
>>>

I mentioned this already in the other thread.  I think your  
suggestion Petri of using the Responder's HIT hash algorithm is a  
good one.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Fri, 7 Apr 2006 22:07:11 +0300 (EEST)

> a full definition being expected to be available in some future

Agree.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 10 Apr 2006 07:39:12 +0300

Charlie,

The crux of this issue seems to be that (IIRC) we'd like to mandate/ 
recommend that the default configuration is one of the following:

  1. Offer HMAC-SHA1-AES128CBC as the last resort cipher suite, _or_
  2. Offer HMAC-SHA1-NULL as the last resort cipher suite

That is, by default, one of the above MUST be offered.

Now, is there something that you see problematic with such a  
requirement?  Maybe that the text is not clear enough in saying that  
the they are just the mandatory defaults, defined in order to ensure  
interoperability?

If not, then I think we just need to clarify the text.

--Pekka

On Apr 8, 2006, at 9:49, Charlie Kaufman wrote:

> I apologize that my mailer can't auto-generate the >> indentations  
> and at the moment I lack the patience to do it myself.
>
> I agree with Pekka that it's important that there could be a legal  
> implementation that did not offer encryption, so if you're going to  
> go down this path some Null scheme has to be mandatory to implement.
>
> But I still object to picking those algorithms as mandatory to  
> offer. While it guarantees interoperability between any two  
> compliant implementations (which is good), it comes at a cost of  
> disallowing *configurations* that only want to support some  
> stronger hash or that don't want to accept NULL encryption. I don't  
> know whether an RFC can say anything about the mandatory *default*  
> configuration, but I believe that's what you're really trying to  
> get at.
>
>         --Charlie
>
> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 12:40 AM
> To: HIP
> Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
> Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a  
> mandatory algorithm
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 10 Apr 2006 08:48:57 -0700

> Sent: Friday, April 07, 2006 12:39 AM
> To: HIP
> Cc: [email-masked]; Petri Jokela
> Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP
> 

I agree to the above proposal to avoid defining it here, because even
the option 1 described above has another possible outcome (block the
packet).  This topic is worthy of a separate draft, and some alignment
with opportunistic IPsec design.

Tom

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Apr 2006 07:59:28 +0300

Yes, we seem to be in violent agreement, Charlie, and that agreement  
concurs with what I remember that our intention was.  IIRC, we never  
discussed this issue into this detail before.

Taking the opportunity, I'd like to apply here also the "be strict in  
what you send, liberal in what you expect" rule here, and slightly  
weaken the language in other respects, too.  However, this should be  
taken as another issue (part 1 below) and we can decide on it  
separately from the default rule (part 2 below).

Here is my suggestion for revised text, part 1:

    When sending, there MUST NOT be more than six
    (6) HIP Suite-IDs in one HIP transform parameter.
    When receiving, the receiver SHOULD NOT rely on the
    sender not sending more than six Suite-IDs.

OTOH, I am happy with the original strict text, too, if there is any  
reason for it.   Any sensible implementation would not rely on it on  
receiving, anyway.

I would remove the next statement:

    The limited number of transforms sets the maximum
    size of HIP_TRANSFORM parameter.

OTOH, I don't remember the details of why we imposed the strict  
length rule in the first place.  Anyone?

Finally, suggested revised text, part 2:

    As the default configuration, the HIP_TRANSFORM parameter
    MUST contain at least one of the mandatory Suite-IDs.
    There MAY be a configuration option that allows the
    administrator to override this default.

--Pekka

On Apr 10, 2006, at 23:38, Charlie Kaufman wrote:

> If what you say in your note is the intent (and I think that's a  
> great thing to require), then I think the text needs to be  
> clarified. The language I was objecting to was in section 5.2.7:
>
>    There MUST NOT be more than six (6) HIP Suite-IDs in one HIP
>    transform parameter.  The limited number of transforms sets the
>    maximum size of HIP_TRANSFORM parameter.  The HIP_TRANSFORM  
> parameter
>    MUST contain at least one of the mandatory Suite-IDs.
>
> This implies that the HIP_TRANSFORM item is mal-formed if it does  
> not propose one of the mandatory Suite-IDs, which is much stronger  
> than saying that they must be present "in the default configuration".
>
> So it sounds like you and I agree. Is there anyone else out there  
> who wants to advocate the (current) stronger statement?
>
>         --Charlie
>
> Sent: Sunday, April 09, 2006 9:39 PM
> To: Charlie Kaufman
> Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela
> Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption  
> as a mandatory algorithm
>
> Charlie,
>

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 11 Apr 2006 17:13:33 +1200

> length rule in the first place.  Anyone?

Because there's no mechanism for fragmentation, the packets start  
getting big, and there is potential for MTU issues.

Andrew

---

From: Petri Jokela <[email-masked]>
Date: Tue, 11 Apr 2006 10:53:20 +0300

>> impossible). It should probably be changed to be implementer advice.

Suggestion (I'm not sure if the wording is correct):

"All HIP implementations have to be careful while employing
a reassembly algorithm so that the algorithm is sufficiently resistant
to DoS attacks. "

/petri

---

From: Petri Jokela <[email-masked]>
Date: Tue, 11 Apr 2006 15:03:58 +0300

Pekka Nikander wrote:
> I am open to both options.  If people feel that now is the right time to 
> move from SHA-1 to SHA-256, I'm sure we can update the ORCHID/KHI 
> algorithm, then the base draft needs to be updated accordingly.   In any 
> case, we need to figure out for the base draft from where the hash 
> algorithms for various cases come.  Right now the draft is not in good 
> enough shape.
> 
> --Pekka
> 
> 

There are multiple sources for used algorithms. If the key expansion
hash algorithm is changed to be dependent on the ORCHID, the following
hash algorithms are used in the base HIP (RHASH = Responder's HIT Hash
algorithm):

Where used                 Algorithm

HIT                        defined in ORCHID (currently SHA-1)
Puzzle                     RHASH - same as in ORCHID
Key expansion              RHASH - same as in ORCHID
Signatures (pub.key algs)  RSA and DSA documents (currently SHA-1)
HMACs (HIP_TRANSFORM)      RFC4307, RFC2451 (SHA1 or MD5)

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Apr 2006 21:31:57 +0300

>> I am open to both options.  If people feel that now is the right  
>> time to move from SHA-1 to SHA-256, I'm sure we can update the  
>> ORCHID/KHI draft.  IF we decide to make PHASH independent of the  
>> HIT hash algorithm, then the base draft needs to be updated  
>> accordingly.   In any case, we need to figure out for the base  
>> draft from where the hash algorithms for various cases come.   
>> Right now the draft is not in good enough shape.
>> --Pekka
>

To me, determining which hash function to use in each case from these  
sources seems to be OK.  I could even imagine a later optional  
payload that would allow negotiating the key derivation function; if  
anything, that one seems most problematic to me.  HIT derivation  
function is naturally defined by ORCHID, and since the puzzle is  
merely a DoS mitigation mechanism, I don't see anything bad there  
either.

As an alternative, would it be technically feasible to use the HMAC  
function from HIP_TRANSFORM for key derivation instead of RHASH?   
That would sound better to me, but I don't remember all the details  
well enough any more to be able to tell whether that would work in  
practise.

So, I would be happy with this (or the alternative) approach.  But I  
can't say if it is good enough from the Bellovin-Rescorla analysis  
point of view.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Wed, 12 Apr 2006 14:16:47 +0300

>> output of the HMAC is fixed at 160 bits. This is probably a bug in the 

Suggested fix: change the HMAC (and HMAC2) parameters so that the HMAC
field is variable length. The length depends on the used hash algorithm:

5.2.9.  HMAC

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                             HMAC                              |
       /                                                               /
       /                               +-------------------------------+
       |                               |            Padding            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type           61505
       Length         length in octets, excluding Type, Length, and
                      Padding
       HMAC           HMAC computed over the HIP packet, excluding the
                      HMAC parameter and any following parameters, such
                      as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST,
                      or ECHO_RESPONSE.  The checksum field MUST be set
                      to zero and the HIP header length in the HIP common
                      header MUST be calculated not to cover any excluded
                      parameters when the HMAC is calculated.  The size
                      of the HMAC is the natural size of the hash
                      computation output depending on the used hash
                      function.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Apr 2006 14:21:24 +0300

> field is variable length. The length depends on the used hash  

Looks good to me.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Wed, 12 Apr 2006 15:05:53 +0300

> with opportunistic IPsec design.

I would suggest adding a new subsection describing the situation. The 
descriptions of I1 and R1, as well as related packet handling text 
contains still some text about the possible NULL destination HIT, but no 
information about necessary packet handling. Reference to this new 
subsection is added to those points.

4.1.6.  HIP Opportunistic Mode

    It is possible to initiate a HIP negotiation even if the destination
    host's HI (and HIT) is unknown.  In this case the connection
    initializing I1 packet contains NULL as the destination HIT.  This
    kind of connection setup is called as opportunistic mode.

    Opportunistic mode setup contains multiple security issues that must
    be carefully addressed in the implementation.  The setup is
    vulnerable to e.g. man-in-the-middle attacks, because the
    initializing node does not have any public key information about the
    peer.

    The opportunistic mode is introduced in this document, but the actual
    connection setup process is not described thoroughly.  It is
    expected that a document describing the opportunistic mode connection
    setup procedure in more details, as well as the related security
    issues that must be taken care of, will be written later.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Apr 2006 16:01:31 +0300

> I would suggest adding a new subsection describing the situation.  
> The descriptions of I1 and R1, as well as related packet handling  
> text contains still some text about the possible NULL destination  
> HIT, but no information about necessary packet handling. Reference  
> to this new subsection is added to those points.

>    host's HI (and HIT) is unknown.  In this case the connection

s/destination host's/responder's/

>    initializing I1 packet contains NULL as the destination HIT.  This

s/NULL/NULL (all zeros)

>    Opportunistic mode setup contains multiple security issues that  

There are multiple security issues involved with opportunistic mode  
that must

>    be carefully addressed in the implementation.  The setup is

s/The setup/Such a set up/

>    vulnerable to e.g. man-in-the-middle attacks, because the

s/e.g./, e.g., /

>    issues that must be taken care of, will be written later.

While this document defines the concept of the opportunistic mode,  
and outlines the basic signalling mechanism to trigger it; i.e., send  
an I1 with a NULL destination HIT, this document does not specify the  
details of the opportunistic mode.  Especially, its security  
properties are not discussed beyond the warning above.  It is  
expected that a separate document will describe the opportunistic  
mode in more detail, including its security properties.

--Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 12 Apr 2006 07:13:07 -0700

This looks good to me, with Pekka's proposed mods.

Tom

---

From: Petri Jokela <[email-masked]>
Date: Thu, 13 Apr 2006 10:00:17 +0300

>> substantial damage. It does seem suspicious though.

In the current draft NOTIFYs can cause some trouble if handled like said 
in 6.13.:

6.13.  Processing NOTIFY Packets

    Processing NOTIFY packets is OPTIONAL.  If processed, any errors
    noted by the NOTIFY parameter SHOULD be taken into account by the HIP
    state machine (e.g., by terminating a HIP handshake), and the error
    SHOULD be logged.

It would be safer to say something like:

6.13.  Processing NOTIFY Packets

    Processing NOTIFY packets is OPTIONAL.  If processed, received errors
    MUST be considered only as informational and they MUST NOT result in
    changes in any state information.  All received errors SHOULD be
    logged.

Security Considerations:

    NOTIFY messages are used only for informational purposes.  They are
    unacknowledged and unprotected.  A HIP implementation cannot rely on
    the information received in a NOTIFY message, and it MUST NOT change
    any state information based on received NOTIFY messages.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Apr 2006 13:51:56 +0300

>>> Notifications are not acknowledged or protected from replay.  
>>> Today, notifications are only used for diagnostics, so a third  
>>> party filtering, duplicating, and reordering them probably can't  
>>> do substantial damage. It does seem suspicious though.
>
> Security Considerations:
>

Hmm.  I thought NOTIFYs were protected from other than replay  
attacks; anyway, they are signed.  ICMPs are supposed to be used as  
completely unprotected messages.

Other than that, I am willing to be happy with your suggestion.   
OTOH, I might allow NOTIFYs resulting in "spontaneous" state machine  
changes; i.e., moving from one state to another if the receive host  
can perform that move anyway.  If you say that NOTIFY strictly MUST  
NOT result in any changes in state information, that sounds too  
stringent to me.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Thu, 13 Apr 2006 14:00:44 +0300

Pekka Nikander wrote:
> Hmm.  I thought NOTIFYs were protected from other than replay attacks; 
> anyway, they are signed.  ICMPs are supposed to be used as completely 
> unprotected messages.

Hah, true, I just wonder what I have been looking at.... possibly the 
nice spring weather outside.

> Other than that, I am willing to be happy with your suggestion.  OTOH, I 
> might allow NOTIFYs resulting in "spontaneous" state machine changes; 
> i.e., moving from one state to another if the receive host can perform 
> that move anyway.  If you say that NOTIFY strictly MUST NOT result in 
> any changes in state information, that sounds too stringent to me.

Ok,

NOTIFY messages are used only for informational purposes and they are
unaknowledged.  A HIP implementation cannot rely on the information 
received in a NOTIFY message because the packet may have been replayed.
It SHOULD NOT change any state information based purely on a received
NOTIFY message.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Apr 2006 14:30:47 +0300

Looks good to me.

--Pekka

---

From: Charlie Kaufman <[email-masked]>
Date: Fri, 7 Apr 2006 11:35:56 -0700

Noting explicitly in the document that it does not define how to do opportunistic HIP would be reasonable. You could also comment on why all of the obvious solutions have serious problems.

I would expect a real implementation would include a "cache" of addresses with which HIP negotiations have succeeded and failed recently, and would probably treat a response packet differently from one where it is initiating the connection. It would probably be unacceptable to have the opportunistic negotiation to introduce a long real time delay in connection setup with every non-HIP enabled node, but it might be acceptable to have such a delay in the case where that node "recently" successfully negotiated HIP.

The low order 64 bits of the address might also provide heuristic clues as to whether the node is HIP-capable.

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Friday, April 07, 2006 12:39 AM
To: HIP
Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP

>> association sending at most I1_RETRIES_MAX I1 packets. If it does not
>> receive any R1s, it can try to initiate the  connection without HIP
>> if local policy allows.
>
> migrating a non-HIP connection to HIP06 11:35:57 -0700
From: Charlie Kaufman <[email-masked]>
To: Pekka Nikander <[email-masked]>, HIP <[email-masked]>
Date: Fri, 7 Apr 2006 11:35:56 -0700
Cc: Petri Jokela <[email-masked]>
Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP

Noting explicitly in the document that it does not define how to do opportunistic HIP would be reasonable. You could also comment on why all of the obvious solutions have serious problems.

I would expect a real implementation would include a "cache" of addresses with which HIP negotiations have succeeded and failed recently, and would probably treat a response packet differently from one where it is initiating the connection. It would probably be unacceptable to have the opportunistic negotiation to introduce a long real time delay in connection setup with every non-HIP enabled node, but it might be acceptable to have such a delay in the case where that node "recently" successfully negotiated HIP.

The low order 64 bits of the address might also provide heuristic clues as to whether the node is HIP-capable.

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Friday, April 07, 2006 12:39 AM
To: HIP
Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP

>> association sending at most I1_RETRIES_MAX I1 packets. If it does not
>> receive any R1s, it can try to initiate the  connection without HIP
>> if local policy allows.
>
> migrating a non-HIP connection to HIP06 11:35:57 -0700
From: Charlie Kaufman <[email-masked]>
To: Pekka Nikander <[email-masked]>, HIP <[email-masked]>
Date: Fri, 7 Apr 2006 11:35:56 -0700
Cc: Petri Jokela <[email-masked]>
Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP

Noting explicitly in the document that it does not define how to do opportunistic HIP would be reasonable. You could also comment on why all of the obvious solutions have serious problems.

I would expect a real implementation would include a "cache" of addresses with which HIP negotiations have succeeded and failed recently, and would probably treat a response packet differently from one where it is initiating the connection. It would probably be unacceptable to have the opportunistic negotiation to introduce a long real time delay in connection setup with every non-HIP enabled node, but it might be acceptable to have such a delay in the case where that node "recently" successfully negotiated HIP.

The low order 64 bits of the address might also provide heuristic clues as to whether the node is HIP-capable.

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Friday, April 07, 2006 12:39 AM
To: HIP
Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP

>> association sending at most I1_RETRIES_MAX I1 packets. If it does not
>> receive any R1s, it can try to initiate the  connection without HIP
>> if local policy allows.
>

I would be tempted to make it explicit that this document does not define how to do opportunistic HIP but simply provides hooks for it, a full definition being expected to be available in some future document.

Opinions?

--Pekka

inions?

--Pekka

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 10 Apr 2006 13:38:43 -0700

If what you say in your note is the intent (and I think that's a great thing to require), then I think the text needs to be clarified. The language I was objecting to was in section 5.2.7:

   There MUST NOT be more than six (6) HIP Suite-IDs in one HIP
   transform parameter.  The limited number of transforms sets the
   maximum size of HIP_TRANSFORM parameter.  The HIP_TRANSFORM parameter
   MUST contain at least one of the mandatory Suite-IDs.

This implies that the HIP_TRANSFORM item is mal-formed if it does not propose one of the mandatory Suite-IDs, which is much stronger than saying that they must be present "in the default configuration".

So it sounds like you and I agree. Is there an is probably hard to implement.

Opinions?

--Pekka

inions?

--Pekka

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 10 Apr 2006 13:38:43 -0700

Opinions?

--Pekka

inions?

--Pekka

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 10 Apr 2006 13:38:43 -0700

So it sounds like you and I agree. Is there anyone else out there who wants to advocate the (current) stronger statement?

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Sunday, April 09, 2006 9:39 PM
To: Charlie Kaufman
Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela
Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm

Charlie,

--Pekka

yone else out there who wants to advocate the (current) stronger statement?

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Sunday, April 09, 2006 9:39 PM
To: Charlie Kaufman
Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela
Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm

Charlie,

--Pekka

yone else out there who wants to advocate the (current) stronger statement?

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Sunday, April 09, 2006 9:39 PM
To: Charlie Kaufman
Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela
Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm

Charlie,

--Pekka

---

From: Charlie Kaufman <[email-masked]>
Date: Fri, 7 Apr 2006 23:49:30 -0700

I apologize that my mailer can't auto-generate the >> indentations and at the moment I lack the patience to do it myself.

I agree with Pekka that it's important that there could be a legal implementation that did not offer encryption, so if you're going to go down this path some Null scheme has to be mandatory to implement.

But I still object to picking those algorithms as mandatory to offer. While it guarantees interoperability between any two compliant implementations (which is good), it comes at a cost of disallowing *configurations* that only want to support some stronger hash or that don't want to accept NULL encryption. I don't know whether an RFC can say anything about the mandatory *default* configuration, but I believe that's what you're really trying to get at.

        --Charlie

-----Original Message-----
From: Pekka Nikander [mailto:[email-masked]]
Sent: Friday, April 07, 2006 12:40 AM
To: HIP
Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman
Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm

--Pekka