Since there is no binding of identities it allows an
authenticator to say "give me the key for authenticator FOO"
even though it is actually authenticator BAR. For instance
the NAS-Id is put into a RADIUS request to ask for a specific
key and the key is sent back protected by the shared secret
bound to the IP address of the authenticator. Since this
network access credential is symmetric all security
properties that it could've had are are lost-- the lying
authenticator can impersonate the client to the real FOO
authenticator, it can inject traffic into a connection
between the peer and the FOO authenticator, it can inspect
traffic on a connection between the peer and the FOO authenticator.
None of this is feasible when the key distributed to BAR (impersonating
as FOO) is different from the key distributed to FOO (appearing as FOO).
In other words, a peer connects to BAR and thinks it is connected to
FOO. The server also thinks the peer is connected to FOO; a key (say,
K1) is derived (with freshness) and given to FOO aka BAR. But, at this
point, the real FOO DOES NOT have K1. When the peer tries to attach to
the real FOO, it may attempt to use K1, but, will fail. If another key
is requested for/by the real FOO, all the server has to ensure is that
K1 is *never* given (in fact, K1 should never have been cached and MUST
be forgotten after delivery); a *different* key (say, K2) must again be
derived (with freshness, again) and given.
In other words, no two key retrievals from the server must result in the
same key being distributed, even if the entity requesting the key is
*seemingly* the same. This only means that every transported key MUST
have an element of freshness (say, at least a server nonce) that must be
communicated with end-to-end protection between the server and peer.
Ensuring correctness of identities while allowing the same key to be
retrievable upon multiple fetches is only *one* way to achieve the
security properties you are trying to achieve. In fact, *never* allowing
the same key to be retrievable multiple times even by the same entity
will consistently achieve these security properties, irrespective of the
correctness of identities.
Vidya
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf