Hi Sam:
>
> Rafa> It is just a matter to be coherent with each part. If the EAP
> Rafa> authentication is successful why do not to state so?
>
> Because it's none of the peer's business whether the access is being
> denied for an authorization or authentication reason.
Not sure if I agree with that in all use cases...
> Also, peers have
> to be able to deal with the case where the EAP message is absent, so
> that code path is going to be better tested.
Following that reasoning, perhaps we should consider both options since they
may be both possible. If the EAP server sends the EAP success
("Access-Reject/EAP-Message/EAP Success" case) I think the acceptor should not
remove the EAP success and send it to the initiator. In fact, the acceptor as
EAP authenticator should not care about what the EAP server is sending to the
EAP peer, and just paying attention to what the AAA server is sending to the
acceptor via AAA protocol. If we have "Access-Reject/no EAP-Message attribute"
case the initiator will not receive the EAP success. But this is not
problematic either, due to the initiator can send an AltReject to the EAP peer
state machine (due to Authorization failed error code is set) to stop it and
inform about such situation.
In conclusion, if you think that by not sending the EAP success to the
initiator will simplify implementations, that is fine with me. Although it
would be interesting to know if existing RADIUS server implementations will
support any of the cases :).
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
