📄 rfc2869.txt
字号:
Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server. For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would occur if the message was proxied to a RADIUS Server which does not support the EAP-Message extension. On receiving an Access-Reject, the NAS MUST send an LCP Terminate Request to the authenticating peer, and disconnect.2.3.2. Retransmission As noted in [3], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. Thus if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. As in RADIUS [1], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server. Note that it may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access- Challenge packet.Rigney, et al. Informational [Page 13] RFC 2869 RADIUS Extensions June 2000 If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Message to the dial-in user.2.3.3. Fragmentation Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information.2.3.4. Examples The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior.Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP ACK-EAPauth -> <- PPP EAP-Request/ IdentityPPP EAP-Response/Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP ChallengePPP EAP-Response/OTP, OTPpw ->Rigney, et al. Informational [Page 14] RFC 2869 RADIUS Extensions June 2000 RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-SuccessPPP AuthenticationPhase complete,NCP Phase startsIn the case where the NAS first sends an EAP-Start packet to theRADIUS server, the conversation would appear as follows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP ACK-EAPauth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EA-Request/ IdentityPPP EAP-Response/Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP ChallengePPP EAP-Response/OTP, OTPpw ->Rigney, et al. Informational [Page 15] RFC 2869 RADIUS Extensions June 2000 RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-SuccessPPP AuthenticationPhase complete,NCP Phase startsIn the case where the client fails EAP authentication, theconversation would appear as follows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP ACK-EAPauth -> Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ IdentityPPP EAP-Response/Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP ChallengePPP EAP-Response/OTP, OTPpw -> RADIUS Access-Request/Rigney, et al. Informational [Page 16] RFC 2869 RADIUS Extensions June 2000 EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Reject/ EAP-Message/EAP-Failure <- PPP EAP-Failure (client disconnected)In the case that the RADIUS server or proxy does not supportEAP-Message, the conversation would appear as follows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP ACK-EAPauth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)In the case where the local RADIUS Server does support EAP-Message,but the remote RADIUS Server does not, the conversation would appearas follows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP ACK-EAPauth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ IdentityRigney, et al. Informational [Page 17] RFC 2869 RADIUS Extensions June 2000PPP EAP-Response/Identity(MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS Server) <- PPP LCP Terminate (User Disconnected)In the case where the authenticating peer does not support EAP, butwhere EAP is required for that user, the conversation would appear asfollows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-EAP authPPP LCP NAK-EAPauth -> <- PPP LCP Request-CHAP authPPP LCP ACK-CHAPauth -> <- PPP CHAP ChallengePPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)In the case where the NAS does not support EAP, but where EAP isrequired for that user, the conversation would appear as follows:Authenticating Peer NAS RADIUS Server------------------- --- ------------- <- PPP LCP Request-CHAP authRigney, et al. Informational [Page 18] RFC 2869 RADIUS Extensions June 2000PP LCP ACK-CHAPauth -> <- PPP CHAP ChallengePPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)2.3.5. Alternative uses Currently the conversation between the backend security server and the RADIUS server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Radius vendors and backend security vendors, it is recommended that RADIUS-encapsulated EAP be used for this conversation. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a backend security server instead. In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a backend security server, the security⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -