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

["Dan Harkins" <[e-mail]>]

  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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf