Dan,
There is a fundamental security property in all that we have been
discussing:
It MUST NOT be possible for an entity A, impersonating as entity B, to
obtain any key material that entity B may actually possess at any time.
And that, I fully agree with.
However, you are going further and saying that that property can *only*
be achieved by detecting the impersonation and hence, detection of
impersonation by the key transport protocol is a MUST.
And that, I disagree with. As I've tried to describe below, there is
more than one way of achieving the same security property.
Vidya
-----Original Message-----
From: Dan Harkins [mailto:dharkins(_at_)lounge(_dot_)org]
Sent: Wednesday, March 07, 2007 10:36 PM
To: Narayanan, Vidya
Cc: Dan Harkins; Sam Hartman; ietf(_at_)ietf(_dot_)org
Subject: RE: [Dan Harkins] comments on
draft-houseley-aaa-key-mgmt-07.txt
If you have a 3 party key distribution scheme and at the
end of it the 3 parties do not share ALL THE SAME STATE yet
believe the protocol has successfully completed then your key
distribution scheme is flawed.
Dan.
On Wed, March 7, 2007 8:32 pm, Narayanan, Vidya wrote:
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