Hi all: Just one comment. In RFC 3579 (section 2.6.3), there is text about conflicting messages. I believe we are discussing these two cases:
Access-Reject/EAP-Message/EAP Success Access-Reject/no EAP-Message attribute (or even Access-Reject/EAP-Start being EAP-Start an empty EAP attribute) These cases are NOT recommended in that section. Reasoning is given in the text and are different for each case: For the Access-Reject/EAP-Message/EAP Success case: "For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully." For Access-Reject/no EAP-Message attribute "If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access." However I believe that, with GSS-EAP, these cases (and the consequent confusion) could be easily solved. When the acceptor receives an Access-Reject it should inform the initiator about an authorization problem. This could be done by defining an error code Authorization failed in GSS-EAP (maybe existing error codes could be used for that). In other words, as long as the initiator does not get confused , then both cases are ok. Personally, I would send a GSS token with the EAP Success and the error code Authorization failed to the initiator. This would allow the initiator to know that authentication was ok but authorization failed. Thus, the initiator does not get confused at all about what happened. Also, some insights from RADIUS server developers are important so that we can see how RADIUS server typically do (e.g. whether they allow Access-Reject/EAP-Message/EAP Success or Access-Reject/no EAP-Message attribute) My 0.02 cents. El 15/03/2012, a las 15:28, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes: > > > I think we're in general agreement. > > Alejandro> I mean, we are using RADIUS to transport both EAP and > Alejandro> SAML. If the conjunction of a SAML failure and a EAP > Alejandro> success should have the result of denial of access > Alejandro> (because of the failure in the authorization), then an > Alejandro> Access-Reject should be sent. Now, I have to admint that > Alejandro> I don't really know if it is possible to send an > Alejandro> EAP-Success packet within an Access-Reject RADIUS > Alejandro> message. But tricking the EAP stack to force the EAP > Alejandro> method to fail even when the method was actually > Alejandro> successful does not sound very well either. What do you > Alejandro> think? > > > In this case my preference would be to send no EAP message back at all > but only to send an access-reject possibly with the SAML failure. > > --Sam > _______________________________________________ > 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
