Hi Sam: El 18/10/2011, a las 15:56, Sam Hartman escribió:
> [EMU copied for EAP input] > > Here in ABFAB, we're designing a new EAP lower layer for applications to > use for authentication. We're using the GSS-API (RFC 2743) as our > application integration point. > > Currently, our lower layer is kind of chatty. The peer sends a first > message that roughly says "Hi, I'd like to authenticate." Then the > authenticator sends an identity request EAP message. Then the peer sends > an identity response. Then the authenticator (probably after an AAA > interaction) respons with the first EAP method message. > > As best we can tell that round trip is unneeded. We could instead > include an unsolicited identity response in our first message from the > peer to authenticator and get a request with an EAP method message from > the first message from the authenticator. According to RFC 3579 (section 2.1) that would be possible in certain cases: "This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up." Alternatively, what I believe you can also do is to allow the peer send information (probably peer's identity) to the authenticator out of EAP (within GSS token). This information allows AAA client to reach the EAP/AAA server that handles the peer's credentials. Then the EAP/AAA server can start directly the preferred EAP method for that peer. What I am trying to say corresponds with something similar to the first figure of section 2.2 in RFC 4072. In RFC 3579 you can also 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." Between both choices, it seems that second one gives the EAP/AAA server the opportunity to start directly with the selected EAP method from a pool of them. First choice, always starts with a particular EAP method (implemented in the Acceptor) that it may not be supported by the (home) EAP/AAA server or not the preferred one by the server for that peer. Hope this helps. > > We can't see any down side of this. There seems to be nothing in the > identity request. We already have another approach for "network > selection." If you want to know who your authenticator is in order to > decide on an identity, we have a lower-layer specific mechanism for > that. > > I'd appreciate any comments. From ABFAB participants, do we want to make > this optimization? From EMU participants are we missing anything? > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- 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
