I have not seen an email from Dan posted to the IETF list here, but,
having participated in the HOKEY discussions from which this seems to
have appeared, I think I understand the context.
-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: Friday, February 16, 2007 1:32 PM
To: Dan Harkins
Cc: bernarda(_at_)microsoft(_dot_)com; ietf(_at_)ietf(_dot_)org
Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt
Speaking as an individual:
I believe the attack Dan is concerned about is very important
and I believe it is important that this draft make it clear
that distributing keys to the wrong parties does not meet the
requirements of the draft.
I think we need to look at what it means by "distributing keys to the
wrong parties" and there are two points for consideration.
1) The peer and the server need to have a common understanding of the
identity of a third entity to which a key may be distributed. When the
server is unambiguously able to verify the identity of that entity (as
would be feasible with Diameter secured with TLS, for e.g.), it can
actually be concluded that the third entity is what it claims to be.
Now, there are possible RADIUS models, where such guarantees may not be
available. There, the only thing that can be ensured is that the peer
and the server both "think" the third entity is what it claimed to be.
However, in both cases, it is feasible to ensure that the third entity
doesn't get away with claiming one identity to the peer and a different
identity to the server.
2) The second point is that no two such "third" entities must obtain the
same key. When the server can actually detect impersonation (say,
because the SA was bound to the identity), this would actually translate
to the fact that the key given to that entity can be guaranteed to be
meant for it. When the server cannot detect impersonation, this only
translates to the fact that a key given to an entity is not the same as
any other key given to any other entity, with no guarantees on whether
the key was meant for it or not.
Translating this to an example: Consider authenticators in ISP1 and ISP2
that want to obtain a key each for a peer, except, ISP1 is impersonating
to be ISP2.
Peer attaches to ISP1, but, thinks it is attached to ISP2. At the
backend, if the server is able to detect the impersonation, the problem
is solved and no keys are given out. But, if the server also believes
that it is ISP2, a key might be given to it and peer goes about its
communication.
Now, the peer attaches to the real ISP2. If it attempts to use the same
key, that will fail. If it tries to fetch another key from the server,
the server MUST ensure that the key given out, although may still be to
"ISP2" in its view, is not the same as the key that was given out
earlier. In other words, a static derivation like "Transported Key = PRF
(Some Master Key, "ISP/authenticator ID") is insufficient in such cases,
since, the resultant key will be the same when the IDs are the same.
Hence, we can use some random data to ensure that even if the IDs are
"perceived" to be the same, the same key is never generated. Of course,
this example is just making a point, not trying to design a particular
solution.
The above is sufficient to ensure that a lying entity cannot use a key
to cause any damage to sessions with other entities, regardless of the
fact that the lying couldn't be detected due to the shortcomings of the
key transport protocol.
I take no position on whether the draft does accomplish that already.
To me, the draft is clear. However, if it can perceived to be unclear to
some others, then, that may be a problem and the text may be worth
fixing. In short, I think it comes down to something like the following:
"It is RECOMMENDED that the key transport protocol be able to detect
impersonation. When it is not feasible to guarantee that, every key
handed out from the server to an entity for a given peer MUST be
different from every other key handed out for a given peer."
If people feel like that might be useful, perhaps that could be added to
the document.
Vidya
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf