ietf
[Top] [All Lists]

RE: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt

2007-04-09 06:20:38
O, I definitely think they are session keys.
 
[BA]  They are not TSKs according to the definition in the EAP Key Management 
Framework. 

Wait, what's wrong with giving 100 authenticators 100 different keys
provided that each authenticator is authorized to claim the identity
it plans to claim?  Isn't that exactly the sort of thing we do want to do?
 
[BA] The creation of cryptographically separate keys for each authenticator is 
not sufficient;  the EAP Key Management Framework describes the problems that 
can result without authentication and authorization.  
 
As an example,  Proactive Key Distribution as proposed in 
http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt 
distributes keys in advance of peer arrival at an authenticator.  The problem 
is that evidence is not provided to the AAA server that the peer actually 
arrived at an authenticator to whom a proactive key was provided. 
 
Since accounting records can now be created without a corresponding AAA 
conversation, new classes of attacks become possible.  For example, a rogue 
authenticator can claim that the authenticator has connected to itself or 
another authenticator in the neighbor graph by issuing bogus accounting 
records.  Since Bogus accounting records can be created without fear of 
detection, financial fraud becomes possible.  
 
Corruption of the neighbor graph is also possible unless the AAA server only 
creates neighbor graph entries in response to successful authentications 
between the peer and AAA server.  Without this, a rogue authenticator could 
corrupt the neighbor graph by submitting bogus accounting records, causing 
proactive keys to be distributed outside their authorized scope (e.g. only to 
legitimate 'neighbors'). 
 
Note that proactive key distribution actually provides more security safeguards 
than some other 'fast handoff' proposals because the creation of a neighbor 
graph based on successful authentications limits the scope of potential 
mischief.  For example, an authenticator in Hawaii cannot claim to be a 
neighbor of one in New York without providing evidence that a peer had actually 
authenticated via both. 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf