ietf
[Top] [All Lists]

RE: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt

2007-03-08 08:41:00
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