[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [secdir]Comments on draft-ietf-shim6-hba-01
Hi,
thanks for the review and for forwarding it...
in general terms, i understand that the summary of the discussion is
about whether we need a shim6 specific security mechanism like HBA or
we can handle this with other more general purpose mechanisms.
As i understand it, during the discussions about the security approach,
it was deemed that it was very important to have an optimized
performance for the shim protocol and that the security solution didn't
impose much additional performance penalties. I guess we agree that HBA
are as efficient as we can get, since they only require a hash
operation for generation and for verification. The usage of approaches
based on public key are clearly a couple of orders more expensive. I
guess this is critical, since the verifications need to be performed
for each shim6 session. From the reading of lately discussions about
the load imposed by the shim6 protocol in heavy loaded servers, i think
that this issue becomes particularly relevant, since using an
efficient/computationally cheap method in those servers will reduce the
computational load imposed to them considerably.
I mean, i think that an important thing to note is that shim6 is not
used as other security mechanisms like BTNS when additional security is
needed, but is is expected to be used in most of the communications.
This means that any performance penalty that is added because of
security will affect most of the communications (as oposed to only
those that require special security). In other words, in other
scenarios, where people are looking for enhanced security, they are
likely to pay the additional cost that it implies. However, in this
case, these are regular communications, so imposing a high performance
cost due to security is harder to accept i guess.
In addition, i think it is important to note that HBA are defined as an
extension to CGAs so actually the verification needed for HBA are
actually a subset of the verification needed for CGA, since you only
need to generate the address to verify the validity while in the CGA
case, you need to generate the address and then verify the signature.
So, imho, the performance gain justifies the need for a specific
security mechanism, especially considering some scenarios where
performance is critical and where turning on the shim shouldn't impose
important performance penalties to the server.
Additional detailed comments below...
El 25/04/2006, a las 18:11, Geoff Huston escribió:
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.
the answer to this question is performance
see above considerations
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.
well, HBA is heavily based on CGA
actually the generation and verification mechanisms are the CGA
methods, only that they need to be performed several times instead of
one.
Since the HBA has been defined as a CGA extension, generating the CGAs
including the HBA extension results in generating the HBAs. Moreover,
this is already supported in the current CGA spec, since it does
contain support for extensiosn, and it does states that they must be
included in the hash calculations
(2) Not tied to SHA-1.
but CGAs are the ones tied to SHA-1 rather than HBA
HBAs are tied to SHA-1 because they are defined as a CGA extension. so
moving to CGAs wouldn't address this issue
(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.
two comments:
- first, as JAri mentions below, there is the Sec parameter to deal
with this
- second, the weakest link in the chain is the 59 bits of hash
contained in the iid. so CGAs and HBA are equally weak and increasing
the key length of the CGA does not provides additional security,
because the weak part is the number of iid bits
(4) Can add new prefixes in real-time.
that is true, but with the additional perfrmance penalty
This draft does not make clear what advantages the described scheme
has.
I can try to add some comments about the motivation for this, in the
lines of performance and use cases
It's also worth noting that if you're using IPsec, you have a lot of
other options that are even better.
better in which sense?
more secure? not sure how wihtout using a PKI scheme... i mean if you
want to use locators as ULIDs, which seems to be the case in order not
to break some apps and other stuff you have two options AFAICT:
- include crypto information in the iid (so hba is as secure as you can
get i guess)
- use certificates (or another third trusted party) to secure the
binding... i think that the deployment issues involved with this are
really big, so we decided not to go thorugh this path
COMMENTS ON THE DOCUMENT
This document needs a lot more abstract up-front material.
I recommend adding:
(1) A section on the threat model.
well, there is a RFC4218 that is referenced a couple of times, which
contains the threat analysis, and in addition, there is the security
considerations that explains what an attacker needs to do to actually
attack the HBAs... so i am not sure what to add... any suggestions?
(2) Explanation of why this is a desirable approach.
yes, i can add a parragraph about performance issues and use cases
(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.
ok, do you mind if i borrow your text above?
S 4:
I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
terms for SHA-1.
ok
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.
this is taken from the CGA spec, so in order to change this we need to
change this we need to change RFC3972
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.
ok, i will to rewrite it
Is Sec in the packet? If so, what stops an attacker setting it
to zero?
Sec is included in the address itself, so changing the Sec implies
changing the address
S 9.
Given that this mechanism is tied irrevocably to SHA-1, it seems
appropriate to discuss what properties of SHA-1 you require.
fully agree, but i guess that what is needed is a general anlysis for
CGAs rather than one special for HBA...
-----------------------------------------------------------------------
-------
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.
Yes, RFC4218 and i think it covers all the threats...
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.
yes, the problem are basically future/time-shifted attacks...
AFAICT, HBAs are the candidate to provide protection against these
attacks without using public key crypto...
Regards, marcelo
I'd be very interested in other ways of looking at this because I do
agree with your concerns about HBA.
--Sam