[secdir]Comments on draft-ietf-shim6-hba-01

[Geoff Huston <gih@apnic.net>]

Hi,

We'd like to interject on this list with a piece of shim6 working group 
business.

Some months back this working group concluded a last call 
on  draft-ietf-shim6-hba, the hash based-address draft. This draft was 
passed to the Internet Area Directors, but it was agreed that the document 
would be parked with the area directors until the protocol and failure 
drafts also made it through WG Last Call.

We'd like to ask the working group at this stage if there are any further 
thoughts about the hash based address draft in the light of a security 
directorate review of the draft. The message thread of that review is 
attached to this note. (The review was conducted in November and December 
last year)

So are there any WG comments related to this security directorate review 
please?

regards,

    Geoff & Kurtis

---------------------------------






From: Eric Rescorla <ekr@networkresonance.com>


I've just finished reading draft-ietf-shim6-hba-10: "Hash Based Addresses"

GENERAL COMMENTS ON THE MECHANISM
The basic goal of this draft is to securely bind together multiple
IPv6 addresses that belong to the same multihomed host. This allows
rerouting of traffic without worrying that you're being redirected
to an attacker. The technique that's used is to use a hash of the
permitted prefixes in the low order bits of the v6 address.

So, eliding some details, say you have prefixes A, B, C, and D, you
would generate a prefix list P consisting of (A,B,C,D). Then you would
generate the new addresses:

    A || H(A || P)
    B || H(B || P)
    B || H(C || P)
    D || H(D || P)

Thus, given one valid address out of the group and the prefix list P you
can determine whether another address is part of the group by computing
the hash and checking against the low order bits.

For me, the big unanswered question is why this is a good general
approach. Far preferable, IMO, would be to simply to cryptographically
sign the prefix list using some key bound to the association.
This key could be established in a number of ways, including
something like BTNS or CGA. This would have a number of advantages:

(1) A more standard style mechanism.
(2) Not tied to SHA-1.
(3) Doesn't get progressively weaker due to Moore's law, since you
    can continue to increase your key size. By contrast, this scheme
    has an absolute upper security limit of 2^64.
(4) Can add new prefixes in real-time.

This draft does not make clear what advantages the described scheme
has.

It's also worth noting that if you're using IPsec, you have a lot of
other options that are even better.


COMMENTS ON THE DOCUMENT
This document needs a lot more abstract up-front material.
I recommend adding:

(1) A section on the threat model.
(2) Explanation of why this is a desirable approach.
(3) An abstract description of the mechanism, as shown above.
    S 4,5 have way too much detail to be this, and, it's actually
    distracting.


S 4:
I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
terms for SHA-1.

Why are three collisions a boundary here in step 6.4. Have you
analyzed the chance of this happening? Why not just continue
until you're out of collision bits.

S 5.
I found paragraph 2 here fairly awkward. As I understand it,
the point here is to justify the replacement in step 1, but
maybe a rewrite is in order? Sorry I can't be of too much help
here, but no new text comes to mind.

Is Sec in the packet? If so, what stops an attacker setting it
to zero?


S 9.
Given that this mechanism is tied irrevocably to SHA-1, it seems
appropriate to discuss what properties of SHA-1 you require.


------------------------------------------------------------------------------

From: Sam Hartman <hartmans-ietf@mit.edu>

I've forwarded your review to Margaret as she requested the review.


There is a threat model for the general problem space which I believe
is sufficient for thinking about this document.  Take a look at RFC
4218.  I seem to recall it is quite well written as these things go.


So, roughly, here are my first cut at requirements for a solution.
This is off the top of my head.  I am not up to speed on shim6; they
may actually have requirements written out.

1) You want to have a efficient mechanism for authenticating that
   traffic is going to a valid place.

2) You don't want attackers who were once on-path to be able to direct
   traffic to themselves.

3) You don't want off-path attackers to be able to direct traffic to
   themselves at all.

4) You don't want on-path attackers to be able to influence traffic
   such that it goes to them and not the original destination.
   I.E. if I'm on the path and also have some tunnel address you
   woludn't see I should not be able to redirect your traffic to my
   tunnel and thus capture it.

the requirement for efficient probably rules out DH and any public-key
key agreement algorithm.  The requirement for deployable rules out
anything that assumes preconfiguration.


So, you don't start out with a secret.  You can trivially have a
secret from off-path attackers simply by sending the secret over the
connection.  (I hesitate to call that a secret, but it would at least
be a quantity unknown by people off-path).


However there's very little you can do about the on-path people.  I
think the only thing you can do is commit to some quanity so that an
on-path attacker cannot add addresses.


I'd be very interested in other ways of looking at this because I do
agree with your concerns about HBA.

--Sam

_______________________________________________

From: Jari Arkko <jari.arkko@piuha.net>

Hi Eric,

Continuing the discussion on some of the points
you raised:

> For me, the big unanswered question is why this is a good general
> approach. Far preferable, IMO, would be to simply to cryptographically
> sign the prefix list using some key bound to the association.
> This key could be established in a number of ways, including
> something like BTNS or CGA. This would have a number of advantages:
I guess the main question is "what association". In
situations where we have actual managed security
relationship, such as in VPNs, we already have IKEv2
and MOBIKE which do more or less the same function
as SHIM6 does, so there's really no need for additional
support in IPv6 for this purpose. However, this is not
the only scenario people have. SHIM6 targets more
general Internet usage which does not assume managed
security between corresponding hosts. But I think
we agree on this, the question is on how to achieve
it. The possibilities that come to my mind are

 - HBAs
 - CGAs
 - BTNS

SHIM6 is taking the approach which uses HBAs or optionally
CGAs. Another possible option would have been to use only
CGAs. I believe the discussions that led to doing HBA related
to computational cost, and IPRs. However, I'm personally
not very convinced about the computational cost problem.
For one thing, I think you only need to do the computations
IF you actually end up having a connectivity problem and
have to switch the address. (There was also some confusion
in the WG I think about the CGA public key computation
implying "PKI" but I hope that was not the reason people
wanted to have symmetric scheme like HBA...) And then
there are IPR on CGA by Ericsson and Microsoft, maybe that
was a part of the rationale for choosing mandatory HBA. But
I have not personally looked at the actual patents so
I at least do not know if the simpler HBA scheme really
falls outside the scope of the claims. Also, there was a
free license for SEND use of CGA by the IPR holders, so
that might be something to try here too.

BTNS would be the other option. However, while
I think BTNS does a good job in the channel binding
case I'm much less convinced that we know what it
should or could do in other cases. In fact, I do not
currently see how to make it work for something like
what SHIM6 wants to do. Maybe we can make it work,
but its really not there today. Getting it done would
be very useful, though, particularly if BTNS+MOBIKE would
give us SHIM6-like functionality but have it also work for v4
and over NATs...

> (2) Not tied to SHA-1.
The SHA-1 issue is by the way something that applies
not just to this proposal but also to CGAs as defined for
SEND. I'd like to see an effort try to get rid of SHA-1
in CGA. If the CGA format is changed then this draft's
use of SHA-1 would also be fixed.

> (3) Doesn't get progressively weaker due to Moore's law, since you
>    can continue to increase your key size. By contrast, this scheme
>    has an absolute upper security limit of 2^64.
I believe HBA uses the same "Sec" extension scheme as
CGA does, see Section 7.2 in RFC 3972. That is, the
difference between the effort of the owner and attacker
is always 2^59, but the actual effort can be adjusted.

--Jari

_______________________________________________

From: Eric Rescorla <ekr@networkresonance.com>

Sam Hartman <hartmans-ietf@mit.edu> writes:

