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@xxxxxxx] > Sent: Friday, February 16, 2007 1:32 PM > To: Dan Harkins > Cc: bernarda@xxxxxxxxxxxxx; ietf@xxxxxxxx > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf