Please replace RADIUS Access-Challenge by RADIUS Access-Request in the sentence of my previous e-mail
"In other words, once the acceptor knows the peer's identity can send that EAP-start message in a RADIUS Access-Challenge..." Best regards. El 19/10/2011, a las 11:28, Rafa Marin Lopez escribió: > Hi Sam: > > El 19/10/2011, a las 00:23, Sam Hartman escribió: > >>>>>>> "Rafa" == Rafa Marin Lopez <[email protected]> writes: >> >> Rafa> 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. >> >> Rafa> Basically EAP is a lock-step protocol where it is required to >> Rafa> get a request to obtain a response (in the peer side)). So the >> Rafa> EAP peer state machine implementing the EAP standard protocol >> Rafa> will react after receiving an EAP request. So I see two >> Rafa> options: either you hack the EAP peer state machine to return >> Rafa> an EAP response/identity without receiving any EAP >> Rafa> request/identity (this "violates" the standard and so we need >> Rafa> to hack the EAP peer state machine) >> >> Or the initiator synthesizes a request and feeds it to the peer's state >> machine. > > Yes, this is another option, though I don't like either. The reason is > simple. AFAIK, the standard EAP does not say anything about a EAP lower-layer > synthesizing a request (which sounds like another type of hack). EAP requests > are sent by the authenticator. This is what the standard says. > >> >> IN our implementation, even if the IETF decides on an an alternate >> encoding for the identity, we'll end up synthesizing an identity request >> and doing something with the identity response. >> >> With a standard EAP library that is lock-step in the manner you >> describe, it's far easier to produce a synthetic identity request in the >> initiator than to hack the state machine or do anything else. > > As I said synthesizing an EAP request is another type of hack, because the > EAP protocol does not work like that. We have a RFC 3748 and RFC 5247 where > the EAP protocol is defined. I believe it would be good if we follow the > standards. > >> Think of >> it this way. In GSS-EAP, the identity request is generated by a party >> very close to the initiator. EAP already supports the identity request >> being generated by a different party than the actual EAP messages. Why >> does it matter whether the request comes from inside the peer or from a >> NAS? > > > Regarding this, you need to think about the mode independence property of EAP > where: > > "As far as the EAP peer is concerned, its conversation with the EAP > authenticator, and all > consequences of that conversation, are identical, regardless of the > authenticator mode of operation." > > In other words, under peer standpoint, all EAP requests are coming from the > EAP authenticator (the peer does not know and do not care if there is a > backend EAP server or it is integrated with the authenticator). > > >> >> >> Rafa> or directly at GSS-API >> Rafa> level you create a EAP response/identity and include the >> Rafa> identity (which seems weird taking into account that we have >> Rafa> an EAP stack in charge of creating EAP messages) >> >> But if you don't create an EAP response/identity on the initiator you >> probably do have to do it on the acceptor to trigger AAA to use EAP. > > I don't think you need to do that. As I explained in the previous e-mail, in > RADIUS EAP (RFC 3579) you can find this text: > > "Rather than sending an initial EAP-Request packet to the > authenticating peer, on detecting the presence of the peer, the NAS > MAY send an Access-Request packet to the RADIUS server containing an > EAP-Message attribute signifying EAP-Start. The RADIUS server will > typically respond with an Access-Challenge containing EAP-Message > attribute(s) encapsulating an EAP-Request/Identity (Type 1). > However, an EAP-Request for an authentication method (Type 4 or > greater) can also be sent by the server. > > EAP-Start is indicated by sending an EAP-Message attribute with a > length of 2 (no data)." > > > In other words, once the acceptor knows the peer's identity can send that > EAP-start message in a RADIUS Access-Challenge. Moreover it should include > the user-name in the request. With that, the RADIUS EAP server should start > the EAP method selected for that peer. > > >> >> Rafa> Personally, I do not like either (considering the standard RFC >> Rafa> 3748). So, I would prefer to define a subtoken for this. >> >> We can do that. It means faking up an identity response on the >> acceptor. But that is certainly not a big deal. > > As explained, you do not need to fake up any identity response on the > acceptor. Just follow what RFC 3579 says. > >> >> --Sam > > ------------------------------------------------------- > 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] > ------------------------------------------------------- > > > > ------------------------------------------------------- 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
