|This article has multiple issues. Please help improve it or discuss these issues on the talk page.
|This article does not cite any references or sources. (September 2008)
CAVE-based Authentication (a.k.a. HLR Authentication, 2G Authentication, Access Authentication) is an access authentication used in CDMA/1xRTT network systems.
CAVE (Cellular Authentication and Voice Encryption)
- 1 CAVE (Cellular Authentication and Voice Encryption)
- 2 See also
- 3 External links
- 4 References
There are two network entities involved in CAVE-based authentication when roaming:
- Authentication Center (AC) a.k.a. HLR/AC, AuC – Located in a roamer’s home network, the AC controls the authentication process and either authenticates the Mobile Station (Mobile Phone, MS) or shares SSD with the serving VLR to allow this authentication to occur locally. The AC must be provisioned with an A-key value for each MS. Authentication is predicated on the assumption that A-key value provisioned in an MS is the same as the A-key value provisioned in the AC. The AC is often co-located with the HLR and referred to as the HLR/AC. However, the AC could be a standalone network entity that serves one or more HLRs. Though the CDMA abbreviation is AC, the GSM abbreviation of AuC is sometimes used (albeit incorrectly in CDMA networks).
- Visitor Location Register (VLR) – If SSD is shared with the visited network, the VLR locally authenticates the roamer. Otherwise, the VLR proxies authentication responses from roamers to their home HLR/AC for authentication.
The authentication controller is the entity that determines whether the response from the MS is correct. Depending upon whether SSD is shared, the authentication controller may be either the AC or VLR. In either case, CAVE-based authentication is based on the CAVE algorithm and the following two shared keys:
- Authentication key (A-key) – A 64-bit primary secret key known only to the MS and AC. In the case of RUIM equipped mobiles, the A-key is stored on the RUIM; otherwise, it is stored in semi-permanent memory on the MS. The A-key is never shared with roaming partners. However, it is used to generate a secondary key known as SSD that may be shared with a roaming partner to enable local authentication in the visited network.
- Shared Secret Data (SSD) – A 128-bit secondary secret key that is calculated using the CAVE algorithm during an SSD Update procedure. During this procedure both MS and the AC in the user’s home network separately calculate SSD. It is this SSD, not the A-key that is used during authentication. SSD may or may not be shared between home and roaming partner networks to enable local authentication. SSD consists of two 64-bit keys: SSD_A, which is used during authentication to calculate authentication signatures, and SSD_B, which is used in the generation of session keys for encryption and voice privacy.
CAVE-based authentication provides two types of challenges
- Global challenge – Procedure that requires any MS attempting to access the serving network to respond to a common challenge value being broadcast in the overhead message train. The MS must generate an authentication signature response (AUTHR) using CAVE with inputs of the global challenge value, ESN, either the last six dialed digits (for an origination attempt) or IMSI_S1 (for any other system access attempt), and SSD_A.
- Unique challenge – Procedure that allows a visited network (if SSD is shared) and/or home network to uniquely challenge a particular MS for any reason. The MS must generate an authentication signature response (AUTHU) using CAVE with inputs of the unique challenge value, ESN, IMSI_S1, and SSD_A.
CAVE-based authentication is a one-way authentication mechanism that always involves the network authenticating the MS (with the exception of the base station challenge procedure that occurs only during an SSD update).
CAVE based authentication procedures are specified in TIA-41 (3GPP2 X.S0004).
- CDMA Development Group website
- BSD Authentication (BSD Auth)
- Common Data Security Architecture (CDSA)
- Generic Security Services API (GSSAPI)
- Java Authentication and Authorization Service (JAAS)
- Novell Modular Authentication Service (NMAS)
- OpenID Connect (OIDC)
- Pluggable Authentication Modules (PAM)
- Simple Authentication and Security Layer (SASL)
- Security Support Provider Interface (SSPI)
- XCert Universal Database API (XUDA)
- Challenge-Handshake Authentication Protocol (CHAP)
- Central Authentication Service (CAS)
- Extensible Authentication Protocol (EAP)
- Host Identity Protocol (HIP)
- LAN Manager
- NT LAN Manager (NTLM)
- Password-authenticated key agreement protocols
- Password Authentication Protocol (PAP)
- Protected Extensible Authentication Protocol (PEAP)
- Remote Access Dial In User Service (RADIUS)
- Resource Access Control Facility (RACF)
- Secure Remote Password protocol (SRP)
- TACACS and TACACS+
- RFID-Authentication Protocols