>>>>> "Alan" == Alan DeKok <[log in to unmask]> writes:
Alan> Sam Hartman wrote:
>> There is an additional concern. At this point in the process, we
>> have not learned the identity of the peer.
Alan> I don't know the full details of the IEEE EAPoL state
Alan> machine, but IIRC, there are provisions for an Access-Point to
Alan> send an EAP identity request. The peer should then respond
Alan> with an identity that contains a realm.
At this point in the GSS exchange, we've not committed to using EAP.
At the GSS layer, you can't commit to a particular way of describing the
initiator (peer)'s identity until you've committed to a particular
mechanism.
You're right though that there are no technical problems here. The
analysis document proposes simply that we need to rethink how GSS deals
with negotiation. The draft GSS mechanism solves this issue by
requiring the client to commit to using EAP before deciding what EAP
method to use.
At that point, all these issues go away, and the typical EAP solutions
apply.
As I've discussed this issue with members of the GSS community, they
tend to agree that while GSS normally discourages multi-layer
negotiation, that performing a multi-layer negotiation is exactly the
right approach here. One reason advanced for this is that the
negotiations are with different parties. The initiator and acceptor
(NAS) decide to use EAP; the peer (initiator) and EAP server decide what
EAP method to use.
--Sam
|