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

Sam Hartman <hartmans-ietf@mit.edu> Fri, 06 April 2007 17:46 UTC

From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org
Date: Fri, 06 Apr 2007 13:46:42 -0400
Message-ID: <tsl7ispief1.fsf@cz.mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Cc: bernarda@microsoft.com
Subject: [Sam Hartman] Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
Precedence: list
Errors-To: ietf-bounces@ietf.org


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 ---

[ietf list trimmed to make sure I get this right; then I will forward]

>>>>> "Sam" == Sam Hartman <hartmans-ietf@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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

[Sam Hartman] Re: [consensus] comments on draft-h… Sam Hartman