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