Hi Sam:

El 18/10/2011, a las 18:55, Sam Hartman escribió:

>>>>>> "Rafa" == Rafa Marin Lopez <[email protected]> writes:
> 
>    Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió:
> 
>>> I think I may have been unclear in what I was proposing.  I'm
>>> proposing that the peer send its identity in the first message
>>> (*) and that the server gets to respond with type 4 or greater (a
>>> specific EAP method).
> 
>    Rafa> Sending its identity does not mean that it must be carried in
>    Rafa> the EAP response/identity. In fact what I suggested is to
>    Rafa> carry the identity in the first message but not contained in
>    Rafa> the EAP response/identity.
> 
> OK. Why not carry it in the EAP response/identity?
> It seems easier than developing new encoding.

Basically EAP is a lock-step protocol where it is required to get a request to 
obtain a response (in the peer side)). So the EAP peer state machine 
implementing the EAP standard protocol will react after receiving an EAP 
request. So I see two options: either you hack the EAP peer state machine to 
return an EAP response/identity without receiving any EAP request/identity 
(this "violates" the standard and so we need to hack the EAP peer state 
machine) or directly at GSS-API level you create a EAP response/identity and 
include the identity (which seems weird taking into account that we have an EAP 
stack in charge of creating EAP messages)

Personally, I do not like either (considering the standard RFC 3748). So, I 
would prefer to define a subtoken for this.

> 
> However it's certainly easy enough to carry it elsewhere. So, if there
> is a reason to do so I'm happy to invent our own subtoken for it.

Good.
> 
> do you support the general concept of an optimization here?

Yes, I do. Certainly, we save two messages between initiator and acceptor. 
Nevertheless, I am not sure how it is the real reduction in time of this 
optimization in contrast with the fact that an EAP authentication may need to 
reach a home EAP/AAA server and may be involve several roundtrips to complete.

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email protected]
-------------------------------------------------------




_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to