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@xxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf