headers
Gonzalo Camarillo | 2 Apr 2006 18:57
Picon
Favicon

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

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 <housley <at> vigilsec.com>
To: hip-chairs <at> tools.ietf.org, townsley <at> cisco.com
CC: hartmans-ietf <at> mit.edu

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 <charliek <at> exchange.microsoft.com>
>To: Russ Housley <housley <at> vigilsec.com>, "secdir <at> mit.edu" <secdir <at> mit.edu>
>CC: "hartmans-ietf <at> mit.edu" <hartmans-ietf <at> mit.edu>
>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
(Continue reading)

Permalink | Reply | 30 comments |
headers
Miika Komu | 3 Apr 2006 17:51
Picon
Picon
Favicon

some comments for mm-03

Some comments for mm-03, part 1/2 (I'll send the rest later this evening).
Should keep Thomas busy until then :)

I haven't read the mm-03 draft for a long time (1-2 years) througly,
so decided to do it now with fresh eyes. Below are my suggested
changes, but before that, a short executive summary of the
proposed changes:

* Mainly consists of many readability/understandability enchancements and
  requests for clarifications.
* Mainly, no new features. In fact, I suggest removing one
  feature/use-case (readdress with peer-initiated rekey) in favour of
  simplifying state machine, interaction with middle-boxes and
  interoperable implementations.
  Suggest removal of it from this draft and adding to a follow-up
  draft.
* An initial proposal for a state machine for mobility and multihoming
  based on the current text in the draft, excluding the (readdress with
  peer-initiated rekey). The actual state machine is in separate email.
* Some new text on closing of SAs in multihoming case.

I feel that the current draft is too "loose", just for the sake of
experimentation but IMHO it makes the implementation too complex in
practice and also makes the situation bad for the interoperability of
implementations. I believe that this can be accomplished by reducing
the functionality: removing the "readdress with peer-initiated
rekey" use case, sticking to three-way packet exchange and adding a
reference state machine.

Editorial comments:
(Continue reading)

Permalink | Reply | 27 comments |
headers
Miika Komu | 3 Apr 2006 17:54
Picon
Picon
Favicon

a state machine proposal for mm-03

Simplified State Machine without Peer Initiated Rekeying
========================================================

Note1: since there are no other HIP header types for mobility and
multihoming (other than UPDATE), the actual packet processing depends
on the parameters in the HIP packet.

Note2: the state machine is simpler to design if we leave out the peer
initiated rekeying (section 3.2.1.2 in the draft). This way, we can
assume that the UPDATE exchange consists of three packets and that
each packet can be distinguished from each other by the precence of
LOCATOR, ECHO_REQUEST or ECHO_RESPONSE.

Note3: reusing the same state variables on both hosts. At the mobile
host (the sender of LOCATOR) it is related to the data structures of
the source IP. On the corresponding node (receiver of LOCATOR), it is
related to the destination IP.

Note4: need some fresh eyes to verify that this is actually sensible :)

Send UPDATE with LOCATOR:
  - Triggered at the MN depending on changes in network attachments
    and according to local policies
  - Removed addresses are DEPRACATED (and not included in the
    LOCATOR)
  - All other addresses are UNVERIFIED (and included in the LOCATOR)
  - Set preferred LOCATOR depending on local policies
  - Send UPDATE with LOCATOR for the CN

Receive HIP UPDATE:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Miika Komu | 3 Apr 2006 23:29
Picon
Picon
Favicon

Re: some comments for mm-03

> Some comments for mm-03, part 1/2 (I'll send the rest later this
> evening).

Here we go again.. decided to split the email on separate sections. Here
is (the end of section three and) section 4.

> 3.3.4.  Interaction with Security Associations
>
> This document specifies a new HIP protocol parameter, the LOCATOR
> parameter (see Section 4), that allows the hosts to exchange information
> about their locator(s), and any changes in their locator(s).

This document specifies a new HIP protocol parameter, the LOCATOR
parameter (see Section 4), that allows the hosts to exchange
information about changes their locator(s).

> The relation between these entities for an association negotiated as
> defined in the base specification [2] and ESP transform [5] is
> illustrated in Figure 11.

What entities? There is also something other fishy with this sentence.

> The addresses addr1a and addr2a are the source addresses that each host
> uses in the base HIP exchange.

The addresses addr1a and addr2a are the source addresses that the hosts
use in the base HIP exchange.

> These are the "preferred" (and only) addresses conveyed to the peer for
> each SA; even though packets sent to any of the hosts' interfaces can
(Continue reading)

Permalink | Reply | 10 comments |
headers
Miika Komu | 4 Apr 2006 01:05
Picon
Picon
Favicon

Re: some comments for mm-03

On Tue, 4 Apr 2006, Miika Komu wrote:

> > Some comments for mm-03, part 1/2 (I'll send the rest later this
> > evening).
>
> Here we go again.. decided to split the email on separate sections. Here
> is (the end of section three and) section 4.

And here are comments from section five.

> 5.  Processing rules

(perhaps a tiny intro)

> 5.1.  Locator data structure and status
>
> Rapidly sending conflicting LOCATORs SHOULD be avoided.

What conflicting means here?

This section does not talk about selecting the source address for a
locator to be sent. Suggest adding text on what to choose as the source
address: the newly obtained locator or, in the case of multiple obtained
locators, selection according to a local policy.

> 3.  Host multihoming (addition of an address).  We only describe the
>     simple case of adding an additional address to a single-homed,
>     non-mobile host.

s/single-homed/multi-homed/ ?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Miika Komu | 5 Apr 2006 09:34
Picon
Picon
Favicon

Re: some comments for mm-03

My last comments, from section six:

> 6.  Security Considerations
>
> If no precautionary measures are taken, an attacker could misuse this
> feature to impersonate a victim's peer from any arbitrary location.

s/this/the redirection/

> If an attacker somehow uses a bug in the implementation or weakness in
> some protocol to redirect a HIP connection, the original owner can
> always reclaim their connection (they can always prove ownership of the
> private key associated with their public HI).

How is this possible if the private key is compromised?

> MitM attacks are always possible if the attacker is present during the
> initial HIP base exchange and if the hosts do not authenticate each
> other's identities, but once the base exchange has taken place even a
> MitM cannot steal an opportunistic HIP connection because it is very
> difficult for an attacker to create an UPDATE packet (or any HIP packet)
> that will be accepted as a legitimate update.

This does not make sense because it is too obvious? After opportunistic
connection (leap of faith) the connection is no longer opportunistic.
Maybe this text can be just removed.

> 6.2.  Denial of Service attacks

> This threat is mitigated through reachability checks and credit-based
(Continue reading)

Permalink | Reply | 3 comments |
headers
Petri Jokela | 6 Apr 2006 09:18

Re: [Fwd: Fwd: Belovin-Rescorla analysis - HIP]

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).

> 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 <charliek <at> exchange.microsoft.com>
>> To: Russ Housley <housley <at> vigilsec.com>, "secdir <at> mit.edu" 
>> <secdir <at> mit.edu>
>> CC: "hartmans-ietf <at> mit.edu" <hartmans-ietf <at> mit.edu>
>> Date: Thu, 23 Mar 2006 12:49:35 -0800
>> Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP

>> 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.
(Continue reading)

Permalink | Reply | 22 comments |
headers
Andrew McGregor | 6 Apr 2006 10:13
Picon
Favicon

Re: [Fwd: Fwd: Belovin-Rescorla analysis - HIP]


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

> 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).

I have a few further comments inline.

>
>> 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 <charliek <at> exchange.microsoft.com>
>>> To: Russ Housley <housley <at> vigilsec.com>, "secdir <at> mit.edu"  
>>> <secdir <at> mit.edu>
>>> CC: "hartmans-ietf <at> mit.edu" <hartmans-ietf <at> mit.edu>
>>> Date: Thu, 23 Mar 2006 12:49:35 -0800
>>> Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP
>

<big snip>

>>> There are other places where crypto-agility is not all that it  
>>> might be:
>>>
(Continue reading)

Permalink | Reply | 16 comments |
headers
Pekka Nikander | 7 Apr 2006 09:11

Belovin-Rescorla analysis - HIP: D-H group negotiation

[Creating separate threads for separate issues.]

>>>> 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.
>>
>> 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.
>
> We implemented this at one stage before the big packet format  
> change... IIRC it worked fine.  I think it should be resurrected.

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Nikander | 7 Apr 2006 09:29

Belovin-Rescorla analysis - HIP: wired-in SHA-1

>>>> 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.
>>
>> Shall we leave these as a headache for the HIP v2 designers?
>
> I think we should fix this 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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane