Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Sam Hartman <hartmans-ietf@mit.edu> Fri, 30 March 2007 17:52 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLHG-0001Ks-Ly; Fri, 30 Mar 2007 13:52:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLHE-0001Kc-47 for ietf@ietf.org; Fri, 30 Mar 2007 13:52:40 -0400
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXLHC-0006r6-S0 for ietf@ietf.org; Fri, 30 Mar 2007 13:52:40 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 25035E006D; Fri, 30 Mar 2007 13:52:26 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Bernard Aboba <bernarda@windows.microsoft.com>, "Dondeti, Lakshminath" <ldondeti@qualcomm.com>, Dan Harkins <dharkins@lounge.org>, ietf@ietf.org
References: <41825.12.108.168.179.1171660575.squirrel@www.trepanning.net> <tslwt2hiybm.fsf@cz.mit.edu> <C24CB51D5AA800449982D9BCB90325134F192B@NAEX13.na.qualcomm.com> <tslfy947pol.fsf@cz.mit.edu> <45D73CEB.2000701@qualcomm.com> <C24CB51D5AA800449982D9BCB90325134F192D@NAEX13.na.qualcomm.com> <0C7B902B470A264FA64D66CBF76FB821014CD3F6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <C24CB51D5AA800449982D9BCB90325134F1947@NAEX13.na.qualcomm.com>
Date: Fri, 30 Mar 2007 13:52:26 -0400
In-Reply-To: <C24CB51D5AA800449982D9BCB90325134F1947@NAEX13.na.qualcomm.com> (Vidya Narayanan's message of "Mon, 19 Feb 2007 21:19:03 -0800")
Message-ID: <tsld52qipph.fsf_-_@cz.mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc:
Subject: Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Sam Hartman
- RE: comments on draft-houseley-aaa-key-mgmt-07.txt Narayanan, Vidya
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Sam Hartman
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Lakshminath Dondeti
- RE: comments on draft-houseley-aaa-key-mgmt-07.txt Narayanan, Vidya
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Lakshminath Dondeti
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Yoshihiro Ohba
- RE: comments on draft-houseley-aaa-key-mgmt-07.txt Narayanan, Vidya
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Sam Hartman
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Yoshihiro Ohba
- Re: comments on draft-houseley-aaa-key-mgmt-07.txt Lakshminath Dondeti
- RE: comments on draft-houseley-aaa-key-mgmt-07.txt Narayanan, Vidya
- RE: comments on draft-houseley-aaa-key-mgmt-07.txt Dan Harkins
- comments on draft-houseley-aaa-key-mgmt-07.txt Dan Harkins
- [Dan Harkins] comments on draft-houseley-aaa-key-… Sam Hartman
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Dan Harkins
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Sam Hartman
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Lakshminath Dondeti
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Dan Harkins
- RE: [Dan Harkins] comments on draft-houseley-aaa-… Narayanan, Vidya
- RE: [Dan Harkins] comments on draft-houseley-aaa-… Dan Harkins
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Lakshminath Dondeti
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Dan Harkins
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Lakshminath Dondeti
- RE: [Dan Harkins] comments on draft-houseley-aaa-… Narayanan, Vidya
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Dan Harkins
- Re: [Dan Harkins] comments on draft-houseley-aaa-… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Dan Harkins
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Dan Harkins
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Dan Harkins
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- Re: [consensus] comments on draft-housley-aaa-key… Sam Hartman
- RE: [consensus] comments on draft-housley-aaa-key… Bernard Aboba
- RE: [consensus] comments on draft-housley-aaa-key… Bernard Aboba