
:toc:



= EAP-SIM/EAP-AKA/EAP-AKA-Prime policy server

This server is an example of applying custom, site-specific policies
to eap-aka['] based authentication.
As much control is given to the user to make decisions about which
AT_* attributes will be returned to the supplicant. Wherever
possible the internal state of the EAP-AKA module will be updated
to reflect the attributes returned from sections.



## Packet Processing sections

Sections in this server may behave slightly differently to sections
in other virtual servers, as they're being called directly by the
EAP-AKA module.

In general, the following rcodes signify a failure to the EAP-AKA
state machine:

- `reject`
- `fail`
- `invalid`
- `userlock`

Returning failure rcodes in the majority of sections will caused the
authentication to fail.

In some instances however, we ignore the section rcode, as the standard
does not allow for an orderly rejection of the supplicant.

Returning failure rcodes will be ignored in the following sections, and
will instead generate a warning:

- `send EAP-Failure`			already rejecting the auth attempt.
- `send Failure-Notification`	already rejecting the auth attempt.
- `recv Failure-Notification`	already rejecting the auth attempt.
- `recv Success-Notification`	sending failure after EAP-Response/
- `recv Authentication-Reject`	already rejecting the auth attempt.
- `recv Client-Error`		already rejecting the auth attempt.
- `clear pseudonym`			nothing more we can do...
- `clear session`			nothing more we can do...

For sections dealing with identity processing the `notfound` rcode
will trigger identity negotiation. The EAP-AKA module will then request
additional identity values from the supplicant.  See the `recv
EAP-Identity-Response` and `recv AKA-Identity-Response` sections for more
details.

NOTE: Setting the EAP-AKA subtype attribute is not supported, and any
attempts to modify it will be ignored (you are not trusted to know how to
run the EAP-AKA state machine better than the EAP-AKA module).



This is a unified configuration example for EAP-SIM, EAP-AKA
and EAP-AKA-Prime.  Many of the sections are identical between
the three EAP methods.

The main differences are between EAP-SIM and EAP-AKA['] where
additional identity processing sections are used.



request_identity:: Send a SIM-Start message to Requests
an additional identity to the one from the EAP-Identity-Response.

If `yes` - We send a request with AT_SUBTYPE SIM-start
with an AT_ANY_ID_REQ attribute to prompt the supplicant
to send a new identity.

The type of identity requested can be controlled by adding
one of the following attributes from the
`recv Identity-Response { ... }` section of the specified
EAP-SIM virtual_server, to the reply list:

- &reply.Any-Id-Req
- &reply.Fullauth-Id-Req
- &reply.Permanent-Id-Req

Even if this configuration item is set to 'no', additional
identities can be requested by policy.
See sites-available/eap-aka-sim for details.



ephemeral_id_length:: The length of any pseudonyms or
fastauth identities we generate (not including hint byte).

See sites-available/eap-aka-sim for details on how to trigger
the generation of pseudonym or fastauth identities.



strip_permanent_identity_hint:: Strip the identity hint when
copying &EAP-Identity or &Identity to &Permanent-Identity.

The stripping is only performed if this config item is set
to yes, and the hint byte matches what we'd expect for the
EAP-Method being executed.



protected_success:: Send a protected success message.

If `yes` - indicate to the peer that we'd like to send
a protected success message.  If the peer agrees and
authentication succeeds, send a `SIM-Notification` (Success)
packet protected with an `AT_MAC` attribute.

After the Notification is ACKed by the peer, we send
the final `EAP-Success` packet containing `MPPE` keys.


request_identity:: Send a AKA-Identity message to request
an additional identity to the one from the EAP-Identity-Response.

If `yes` - We send a request with AT_SUBTYPE AKA-Identity
with an AT_ANY_ID_REQ attribute to prompt the supplicant
to send a new identity.

The type of identity requested can be controlled by adding
one of the following attributes from the
`recv Identity-Response { ... }` section of the specified
EAP-AKA virtual_server, to the reply list:

- &reply.Any-Id-Req
- &reply.Fullauth-Id-Req
- &reply.Permanent-Id-Req

Even if this configuration item is set to 'no', additional
identities can be requested by policy.
See sites-available/eap-aka-sim for details.



ephemeral_id_length:: The length of any pseudonyms or
fastauth identities we generate (not including hint byte).



strip_permanent_identity_hint:: Strip the identity hint when
copying &EAP-Identity or &Identity to &Permanent-Identity.

The stripping is only performed if this config item is set
to yes, and the hint byte matches what we'd expect for the
EAP-Method being executed.



protected_success:: Send a protected success message.

If `yes` - indicate to the peer that we'd like to send
a protected success message.  If the peer agrees and
authentication succeeds, send a `AKA-Notification` (Success)
packet protected with an `AT_MAC` attribute.

After the Notification is ACKed by the peer, we send
the final `EAP-Success` packet containing `MPPE` keys.



network_name:: The default value used for AT_KDF_INPUT

EAP-AKA-Prime mixes various keys with a network identifier
specifying the user's point of connection into the network
to prevent vectors being used where they were not intended
to be.

The value of the AT_KDF_INPUT can be overridden in the
eap-aka-prime virtual server with &reply.KDF-Input if
this value needs to be determined dynamically.

How this value should be created and formatted is specified
in 3GPP.24.302.



request_identity:: Send a AKA-Identity message to request
an additional identity to the one from the EAP-Identity-Response.

If `yes` - We send a request with AT_SUBTYPE AKA-Identity
with an AT_ANY_ID_REQ attribute to prompt the supplicant
to send a new identity.

The type of identity requested can be controlled by adding
one of the following attributes from the
`recv Identity-Response { ... }` section of the specified
EAP-AKA virtual_server, to the reply list:

- &reply.Any-Id-Req
- &reply.Fullauth-Id-Req
- &reply.Permanent-Id-Req

Even if this configuration item is set to 'no', additional
identities can be requested by policy.
See sites-available/eap-aka-sim for details.



ephemeral_id_length:: The length of any pseudonyms or
fastauth identities we generate (not including hint byte).

See sites-available/eap-aka-sim for details on how to trigger
the generation of pseudonym or fastauth identities.



strip_permanent_identity_hint:: Strip the identity hint when
copying &EAP-Identity or &Identity to &Permanent-Identity.

The stripping is only performed if this config item is set
to yes, and the hint byte matches what we'd expect for the
EAP-Method being executed.



protected_success:: Send a protected success message.

If `yes` - indicate to the peer that we'd like to send
a protected success message.  If the peer agrees and
authentication succeeds, send a `AKA-Notification` (Success)
packet protected with an `AT_MAC` attribute.

After the Notification is ACKed by the peer, we send
the final `EAP-Success` packet containing `MPPE` keys.



### `recv Identity-Response { ... }` - Process an EAP-Identity-Response or AKA-Identity value

This is usually the first section called when starting a new EAP-AKA
session, and will be called for each round of identity negotiation.

The following request attributes are available:
- `Identity`			the identity value received in the
				EAP-Identity-Response.
- `Permanent-Identity`	If the hint byte at the start of the
		identity string indicated it was
		permanent.

- `Identity-Type`		The type of identity the 'hint' byte
		at the start of the identity indicates.
		- `Permanent`
		- `Pseudonym`
		- `Fastauath`

- `Method-Hint`		The EAP-Method the 'hint' byte
		at the start of the identity indicates:
		- `AKA-Prime`
		- `AKA`
		- `SIM`

At the end of this section the value of `&Identity-Type` will be
checked to see if any additional identity processing steps are
required.

The following actions are associated with the various
`Identity-Type` values:
- `Permanent`::	The current `&Identity` value will be copied to
  	`&session-state.Permanent-Identity`.  The hint byte
   	will be stripped if the hint matches the current
	EAP-Method.  If the hint byte does not match
	the current EAP-Method the complete value of
	Identity will be copied.  In both cases the realm
	will also be stripped.  You can override the
	identity stored here in policy.
- `Pseudonym`::	`load pseudonym { ... }` will be called.
- `Fastauth`::	`load session { ... }` will be called.

#### Identity hints

In EAP-AKA['] and EAP-SIM, the first byte of the identity is used as
a hint about what type of identity has been provided by the
supplicant and which EAP method should be started.

`Identity-Type` and `Method-Hint` are added by the EAP-AKA module as
a convenience to help determine if additional identities should be
requested.

If for whatever reason the provided ID isn't not recognised or
cannot be processed, you should return `notfound` from this section
to request an additional identity from the supplicant.

Adding any of the following attributes to the reply list will also
cause an additional identity to bre request from the supplicant.

- `Permanent-Id-Req`		request the supplicants `Permanent` Id
		usually its IMSI number.
- `Fullauth-Id-Req`		request either a `Permanent` or a
		`Pseudonym` identity`.
- `Any-Id-Req`		request any identity
		(`Fastauth`, `Pseudonym`, `Permanent``).

NOTE: We do not currently support handover between the EAP-AKA/SIM
modules.  Usually this is not an issue because EAP Negotiation
allows the supplicant and server to negotiate a mutually acceptable
EAP type. If, however, you want to avoid the additional round trips
involved in that negotiation, you can use
`%aka_sim_id_method(%{User-Name})` in the top level virtual server,
which will return the EAP method hinted by the identity, and then
set `&control.EAP-Type` to an appropriate value before calling the
EAP module.

#### Pseudonyms

When receiving a `Identity-Type = Pseudonym` request, the pseudonym
should either be decrypted or resolved to a permanent identity.
Identity resolution can be done here, or in the `load pseudonym { ... }`
section.

If for whatever reason the identity cannot be validated, you should
return `notfound` to request an additional identity.

NOTE: Setting `&Method-Hint = Pseudonym` here will cause the server
to execute the `load pseudonym { ... }` section next.  This is
sometimes useful when dealing with non-standard pseudonym identities.

#### Reauthentication

When receiving a `Identity-Type = Fastauth` request, the fastauth
identity should be resolved in a datastore of valid fastauth
identities.
Session resolution can be done here, or in the `load session { ... }`
section.

If the identity cannot be resolved, you should return `notfound` to
request an additional identity.

NOTE: Setting `&Method-Hint = Fastauth` here will cause the server
to execute the `load session { ... }` section next.  This is
sometimes useful when dealing with non-standard fastauth identities.

#### Custom identity schemes

Multiple identity privacy schemes have been proposed for
EAP-SIM/AKA/AKA'.  Instead of hard coding implementations in the server
source we've provided the necessary cryptographic functions for them to be
implemented in policy.

The notable exception to this is the scheme described in
3GPP TS 33.234 which is supported via the following expansions functions:

- 3gpp_temporary_id_key_index
- 3gpp_temporary_id_decrypt
- 3gpp_temporary_id_encrypt

The rlm_cipher module and the &control.KDF-Identity attribute override
(see notes below) are provided to allow the "Privacy Protection for EAP-AKA"
scheme described by 3GPP S3-170116 and the Wireless Broadband Allowance
document "IMSI PRIVACY PROTECTION FOR WI-FI".



### `send Identity-Request { ... }` - Allow user massaging of Identity-Request

This section is called when a new Start or AKA-Identity request is
sent to the supplicant, unless `send Start { ... }` or `send
AKA-Identity { ... }` sections are provided, in which case they will
be used instead.



### `send Start-Request { ... }` - Allow specific policies to be applied to SIM start requests

This section is optional, and may be used to specify EAP-SIM only
logic for sending Start requests.

If this section is not provided, `send Identity-Request { ... }`
will be executed instead.

The Identity and Start messages perform a very similar role in
EAP-SIM/EAP-AKA, the main difference being, Start messages also
allow the version of EAP-SIM to be negotiated.



### `send Start-Request { ... }` - Allow specific policies to be applied to SIM start responses

This section is optional, and may be used to specify EAP-SIM only
logic for sending Start requests.

If this section is not provided, `send Identity-Request { ... }`
will be executed instead.

The Identity and Start messages perform a very similar role in
EAP-SIM/EAP-AKA, the main difference being, Start messages also
allow the version of EAP-SIM to be negotiated.



### `send AKA-Identity-Request { ... }` - Allow specific policies to be applied to AKA identity requests

This section is optional, and may be used to specify
EAP-AKA/EAP-AKA['] only logic for sending AKA-Identity requests.

If this section is not provided, `send Identity-Request { ... }`
will be executed instead.

The Identity and Start messages perform a very similar role in
EAP-SIM/EAP-AKA, the main difference being, Start messages also
allow the version of EAP-SIM to be negotiated.



### `send Challenge-Request { ... }` - Acquire GSM triplets or UMTS quintuplets for the Challenge-Request

NOTE: It's recommended to perform identity resolution in `recv
EAP-Identity-Response` or `recv Identity-Response` and request or
generate UMTS quintuplets in this section.

The following attributes are added by the EAP-AKA module to the
control list:

- `SIM-AMF = 0x8000`	Only set when using EAP-AKA'.
	This is a hint to any modules generating or
	retrieving UMTS quintuplets that the AMF
	separation bit should be high.

The following attributes are added by the EAP-AKA module to the reply
list, to be modified by policy:

- `KDF-Input`	Only set when using EAP-AKA'
	Is initially set to the value of the
	`network_name` configuration item.  But can
	be set to anything.  If EAP is running over
	RADIUS this should usually be the SSID
	portion of Called-Station-ID.
- `Bidding`		Only set when using EAP-AKA and the
	configuration item `prefer_aka_prime` is 'yes',
	or no `prefer_aka_prime` value is provided and
	EAP-AKA' is enabled in the same EAP module.
- `Result-Ind`	Set when the configuration item
	`protected_success` is 'yes'.

Two sets of control attributes are used depending on how the
quintuplets are being acquired.

If generating triplets or quintuplets locally you should provide the
following control attributes:

- `SIM-Ki`::		Secret shared by the AuC and SIM card.
- `SIM-SQN`::	Sequence number.  Must be stored/incremented
	for each set of quintuplets generated.  Used
	for replay protection, should be a higher
	value than the counterpart SQN on the SIM.
- `SIM-OP`/`SIM-OPc`::Operator Variant Algorithm Configuration Field.
	Input to milenage.  Can provide SIM-OPc if you
	already have access to it, else the OPc will
	be derived from the OP. Must match the value
	configured on the SIM card.

If retrieving triplets from the AuC, you should should provide
three sets of the following control attributes:

- `KC`::		Authentication value from the AuC.
- `RAND`::		User authentication challenge.
- `SRES`::		Signing response.

If retrieving quintuplets from an AuC, you should provide the
following control attributes:

- `AUTN`::		Authentication value from the AuC.
- `CK`::		Ciphering Key.
- `IK`::		Integrity Key.
- `RAND`::		User authentication challenge.
- `XRES`::		Signing response.
- `SQN`::		(optional)
- `AK`::  		(optional)

### Pseudonyms

For identity privacy you may include a `&reply.Next-Pseudonym`
attribute. `&reply.Next-Pseudonym` must be a valid UTF8 string and
MUST NOT contain a realm.  The supplicant will decorate the identity
as appropriate to ensure correct routing.

The following facilitates may be useful when generating pseudonym
values:

- The encrypt expansions of the `rlm_cipher` module.
- The `%3gpp_temporary_id_encrypt()` expansion.
- The `%randstr()` expansion.

NOTE: Add a `&reply.Next-Pseudonym-Id` attribute in this section to
avoid having the permanent Id of the SIM exposed during subsequent
authentication attempts.
The value of this attribute may be empty (a zero length string) if
which case a random value with the correct hint character will be
generated for you.

### Fast-Reauth

For identity privacy, to reduce load on the AuC, and to improve
authentication times/user experience, fast re-authentication may be
used.

Fast re-authentication is very similar to session-resumption in TLS
based EAP methods, where the original MK (Master Key) is stored and
then used to generate new MSKs (Master Session Keys) for subsequent
authentication attempts.

NOTE: Add a `&reply.Next-Reauth-Id` attribute in this section, to
allow session-resumption for subsequent authentication attempts.
The value of this attribute may be empty (a zero length string) if
which case a random value with the correct hint character will be
generated for you.

### Cryptographic identity overrides

The identity provided as the value of EAP-Response/Identity or in
the last processed EAP-Response/AKA-Identity or
EAP-Response/SIM-Start message is used as an input to generate the
MK (Master Key) in full authentication, and XKEY' in
re-authentication.

The identity used as inputs for these cryptographic values must be
identical on both the supplicant and the EAP server, otherwise
authentication will fail with the supplicant returning a
EAP-Response/(AKA|SIM)-Client-Error message with an
AT_CLIENT_ERROR_CODE of "unable to process packet".

Some handset manufacturers have implemented identity schemes which
require an identity not provided in the EAP-Response/Identity
message, or sent as an AT_IDENTITY value. One such identity privacy
scheme described by 3GPP S3-170116 "Privacy Protection for EAP-AKA",
where the cryptographic identity is the plaintext extracted from
the encrypted identity blob.  The same behaviour is required for the
evolution of that standard published by the WBA
"IMSI PRIVACY PROTECTION FOR WI-FI".

Both standards as implemented in iOS and Android violate https://tools.ietf.org/html/rfc4186[RFC 4186],
https://tools.ietf.org/html/rfc4187[RFC 4187],and https://tools.ietf.org/html/rfc5448[RFC 5448] in requiring that the Identity input to the
cryptographic function used to derive the MK for the session be set
to the decrypted identity, not the last value of AT_IDENTITY as
stated by the original RFCs.

No where is this mentioned in either the original 3GPP proposal or the
WBA document.

If you need to implement one of these identity privacy schemes, the
cryptographic identity can be specified with `&control.KDF-Identity`.



### `recv Challenge-Response { ... }` - Allow additional authorization checks and logging

The following rcodes have special meanings in this section:

- `reject`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 1026
		(User has been temporarily denied access).
- `userlock`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 1026
		(User has been temporarily denied access).
- `notfound`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 1031
		(User has not subscribed to the requested service).
- `invalid`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 0
		(General failure after authentication).
- `Fail`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 0
		(General failure after authentication).
- Anything else		Continue processing the request.



### `recv Reauthentication-Request { ... }` - Allow user massaging of a reauthentication request

There's not much to do here as the majority of the work for
session resumption is done in `load session { ... }`.

Add a `&reply.Next-Pseudonym` attribute in this section if you want
to allow avoid having the permanent Id of the SIM exposed during
subsequent authentication attempts.

Add a `&reply.Next-Reauth-Id` attribute in this section, to allow
session resumption for subsequent authentication attempts.

The following rcodes have special meanings in this section:

- `reject`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 16384
		(General Failure).
- `userlock`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 16384
		(General Failure).
- `ok`			Continue with reauthentication.
- `updated`			Continue with reauthentication.
- `noop`			Continue with reauthentication.
- Anything else		Fall back to full authentication.

NOTE: You should use fresh reauthentication ID values here, else the
supplicant may be tracked as they would if their permanent Id has been
used.



### `recv Reauthentication-Response { ... }` - Allow additional authorization checks and logging

Uses the same rcode mappings as `recv Challenge-Response { ... }`.

Will not allow a transition back to the challenge state, as it's
not clear that this is allowed by RFC4186/RFC4187.



### `recv Client-Error { ... }` - Log the fact that the supplicant has terminated authentication

The reason for the error should be available in `&Client-Error-Code`

After this section is run authentication fails immediately with no
EAP-Response/AKA-Notification round.



### `recv Authentication-Reject { ... }` - Log the fact that the supplicant failed to authenticate the AuC

NOTE: Only used for EAP-AKA and EAP-AKA'

The supplicant will respond with EAP-Response/AKA-Authentication-Reject
whenever it cannot validate the AUTN (authentication) value provided in the
EAP-Request/AKA-Challenge packet.

No additional attributes are provided by the supplicant that specify
the error.

After this section is run authentication fails immediately with no
EAP-Response/AKA-Notification round.



### `recv Synchronization-Failure { ... }` - Allow resynchronisation of sequence numbers

NOTE: Only used for EAP-AKA and EAP-AKA'

In some instances the SQN on the SIM card and the SQN in the AuC can
get out of sync.  When this happens the supplicant will send a
EAP-Response/Synchronization-Failure message with an AUTS attribute.

If the original UMTS quintuplets were calculated locally and you
provided Ki and OP/OPc in the Challenge-Request round, then the
EAP-AKA module will automatically calculate a new SQN for you and
place it in `&control.SIM-SQN`.  You should store this new SQN.

As a convenience, the EAP-AKA module will also repopulate
&control.SIM-Ki and &control.SIM-OPc so you do not need to retrieve
them again in the `send Challenge-Request { ... }` section.

If the UMTS quintuplets were provided by an AuC, you should submit
the AUTS value to the AuC to allow it to calculate a new SQN, then
retrieve a new UMTS quintuplet in the
`send Challenge-Request { ... }` section.

If the rcode returned from this section does not indicate failure
and a &control.SQN value is provided, we send a new challenge to
the supplicant and continue; otherwise authentication fails.

NOTE: Only one Synchronisation attempt is permitted per
authentication attempt.



### `send Failure-Notification { ... }` - Allow massaging/logging of failure notifications

NOTE: The rcode returned from this section is ignored.



### `send Failure-Notification { ... }` - Allow logging of failure notification acknowledgements

NOTE: The rcode returned from this section is ignored.



### `send Success-Notification { ... }` - Allow massaging/logging of success notifications

Uses the same rcode mappings as `recv Challenge-Response { ... }`.

NOTE: Only entered if protected result indications are used.



### `send Success-Notification-Ack { ... }` - Allow logging of success notification acknowledgements

NOTE: The rcode returned from this section is ignored.



### `send EAP-Success { ... }` - Allow massaging/logging of success notifications

NOTE: The rcode returned from this section is ignored if we have already sent
a Success-Notification, otherwise the same rcode mappings as
`recv Challenge-Response { ... }` are used.



### `send EAP-Failure { ... }` - Allow logging of failure notification acknowledgements

NOTE: The rcode returned from this section is ignored.



### `store pseudonym { ... }`

If when sending a Challenge-Request Reauthentication-Request a
`&reply.Next-Pseudonym-Id` attribute is found, this section will be
called.

If `&reply.Next-Pseudonym-Id` is empty, it will be filled with a random
string of alphanumeric characters.

For consistency, &reply.Next-Pseudonym-Id will also be made available
temporarily in `&Next-Pseudonym-Id` for use as a key.

You should store the following attributes against the key
`&Next-Paeudonym-Id`:

- `&session-state.Permanent-Identity`::The permanent identity of the user.

If a failure rcode is returned authentication continues but the
Next-Pseudonym-Id will not be sent to the supplicant.

NOTE: The cache module is ideally suited for storing pseudonym
data.  If you're using multiple instances of FreeRADIUS in a
failover cluster, you may wish to use the redis or memcached drivers
to provide a unified pseudonym store.

NOTE: If you're using 3GPP style encrypted pseudonyms you do not
need populate this section.  You should however, provide a policy
for `load session { ... }`, and use that to decrypt the pseudonym.



### `load pseudonym { ... }`

This section will be called prior to entering the AKA-CHALLENGE state.

You should restore the contents of the following attributes using
`&Next-Pseudonym-Id` as a key:

- `&session-state.Permanent-Identity`::The permanent identity of the user.

NOTE: If you're using 3GPP style encrypted pseudonyms, you should
decrypt the pseudonym here, and store the decrypted value in
`&session-state.Permanent-Identity`.



### `clear pseudonym { ... }`

This section we be called if authentication or re-authentication fails.

You should remove any session information stored against
`&Next-Pseudonym-Id`.



### `store session { ... }`

If when sending a Reauthentication-Request a `&reply.Next-Reauth-Id`
attribute is found, this section will be called.

You should restore the contents of the following attributes using
`&request.Session-ID` as a key:

- `&session-state.Counter`::		How many times this session has
			been resumed.
- `&session-state.Session-Data`::	The master session key.
- `&session-state.Permanent-Identity`::(optionally) the permanent
			identity of the user.

If a failure rcode is returned, authentication continues but the
Next-Reauth-Id will not be sent to the supplicant.

NOTE: The cache module is ideally suited for storing session data.
If you're using multiple instances of FreeRADIUS in a failover
cluster, you may wish to use the redis or memcached drivers to
provide a unified session store.



### `load session { ... }`

This section will be called prior to attempting re-authentication.

You should restore the contents of the following attributes using
`&request.Session-ID` as a key:

- `&session-state.Counter`::		How many times this session has
			been resumed.
- `&session-state.Session-Data`::	The master session key.
- `&session-state.Permanent-Identity`::(optionally) the permanent
			identity of the user.

The following rcodes have special meanings in this section:

- `reject`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 16384
		(General Failure).
- `userlock`			Reject the authentication attempt, send
		a Failure-Notification with an
		AT_NOTIFICATION value of 16384
		(General Failure).
- `ok`			Continue with reauthentication.
- `updated`			Continue with reauthentication.
- Anything else		Fall back to full authentication.



### `clear session { ... }`

This section we be called if authentication or re-authentication fails.

You should remove any session information stored against `&request.Session-ID`.


== Default Configuration

```
#					Success Notification-ACK would
#					violate the standard.
server eap-aka-sim {
#	namespace = eap-sim
	namespace = eap-aka
#	namespace = eap-aka-prime
#	eap-sim {
#		request_identity = no
#		ephemeral_id_length = 14
#		strip_permanent_identity_hint = yes
#		protected_success = yes
#	}
	eap-aka {
#		request_identity = no
#		ephemeral_id_length = 14
#		strip_permanent_identity_hint = yes
#		protected_success = yes
	}
#	eap-aka-prime {
#		network_name = ""
#		request_identity = no
#		ephemeral_id_length = 14
#		strip_permanent_identity_hint = yes
#		protected_success = yes
#	}
	recv Identity-Response {
		ok
	}
	send Identity-Request {
		ok
	}
#	send Start-Request {
#		ok
#	}
#	recv Start-Response {
#		ok
#	}
#	send AKA-Identity-Request {
#		ok
#	}
	send Challenge-Request {
		ok
	}
	recv Challenge-Response {
		ok
	}
	send Reauthentication-Request {
		ok
	}
	recv Reauthentication-Response {
		ok
	}
	recv Client-Error {
		ok
	}
	recv Authentication-Reject {
		ok
	}
	recv Synchronization-Failure {
		ok
	}
	send Failure-Notification {
		ok
	}
	recv Failure-Notification-ACK {
		ok
	}
	send Success-Notification {
		ok
	}
	recv Success-Notification-ACK {
		ok
	}
	send EAP-Success {
		ok
	}
	recv EAP-Failure {
		ok
	}
	store pseudonym {
		ok
	}
	load pseudonym {
		ok
	}
	clear pseudonym {
		ok
	}
	store session {
		ok
	}
	load session {
		ok
	}
	clear session {
		ok
	}
}
```
