RADIUS Specific Authentication

RADIUS specific authentication can be divided into two parts. The first one takes place before Common authentication process, the second one - after this process. RADIUS specific authentication is not executed if IRADIUSAuthentication interface is not implemented by server extension, and only then common authentication is performed.

First, it is checked if the packet is returned as a response to a previously issued Challenge-Response packet (determined by State attribute present in the packet). If it's true:

• EAP-Message attribute is looked for.
  If this attribute is present in the packet, but IEAP interface is not supported by server extension, ClearBox Server performs EAP-MD5 authentication. As the request packet contains State attribute, it means that the EAP message in the packet is MD5 response. Server calls ICommonAuthentication::GetUserPassword to get user password. If it's not available in clear text form or user was not found by his name, ICommonAuthentication::LogonStatus is called with authRes parameter set to AR_NOUSER or AR_NOPWD respectively, and authentication result is ACCESS_REJECT. Then server generates a MD5 response from its original challenge and its copy of user password it just has received. If they are not equal, user is rejected with ACCESS_REJECT and ICommonAuthentication::LogonStatus is called with authRes set to AR_WRONGPWD. If they are equal, server goes to the next step.
  
  If IEAP interface is supported, ClearBox Server combines all EAP-Message attributes into one array of bytes and passes it to IEAP::ProcessMessage method, which returns authentication result (ACCESS_ACCEPT/ ACCESS_CHALLENGE/ ACCESS_REJECT) and list of attributes to be put into response packet. Authentication result returned by this method is sent back as access code (ACCESS_ACCEPT/ ACCESS_CHALLENGE/ ACCESS_REJECT) to the RADIUS client.
• If the access-request packet is sent by NAS as a response to the previously issued Access-Challenge packet, then server calls IRADIUSAuthentication::ChallengeDataReply method of server extension and passes it an attribute that server extension has requested in IRADIUSAuthentication::GetChallengeResponseAttributes method implementation. This method returns authentication result (ACCESS_ACCEPT/ ACCESS_CHALLENGE/ ACCESS_REJECT).

If authentication result (ACCESS_ACCEPT/ACCESS_CHALLENGE/ACCESS_REJECT) has not been received then

Common authentication process begins. Authentication method is defined by attributes found in the packet. If none of known methods was found, user is rejected (ACCESS_REJECT).

Some changes are made in this process to perform EAP authentication. If at this point there's an Access-Request packet with EAP message embedded, this means that it's initiating EAP/Identity response from the authenticated peer (client).
- If IEAP interface is implemented by the server extension then the authentication result is determined by IEAP::ProcessMessage return value.
- If is not implemented, then the server generates MD5 challenge, so authentication result is ACCESS_CHALLENGE.

If user was accepted then IRADIUSAuthentication::CanAuthenticate is called if IRADIUSAuthentication interface is implemented by server extension. The final authentication result is received:

• If ACCESS_REJECT value is returned by this method, ICommonAuthentication::LogonStatus is called with AR_EXTNDRREJ as authRes parameter. If server extension implements IRADIUSAuthentication then IRADIUSAuthentication::GetRejectResponseAttributes is called. Finally, user is rejected.
• If ACCESS_CHALLENGE value is returned, IRADIUSAuthentication::GetChallengeResponseAttributes is called to get list of attributes which should be put into challenge-response packet.
• If ACCESS_ACCEPT value is returned, ICommonAuthentication::LogonStatus is called with AR_OK as authRes parameter, and user is accepted (but may be rejected in authorization stage later, see RADIUS authorization).

See Also

Authentication concepts, RADIUS concepts