HP-UX AAA Server A.08.02.10 Administrator's Guide HP-UX 11i v3 (T1428-90093, November 2013)

The EAP-AKA uses an example algorithm for key generation that can be customized or replaced
with operator specific key generation algorithm.
EAP-AKA includes optional identity privacy support, wherein the supplicant can send a temporary
(pseudonym) identity instead of using the clear text permanent identity to prevent eavesdroppers.
In such cases the HP-UX AAA Server has to do a lookup of the Real user name i.e the permanent
identity on receiving the pseudonym identity. The mapping of the permanent identity with the
pseudonym and vice versa can be done using algorithms built inside the Server or using an external
storage like SQL compliant database with the mapping information.
EAP-AKA also includes optional fast re-authentication support, wherein the previously generated
Master Session Key during full authentication process will be used to generate a fresh Master
Session Key. A supplicant requesting the fast re-authentication will send the fast re-authentication
identity got during previous full authentication. The HP-UX AAA Server internally maps the fast
re-authentication identity to the permanent identity either using an optional internal cache or using
an external storage like SQL compliant database with the mapping information.
NOTE: The HP-UX AAA Server can also generate the AV.
Features
The EAP-AKA authentication method is fully compliant with RFC 4187. It supports the following
features:
• IMSI permanent identities are supported on a per realm basis.
• Non-IMSI permanent identities are supported on a per realm basis.
• Protected success indications are supported on a per realm basis.
• Fast re-authentication is supported on a per realm basis.
• Protected Identity Exchanges using AT_CHECKCODE is supported on a per realm basis.
• Authentication Management Field (AMF) is supported on a per realm basis.
• Algorithmically or randomly generated pseudonyms are supported on a per realm basis.
• To ensure that permanent user names, pseudonyms, and fast re-authentication user names are
distinct and can be easily distinguished from one another, the server generates pseudonyms
with the leading character 4 and fast re-authentication user names with the leading character
5. In accordance with the RFC, permanent user names derived from the IMSI are prefixed
with the leading character 0.
• A user's subscriber key, Ki, sequence number, mode, and the name of the appropriate AKA
algorithms, can be stored in an external database or a local file. The server automatically
generates the authentication vector from this information.
• An authentication vector can be stored in a local file. This is intended for use in a lab
environment, and requires no additional user-written plug-ins.
• The user credentials can be retrieved from an AuC if the customer implements an AATV, which
communicates with the AuC.
• AKA 3GPP Milenage algorithms are provided with parameters that can be configured.
• The Milenage AKA algorithm can be customized with a simple plug-in.
• Additional AKA algorithms provided by the customer can be plugged into the server.
• Occurrences and values of received AKA attributes are validated.
• Support for pseudonym and fast re-authentication identity mapping is built-in, without the need
for an external database.
EAP-AKA 171