Sam,
I guess the question is, what text in this I-D would prevent a new
key distribution protocol based on AAA in which the authentication
server sent a copy of the peer's keys willy-nilly to every
authenticator it had a security association with?
Another question: has the peer no say in to whom its secrets are
disclosed? If you think it does then what in the I-D addresses that
concern and if you don't think it does then why?
As I have stated (starting with my 16 Feb 07 comments) I think this
is an important I-D and we need an RFC on this subject. I just don't think
it goes far enough in proscribing bad behavior and mandating good behavior.
Again, the 802.11 Task Group "r" is a prime example of why this I-D
does not go far enough.
I think this I-D has to discuss the use of AAA as a key distribution
protocol and it does not do that right now.
At the SAAG meeting you said (something to the effect of) "everyone
understands the 'channel binding' issue". I don't necessarily agree with
you (see 802.11r) but the problem is that when AAA is used as a key
distribution protocol that issue explodes in another dimension. And people
think that if it's OK to ignore that issue in the traditional EAP case
where an authentication server gives single key to single authenticator
through whom the peer is speaking then it must be OK to ignore it when
distributing keys to a multiplicity of authenticators that the peer is not,
and may never be, speaking to.
Dan.
On Fri, March 30, 2007 10:52 am, Sam Hartman wrote:
Hi. I had a few discussions in Prague and think that we're all
basically on the same page about what the document should say. I'm
going to describe that consensus here. I'd like to ask Russ to
confirm that the document reflects the consensus
and if so to ask me to remove my discuss and approve the document.
Unless I've really gotten something wrong here, I think we're done
deciding what we are trying to say and are only left with deciding if
we've managed to say it. When two parties communicate in these
protocols they must authenticate each other. Typically EAP is used to
authenticate the peer and the EAP server. Typically AAA protocols
authenticate the authenticator and the AAA server.
Typically secure association protocols run between the peer and
authenticator.
It's common for the EAP layer identities to be different from the
lower layer identities.
There are two types of lower layer identities: those that are used for
authorization and those that are not. AN example of an identity not
used for authorization would be a network that had a concept like a
MAC address that is not used for access control. The MAC address is
used to look up keys, but all people granted access to the network
have the same authorizations. In this case it's not important to make
sure that the peer is claiming a MAC address that is appropriate for
the EAP layer identity of the peer.
However in a network where the MAC address is used to make
authorization decisions, someone needs to make sure that the peer's
EAP identity is authorized to claim the MAC address that it claims.
Typically the AAA server fills this role. However it would be OK to
architect a design where the authenticator filled that role--I don't
think you'd use RADIUS or Diameter in such a design though.
The authenticator probably has a lower layer identity too. The AAA
server needs to authorize this identity to the peer. Typically this
would happen by the AAA server looking at what authenticator the peer
claims it is connecting to, looking at the higher layer identity that
the authenticator is using to communicate to the AAA server and
confirming that the higher layer identity is authorized to claim the
lower layer identity to peers.
It's OK to have things like WLAN switches that are authenticators
including a large number of physical devices. They can have one
higher layer identifier and a lot of lower layer identifiers. They
could potentially also have one lower layer identifier.
Unlike the peer identity, we always assume that the lower layer
authenticator identity needs to be authorized.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf