Cisco Mobile Wireless Home Agent Release 5.2 for Cisco IOS Release 12.4(22)YD2

User Authentication and Authorization

This chapter discusses User Authentication and Authorization, and how to configure this feature on the Cisco Mobile Wireless Home Agent.

This chapter includes the following sections:

•User Authentication and Authorization

•Authentication Configuration Extension

•3GPP2 RRQ Without MHAE

•Local Authentication for 3GPP2

•NAI Authentication with Local MN-HA SPI and Key

•No Authorization for Re-Reg / De-Reg

•Skip HA-CHAP with MN-FA Challenge Extension (MFCE)

•Authentication and Authorization RADIUS Attributes

User Authentication and Authorization

The Home Agent can be configured to authenticate a user using either PAP or CHAP. The Foreign Agent Challenge procedures are supported (RFC 3012) and includes the following extensions:

•Mobile IP Agent Advertisement Challenge Extension

•MN-FA Challenge Extension

•MN-AAA Authentication Extension

Note PAP is used if no MN-AAA extension is present, and CHAP is always used if MN-AAA is present. The password for PAP users can be set using the ip mobile home-agent aaa user-password command.

When configured to authenticate the user with the Home AAA-server, if the Home Agent receives the MN-AAA Authentication Extension in the Registration Request, the contents are used. If the extension is absent, a default configurable password is used. This default password is a locally defined string such as "vendor".

The HA accepts and maintains the MN-FA challenge extension and MN-AAA authentication extension (if present) from the original registration for use in later registration updates.

If the Home Agent does not receive a response from the AAA server within a configurable timeout, the message can be retransmitted a configurable number of times. You can configure the Home Agent to communicate with a group of AAA servers; the server is chosen in round-robin fashion from the available configured servers.

To configure authorization and authentication on the HA, perform the following tasks:

Router(config)# ip mobile host {lower [upper] | nai 
string {static-address {addr1 [addr2] [addr3] 
[addr4] [addr5] | local-pool name} | address {addr | 
pool {local name | dhcp-proxy-client [dhcp-server 
addr]} {interface name | virtual-network 
network_address mask} [skip-chap | aaa [load-sa 
[permanent]] [authorized-pool pool name] 
[skip-aaa-reauthentication] [care-of-access acl] 
[lifetime seconds]

The HA supports 3GPP2 and Cisco proprietary security extension attributes in RADIUS access accept packet. Sending 3GPP2 MN-HA SPI in Access Request to RADIUS server and processing the MN-HA Secure Key Received from RADIUS server is configurable on HA.

Cisco IOS provides a mechanism to authorize subscribers based on their realm. This can be done using a feature called "Subscriber Authorization", the details of which can be found here: http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapter09186a0080455cf0.html#wp1056463.

Note The Home Agent will accept user profiles, it will not authorize a mobile subscriber based on information returned in a group profile.

Authentication Configuration Extension

The Home Agent allow you to configure when external authentication with AAA occurs for specific mobile IP events. Handoffs across foreign agents is treated as a registration and a de-registration event, and there is no specific configuration for handoff.

In the event that a re-registration request is received with a different SPI than used for a previous registration or re-registration for that session, the configuration options enable | disable for authentication on re-registration are ignored for this user.

Applying or modifying any configuration occurs at the next event for a given binding.

The following configuration is for the re-registration and de-registration events that may be on a per-realm (VRF) basis.

ip mobile host nai string aaa load-sa skip-aaa-reauth [ reregistration | deregistration]

The default configuration is that authentication occurs for all three events (ip mobile host nai string aaa load-sa).

Here are some examples that assume the default configuration is in place:

ip mobile host nai string aaa load-sa skip-aaa-reauth results in AAA authentication occurring for registration only.

ip mobile host nai string aaa load-sa skip-aaa-reauth deregistration results in AAA authentication occurring for registration and reregistration.

ip mobile host nai string aaa skip-chap results in no authentication occurring for initial registration, reregistration, and deregistration events.

ip mobile host nai string aaa load-sa skip-aaa-reauth reregistration results in AAA authentication occurring for registration and deregistration only.

The load-sa keyword causes the HA to download and locally store the security attributes for mobile-home authentication during the entire session. Without this parameter the HA does not locally store the security attributes for mobile-home authentication, and must retrieve them from AAA for subsequent re-registration or de-registration.

3GPP2 RRQ Without MHAE

Currently, the HA treats the MN-HA authenticator extension in RRQ as mandatory. If an RRQ is received by the HA without the MHAE extension, that RRQ is ignored.

But 3GPP2 PMIP RRQs may not have MHAE extensions since they are not mandatory according to the standard/RFC. In Cisco HA Release 5.1, you can configure the HA to allow 3GPP2 PMIP RRQs without the MHAE extension provided it succeeds FA-HA authentication.

To configure this feature, perform the following task:

Note If a CMIP RRQ is received without MHAE, but with valid FHAE and the command is configured, the HA will still process the RRQ. It does not reject this RRQ, because the HA cannot differentiate between PMIP RRQs and CMIP RRQs. To avoid this situation, ensure that the FA checks for the CMIP RRQ, and makes sure it does not forward a CMIP RRQ without MHAE to the HA.

Local Authentication for 3GPP2

The existing HA 5.0 allows you to authenticate a user either using a downloaded SA from AAA, or on locally configured HA. This can be provisioned using the aaa keyword in the ip mobile host nai configuration command.

The HA 5.0 functionality can be configured per user/nai but not per access-type.

In HA Release 5.1, this feature along with NAI Authentication with local MN-HA SPI and Key, provides you the flexibility of authenticating a user using a downloaded SA or local SA based on access-type.

This feature addresses the requirement of authenticating a user using local SA for 3gpp2 access-type, and authenticating the same user using AAA SA for Wimax access-type. During 3gpp2 access-type, no Access-Request is sent to the AAA.

When enabled, the Access-Request is not sent to AAA even if the RRQ has an MN-AAA extension.

To configure the HA to perform local authentication for 3GPP2, perform the following tasks:

This configuration, when used with ip mobile host nai aaa, and ip mobile secure host nai, addresses the requirement of authenticating a user using local SA for 3gpp2 access-type, and authenticating the same user using AAA SA for Wimax access-type.

NAI Authentication with Local MN-HA SPI and Key

HA R5.0 supports local configuration for MN-HA security association (SA) or MN-HA SA downloaded from AAA, but not both together.

In HA Release 5.1, the HA supports both the local configuration of a MN-HA SA, as well as an SA downloaded from AAA. Regardless of whether an SA is configured locally or not, if the HA receives an SA in the access-response message from AAA, then only the SA downloaded from AAA is used for MN-HA authentication.

Limitations and Restrictions

•When the ip mobile host command is configured for a full-NAI, the SA(s) configured locally for the corresponding realm are not applied. If the local SA needs to be applied, then the SA(s) needs to be configured separately for the full-NAI.

For example, consider the following case:

–ip mobile host nai @cisco.com virtual-network ip1 mask1 aaa

–ip mobile host nai user1@cisco.com virtual-network ip2 mask2 aaa

–ip mobile secure host nai @cisco.com spi 100 key ascii CISCO

Here, the configured SA for @cisco.com is not applied to user1@cisco.com. If a local SA needs to be applied for this user, an SA needs to be configured separately:

ip mobile secure host nai user1@cisco.com spi 100 key ascii YAHOO

•This feature is supported only for 3GPP2 users, and not for Wimax users.

No Authorization for Re-Reg / De-Reg

With the NAI Authentication with local MN-HA SPI and Key feature, both locally configured SA and SA downloaded from AAA are supported.

But when you configure the following command, the re-authentication and re-authorization are prevented only when the SA for MN-HA is received in an access-accept:

router (config)# ip mobile host nai realm virtual-network ip mask aaa load-sa 
skip-aaa-reauth [rereg | dereg]

If the MN-HA authentication uses local SA during registration, even with the above configuration, the re-authentication/re-authorization is not skipped because the load-sa only caches the SA downloaded from AAA.

This feature supports caching SA even when using locally configured SA, if load-sa is configured. With load-sa configured, re-authorization is prevented even when using a locally configured SA. Additionally, when skip-aaa-reauth is configured, re-authentication with AAA is prevented when using a locally configured SA.

The [rereg | dereg] options, if specified, gives you the flexibility to prevent re-authentication and re-authorization for either re-registration or de-registration only.

Skip HA-CHAP with MN-FA Challenge Extension (MFCE)

This feature allows the HA to download a Security Association (SA) and cache it locally on the disk, rather than performing a HA-CHAP procedure with Home AAA server to download the SA for the user for each registration request. When a user first registers with the HA, the HA does HA-CHAP (MN-AAA authentication), downloads the SA, and caches it locally. On subsequent re-registration requests, the HA uses the locally cached SA to authenticate the user. The SA cache entry is removed when the binding for the user is deleted.

You can configure this feature on the HA using the ip mobile host command, noted above.

Configuration Examples

The following example configures a mobile node group to reside on virtual network 10.99.1.0 and retrieve and cache mobile node security associations from a AAA server. The cached security association is then used for subsequent registrations.

ip mobile host 10.99.1.1 10.99.1.100 virtual-network 10.99.1.0 aaa load-sa

The following example configures a local pool of dynamic addresses to be used in assigning IP addresses to mobile nodes in the cisco.com domain. The security associations that are retrieved from the AAA server are cached permanently until cleared manually.

ip mobile host nai @cisco.com address pool local mobilenodes virtual network 10.2.0.0 

255.255.0.0 aaa load-sa permanent lifetime 180

Authentication and Authorization RADIUS Attributes

The Home Agent, and the RADIUS server support RADIUS attributes listed in Table 1 for authentication and authorization services.