> I've forwarded your review to Margaret as she requested the review.
>
>
> There is a threat model for the general problem space which I believe
> is sufficient for thinking about this document.  Take a look at RFC
> 4218.  I seem to recall it is quite well written as these things go.

Willdo.

> So, roughly, here are my first cut at requirements for a solution.
> This is off the top of my head.  I am not up to speed on shim6; they
> may actually have requirements written out.
>
> 1) You want to have a efficient mechanism for authenticating that
>    traffic is going to a valid place.
>
>
> 2) You don't want attackers who were once on-path to be able to direct
>    traffic to themselves.
>
> 3) You don't want off-path attackers to be able to direct traffic to
>    themselves at all.
>
> 4) You don't want on-path attackers to be able to influence traffic
>    such that it goes to them and not the original destination.
>    I.E. if I'm on the path and also have some tunnel address you
>    woludn't see I should not be able to redirect your traffic to my
>    tunnel and thus capture it.
>
> the requirement for efficient probably rules out DH and any public-key
> key agreement algorithm.  The requirement for deployable rules out
> anything that assumes preconfiguration.

I don't think I agree with this assumption. A single digital
signature that's checked every time you re-home seems quite
eminently practical.

-Ekr
_______________________________________________
From: Jari Arkko <jari.arkko@piuha.net>

Forgot to say one thing that I wanted to say...

> The possibilities that come to my mind are
>
>  - HBAs
>  - CGAs
>  - BTNS
>
> SHIM6 is taking the approach which uses HBAs or optionally
> CGAs.

While the use of CGAs (or something BTNS+MOBIKE derived)
would be more general, I don't actually see any specific
problems in the HBA use, at least not compared to CGAs,
assuming the algorithms can be updated. HBA does not
have any less bits available than CGA, and while the technique
is very simple, it still binds the addresses together, which
was the purpose for this particular function.

Of course, we may still discuss whether we believe dynamic
addresses are frequent enough to make non-static
solutions better, or whether we want one mechanism instead
of two, etc.

--Jari

---------------------------------------------

From: Eric Rescorla <ekr@networkresonance.com>

Jari Arkko <jari.arkko@piuha.net> writes:

> Forgot to say one thing that I wanted to say...
>
>> The possibilities that come to my mind are
>>
>>  - HBAs
>>  - CGAs
>>  - BTNS
>>
>> SHIM6 is taking the approach which uses HBAs or optionally
>> CGAs.
>
> While the use of CGAs (or something BTNS+MOBIKE derived)
> would be more general, I don't actually see any specific
> problems in the HBA use, at least not compared to CGAs,
> assuming the algorithms can be updated. HBA does not
> have any less bits available than CGA, and while the technique
> is very simple, it still binds the addresses together, which
> was the purpose for this particular function.

Well, I think I disagree here on philosophical grounds.
I prefer to avoid inventing new mechanisms--especially ones
of new styles--when that can be avoided. The standard primitives
we have for integrity are MACs with shared keys and digital
signatures with known public keys. Why invent something new.

-Ekr

----------------------------------------

From: Jari Arkko <jari.arkko@piuha.net>

Eric Rescorla wrote:

> > While the use of CGAs (or something BTNS+MOBIKE derived)
> > would be more general, I don't actually see any specific
> > problems in the HBA use, at least not compared to CGAs,
> > assuming the algorithms can be updated. HBA does not
> > have any less bits available than CGA, and while the technique
> > is very simple, it still binds the addresses together, which
> > was the purpose for this particular function.
>
> Well, I think I disagree here on philosophical grounds.
> I prefer to avoid inventing new mechanisms--especially ones
> of new styles--when that can be avoided. The standard primitives
> we have for integrity are MACs with shared keys and digital
> signatures with known public keys. Why invent something new.
Actually, we may be in agreement here. I was
just pointing out that I don't see any specific
problem in this mechanism wrt. the desired
function. But I still agree with your philosophical
principle.

--Jari


_______________________________________________