RADIUS Interaction for Authentication

The RADIUS server supports various methods to authenticate the user. When the server is provided with the username and original password of the user, it can support Point-to-Point Protocol (PPP), Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), or Microsoft CHAP (MSCHAP), UNIX login, and other authentication methods.

In releases prior to 2021.01.0: The SMF uses only MSISDN values for user authentication.

In release 2021.01.0 and later: The SMF supports user authentication using PAP, CHAP, or MSCHAP protocol. The SMF configuration aids in the protocol selection for the user authentication. If the secondary authentication is enabled in DNN profile, the SMF interacts with the RADIUS server to perform RADIUS authentication. To implement the authentication, the RADIUS client residing within the SMF sends the User-Name and User-Password attributes in Access-Request message to the RADIUS server.

The SMF uses more attributes to facilitate the RADIUS authentication function. For the complete list of attributes supported, see the RADIUS Attribute Definition section.

The RADIUS server validates the user with the authentication information. If the validation is successful, the server sends the Access-Accept response to the SMF.

PAP-, CHAP-, MSCHAP-based Authentication

The SMF decodes the Protocol Configuration Options (PCO), Extended PCO (ePCO), or Additional PCO (APCO) IE received from UE. Then, the SMF retrieves the values related to PAP (User Name and Password), CHAP (Challenge and Response), or MSCHAP (Challenge and Response) from the IE. If any of the protocols have higher precedence in configured priority under DNN, the SMF sends the received values in RADIUS Access-Request message to the RADIUS server.

Note

The SMF does not include the authentication information received from the UE in the RADIUS Access-Request message if the priority is not configured.

By default, the SMF uses the configured host password under DNN for authentication until additional configuration is enabled to use the password received in PCO, ePCO, or APCO. The SMF allows the operator to configure the host password at DNN profile either in plain-text or encrypted form and always displays the same in encrypted format only wherever applicable.

The SMF sends MSISDN as the User Name if the UE does not provide the username explicitly in PCO IE for PAP-based authentication.

For CHAP-based authentication, the SMF converts the received CHAP Challenge and Response to MSCHAP if the convert-to-mschap command option is enabled, CHAP is enabled, and the received CHAP Response length is 49 bytes. By default, the SMF uses MSCHAPv1 as the authentication algorithm.

For MSCHAP-based authentication, the SMF sends User Name, Challenge, and Response received in PCO to the RADIUS server if Protocol ID is LCP and LCP container specifies the algorithm as CHAP/MSCHAPv1 (128) as per RFC 2433 or CHAP/MSCHAPv2 (129) as per RFC 2795.

The SMF forwards the authentication information from RADIUS server to UE in Create-Session-Response PCO/EPCO/APCO IE for a 4G/Wi-Fi session, and in N1 Container EPCO IE for a 5G session.

Consider the following important points while implementing the RADIUS authentication functionality.

  • Perform the length validation of different AVPs applicable for this feature based on RFC 2865. Also, reject the authentication if any violation is identified.

    • The minimum length of CHAP Challenge is 5 bytes (even though it is 1 byte as per RFC 1334 and RFC 1994).

  • The SMF sends the received authentication information from UE to RADIUS server based on the configured authentication algorithm at DNN level. The SMF does not manipulate any data received from UE and it only applies the configurations related to authentication before sending the information to RADIUS server.

  • The SMF does not validate the use case of incrementing the Identifier value for every authentication as it does not allow multiple authentication during the PDU session lifetime.

  • The SMF sends the encrypted NULL (empty) password in Access-Request when it receives empty password from UE and no host level password configured at SMF or password-use-pco option is enabled.

  • The SMF falls back to the default authentication where Access-Request carries the configured server secret as User Password in the following scenarios:

    • If none of the algorithm preference is enabled with priority

    • If the UE provided information is not applicable for the configured algorithm preferences, if any

    • When the UE sends the empty PAP or CHAP containers without any data (the container length is 0)

  • The SMF rejects the authentication in the following scenarios:

    • When there is no other algorithm configured for authentication

    • Whenever there is a mismatch in CHAP identifier received in both CHAP Challenge and CHAP Response containers (the SMF currently copies the CHAP-ID from CHAP Challenge container)

      • CHAP-ID in CHAP Password must be taken from CHAP Response as per RFC 2865.

      • Response Identifier must be copied from the Identifier field of the Challenge Response as per RFC 1334.

      • Whenever the validation criteria of the current algorithm fails

  • The SMF allows to configure the same priority through CLI for different algorithms because configuring 0 explicitly disables the configuration. In this scenario, any one of the algorithms is considered and the selection is purely implementation dependent. It is the responsibility of operator to ensure different algorithms have different priorities to resolve the conflicts whenever UE sends multiple authentication containers to the SMF.

  • The SMF allows to configure the password-use-pco option without configuring PAP due to the limitation of Yang defined syntax format. The same is applicable for convert-to-mschap option. But the functionality will work only if the corresponding algorithm is enabled with the valid priority.

  • By default, the SMF encrypts the operator given Host level password using AES-128-CFB encryption algorithm, if it’s a plain-text. It ignores the encryption if the operator gives the already encrypted password which has to meet the AES-128-CFB encryption standard.

  • By default, the SMF considers the authentication algorithm as MSCHAPv1(128) whenever the received CHAP Challenge and Response converted to MSCHAP if received CHAP-Response length is 49 bytes and convert-to-mschap option is enabled.

  • The following are the list of MSCHAP specific AVPs supported at SMF and its RFC references:

    • MSCHAP-CHALLENGE (MSCHAP)  RFC2548 Section 2.1.2

    • MSCHAP-RESPONSE  RFC2548 Section 2.1.3

    • MSCHAP2-RESPONSE  RFC2548 Section 2.3.2

    • MSCHAP-ERROR  RFC2548 Section 2.1.5

    • MS-CHAP2-Success (RFC 2548, Section 2.3.3) is not supported as there is no clear information on MS-CHAP success AVP for v1 in RFC 2548.

  • When the RADIUS server sends both MSCHAP-Error and Reply-Message AVPs in Access-Reject message, the preference is given to MSCHAP-ERROR while filling the CHAP container for NACK in PCO/APCO/EPCO. MSCHAP-Error is common for both MSCHAPv1 and MSCHAPv2 algorithm and it is encapsulated in the Message field of the CHAP Failure container.

  • In MSCHAP, only the authentication functionality is supported.

Important

The SMF uses the inbuilt encryption algorithm “AES-128-CFB” for encrypting the host level password (outbound password) provided by NETCONF-YANG data model. The SMF Ops Center creates a global key, for AES-128-CFB encryption, which is used for encrypting the operator given plain-text password. It shares the key with all the pods via SSH for decrypting the encrypted data in the respective pods. The key is exported as a ENV variable “CONFD_AES_KEY” in SMF-SERVICE pod. If the operator wishes to configure the already encrypted password, then the AES-CFB-128 encrypted string should be prefixed with “$8$” as follows, $8$<encrypted-data> to indicate that the given input is already AES-128-CFB encrypted string to NETCONF-YANG model.

For CLI details associated with authentication, see the Configuring the RADIUS Client section.