![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
When I originally sent out the consensus call on draft-housley-aaa-key-mgmt, I managed to get a couple of details wrong. Russ and bernard helped me try and fix my understand and here is where I think we are. I believe now we're just left with the question of whether the draft says what we mean it to say. Hopefully Bernard and Russ will get back to us on that soon.
--- Begin Message ---
- To: "Bernard Aboba" <bernarda at windows.microsoft.com>, housley at vigilsec.com
- Subject: Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
- From: Sam Hartman <hartmans-ietf at mit.edu>
- Date: Tue, 03 Apr 2007 20:13:50 -0400
- Cc: "Dondeti, Lakshminath" <ldondeti at qualcomm.com>, Dan Harkins <dharkins at lounge.org>,
- In-reply-to: <tsld52qipph.fsf_-_@cz.mit.edu> (Sam Hartman's message of "Fri, 30 Mar 2007 13:52:26 -0400")
- 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> <tsld52qipph.fsf_-_@cz.mit.edu>
- User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
- Xref: cz.mit.edu misc-mail:18181
[ietf list trimmed to make sure I get this right; then I will forward] >>>>> "Sam" == Sam Hartman <hartmans-ietf at mit.edu> writes: Sam> There are two types of lower layer identities: those that are Sam> used for authorization and those that are not. AN example of Sam> an identity not used for authorization would be a network Sam> that had a concept like a MAC address that is not used for Sam> access control. The MAC address is used to look up keys, but Sam> all people granted access to the network have the same Sam> authorizations. In this case it's not important to make sure Sam> that the peer is claiming a MAC address that is appropriate Sam> for the EAP layer identity of the peer. Sam> However in a network where the MAC address is used to make Sam> authorization decisions, someone needs to make sure that the Sam> peer's EAP identity is authorized to claim the MAC address Sam> that it claims. Typically the AAA server fills this role. Sam> However it would be OK to architect a design where the Sam> authenticator filled that role--I don't think you'd use Sam> RADIUS or Diameter in such a design though. Sam> The authenticator probably has a lower layer identity too. Sam> The AAA server needs to authorize this identity to the Sam> peer. Typically this would happen by the AAA server looking Sam> at what authenticator the peer claims it is connecting to, Sam> looking at the higher layer identity that the authenticator Sam> is using to communicate to the AAA server and confirming that Sam> the higher layer identity is authorized to claim the lower Sam> layer identity to peers. This claim is problematic because the AAA server may not be involved in some fast handoff situations. A better statement for this is that The authenticator probably has a lower layer identity too. This identity needs to be authorized to the peer too. The authenticator cannot perform this task because it is the entity being authorized. The peer does not have the necessary information to perform this task. Often the AAA server can authorize the authenticator to the peer. Alternatively some other party already trusted by the peer to act as an introducer can authorize an authenticator For example, in some handoff situations, entity co-resident with an authenticator that has already been authorized may authorize other authenticators.
--- End Message ---
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.