name: AUTN
full_form: Authentication Token
context: For UMTS subscribers, authentication and key agreement will be performed as follows: - UMTS AKA shall be applied when the user is attached to a UTRAN. - UMTS AKA shall be applied when the user is attached to a GSM BSS, in case the user has a ME capable of UMTS AKA and also the VLR/SGSN is R99+. In this case, the 64-bit GSM cipher key Kc is derived from the UMTS cipher/integrity keys CK and IK, by the VLR/SGSN on the network side and by the USIM on the user side.The 128-bit GSM cipher key Kc128 is derived from the UMTS cipher/integrity keys CK and IK, by the VLR/SGSN on the network side and by the ME on the user side if needed to support 128-bit ciphering algorithms in GSM as described in subclause 6.3.3 of this specification. - GSM AKA shall be applied when the user is attached to a GSM BSS, in case the user has a ME not capable of UMTS AKA. In this case, the GSM user response SRES and the 64-bit GSM cipher key Kc are derived from the UMTS user response RES and the UMTS cipher/integrity keys CK and IK. A R98- VLR/SGSN uses the stored Kc and RES and a R99+ VLR/SGSN derives the SRES from RES and Kc from CK, IK. NOTE: To operate within a ME not capable of UMTS AKA, the USIM may support the SIM-ME interface as defined in GSM 11.11, and support GSM AKA which provides the corresponding GSM functionality for calculating SRES and Kc based on the authentication key K and the 3G authentication algorithm implemented in the USIM. Due to the fact that the UMTS authentication algorithm only computes CK/IK and RES, conversion of CK/IK to Kc shall be achieved by using the conversion function c3, and conversion of RES to SRES by c2. - GSM AKA shall be applied when the user is attached to a GSM BSS, in case the VLR/SGSN is R98-. In this case, the USIM derives the GSM user response SRES and the GSM cipher key Kc from the UMTS user response RES and the UMTS cipher/integrity keys CK, IK. The execution of the UMTS (resp. GSM) AKA results in the establishment of a UMTS (resp. GSM) security context between the user and the serving network domain to which the VLR/SGSN belongs. The user needs to separately establish a security context with each serving network domain. Figure 18 shows the different scenarios that can occur with UMTS subscribers in a mixed network architecture. Figure 18: Authentication and key agreement of UMTS subscribers Note that the UMTS parameters RAND, AUTN and RES are sent transparently through the UTRAN or GSM BSS and that the GSM parameters RAND and SRES are sent transparently through the GSM BSS. In case of a GSM BSS, ciphering is applied in the GSM BSS for services delivered via the MSC/VLR, and by the SGSN for services delivered via the SGSN. In the latter case the GSM cipher keys Kc or Kc128 are not sent to the GSM BSS. In case of a UTRAN, ciphering and integrity are always applied in the RNC, and the UMTS cipher/integrity keys CK an IK are always sent to the RNC.
description: The Authentication Token (AUTN) is a parameter used in the authentication process of UMTS subscribers. It is part of the UMTS security architecture and plays a crucial role in establishing a secure connection between the user equipment and the serving network domain.
explanation: AUTN is classified as a Parameter because it is a specific value used within the context of UMTS authentication, as described in the provided paragraph from 3GPP TS 33.102. It is not a protocol, network function, or interface but rather a key component in the authentication and key agreement process.
section_title: 6.8.1 Authentication and key agreement of UMTS subscribers 6.8.1.1 General
biotag_Context: O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,B-Technology,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,O,B-Technology,B-Protocol,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,B-Network Function,O,O,B-Technology,B-Protocol,O,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,B-Parameter,O,O,O,O,B-Technology,O,O,B-Parameter,O,O,O,O,O,O,O,O,O,O,O,O,B-Device,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,B-Technology,O,O,B-Parameter,O,O,O,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,B-Network,B-Protocol,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,B-Network Function,O,O,O,B-Technology,O,O,O,O,O,B-Network,O,O,B-Parameter,O,O,O,B-Network,O,O,B-Parameter,O,O,O,O,B-Technology,O,O,B-Message,O,O,B-Technology,O,O,B-Parameter,O,O,O,O,O,O,O,O,B-Parameter,O,B-Message,O,O,O,O,O,O,B-Parameter,O,B-Message,O,B-Parameter,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,B-Technology,O,O,B-Device,O,O,O,O,O,O,O,O,B-Network,O,O,O,B-Network,B-Protocol,O,O,O,O,B-Network,O,O,O,B-Parameter,O,B-Parameter,O,O,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,B-Parameter,O,O,O,O,O,O,O,O,O,O,O,O,B-Message,O,B-Parameter,O,O,O,B-Network,B-Protocol,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,O,O,B-Device,O,O,B-Network,O,O,B-Parameter,O,O,B-Network,O,O,B-Parameter,O,O,B-Technology,O,O,B-Message,O,O,B-Technology,O,O,O,O,O,O,O,O,B-Technology,O,O,B-Protocol,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Technology,O,O,O,O,B-Technology,O,O,B-Parameter,O,B-Message,O,O,O,O,O,B-Network,O,B-Network,B-Network Function,O,O,O,B-Network,O,B-Parameter,O,B-Parameter,O,O,O,O,O,B-Network,O,O,O,O,O,B-Network,O,O,O,O,O,O,B-Network,B-Network Function,O,O,O,O,O,O,O,O,O,B-Network Function,O,O,O,O,O,O,O,O,O,O,O,B-Network,O,O,B-Parameter,O,O,O,O,O,O,O,B-Network,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,B-Technology,O,O,B-Parameter,O,B-Parameter,O,O,O,O,O,O
biotag_Description: O,B-Parameter,I-Parameter,O,O,O,O,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,B-Technology,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O,O