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] ------------------------------------------------------- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
