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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]