• No results found

Diameter-RADIUS Interactions (Translation Agents)

Diameter: Twice the RADIUS?

7.4 Diameter Versus RADIUS: A Factor 2?

7.4.3 Diameter-RADIUS Interactions (Translation Agents)

As mentioned earlier, Diameter and RADIUS may need to co-exist within the boundaries of the same operator administration for a long migration period. In the process of designing Diameter, a great amount of effort was focused on providing facilities for RADIUS–Diameter co-existence. An example of such efforts was to ensure that RADIUS attribute space is included as-is inside the Diameter attribute space to eliminate the need for attribute conversion. However, Diameter creates a superset of RADIUS attributes and messages and for that reason co-existence of Diameter and RADIUS requires specialized effort.

Due to its focus on authentication and authorization, Diameter NAS application is the one Diameter specification with the most similarity to RADIUS. For those reasons, the Diameter NAS application is the first specification that describes interoperability between Diameter and RADIUS implementations. This interoperability is envisioned through an architecture consisting of distinct RADIUS and Diameter systems meeting each other through a translation agent at their boundaries.

Since Diameter functionality is superior to that of RADIUS and there are many differences between RADIUS and Diameter, there can be many variants and implementations of translation agents in proprietary non-IETF manners. Also due to the simultaneous standardizations of RADIUS and Diameter, various RADIUS messages may be handled differently by different translation agents along the process, while none of those translation agents can be assumed to have access to complete and accurate session state information.

The Diameter NAS application describes many requirements and conversion procedures for RADIUS–Diameter translation agents. We do not go into the exact details of how the translation of a message, an attribute or AVP or a service such as security is performed in every instance. Instead we provide some highlights to give the reader some idea of the issues to be considered in the translation:

● RADIUS security mechanisms are hop by hop, while Diameter may apply end-to-end security mechanism. The Diameter agent will have to decrypt the RADIUS messages and attributes and secure the information in a Diameter-specific manner as explained earlier. For instance, when the translation agent receives a RADIUS message including a User- Password Attribute encrypted with a RADIUS shared secret over the link, the agent must decrypt the password from the RADIUS link and forward the password information inside a Diameter message that is protected by Diameter security mechanisms. The authenticator value in RADIUS messages including message-authenticator attribute (defined in [RADEXT2869]) must be verified by the translation agent, but not included back in the Diameter message created by the agent.

● RADIUS supports neither peer-to-peer architecture nor server-initiated messages, while Diameter defines a large number of command codes that can be used in both request and response messages in a peer-to-peer manner. When negotiations involve multi-round message exchanges, RADIUS only offers Access request for client to server and access challenge for server to client messages. The translation agent must create access challenge messages or access request messages based on the Diameter commands.

● RADIUS servers are assumed to be stateless, while Diameter nodes maintain state and, as mentioned earlier, Diameter agents may have a distorted picture of the overall end-to-end session.

● Diameter AVPs are defined in fully qualified domain name (FQDN) format, while RADIUS attributes are not. The translation agent must change the information format according to the system to which the message is being forwarded. A prime example is converting RADIUS NAS IP address attribute into Diameter Origin-Host AVP in FQDN format.

● Diameter supports grouped AVPs. When the translation agent receives RADIUS attribute/s that will have to be part of a grouped AVP, the agent must extract the related RADIUS attributes to build the Diameter grouped AVP. The prime example is handling of CHAP exchanges. The CHAP-password attribute of RADIUS includes the response as the attribute data, but includes CHAP-ID in the “header” of the attribute. In contrast, Diameter defines a grouped CHAP-Auth AVP that includes CHAP-response and CHAP-Ident as sub-AVPs. This conversion needs to be done by the translation agent.

In summary, the translation agents act as gateways responsible for interoperability between RADIUS and Diameter. The problem is: Diameter does not specify the details of the operation of these agents. Therefore, it cannot be assumed that implementing Diameter specifications alone will lead to ready backward compatibility with RADIUS in a plug and play manner.

7.5 Further Resources

For more information on the standardization of Diameter in IETF, the reader is referred to the website for the IETF AAA working group

http://ietf.org/html.charters/aaa-charter.html

For information on open source implementations of Diameter, the following website is a good starting point:

http://www.opendiameter.org/

One of the major third generation cellular network standards (3GPP) is using Diameter for AAA procedures. The standardization is performed partly at IETF in documents such as [DIA3G3589] and partly in 3GPP, such as [3GPPDIA]. This would mean most Diameter activities can be traced by following the activities around 3GPP cellular networks.

7.6 References

1. [AAAEVAL2989], B. Aboba et al., “Criteria for Evaluating AAA Protocols for Network Access”, IETF, RFC 2989, November 2000.

2. [NASCRIT3169], M. Beadles, D. Mitton, “Criteria for Evaluating Network Access Server Protocols”, Internet Engineering Task Force, RFC 3169, September 2001.

3. [PITTPROC], IETF 48th Proceedings website, AAA Working Group meeting minutes, http://www.ietf.org/ proceedings/00jul/00july-58.htm, Pittsburg, July 31–August 4, 2000.

4. [EVALRES3127], D. Mitton et al., “Authentication, Authorization and Accounting Protocol Evaluation”, IETF, RFC 3127, June 2001.

5. [DIAMETER3588], P. Calhoun, “Diameter Base Protocol”, RFC 3588, IETF, September 2003.

6. [NASREQDR], P. Calhoun et al., “Diameter Network Access Server Application”, Internet draft, IETF work in progress, draft-ietf-aaa-diameter-nasreq-16.txt, June 2004.

7. [AAATR3539], B. Aboba, J. Wood, “Authentication, Authorization and Accounting (AAA) Transport Profile”, IETF, RFC 3539, June 2003.

8. [DICMSDR], P. Calhoun, W. Bulley, S. Farrell, “Diameter CMS Security Application”, Internet draft, IETF work in progress, draft-ietf-aaa-diameter-cms-sec-04.txt, March 2002.

9. [CMS3370], R. Housley, “Cryptographic Message Syntax (CMS) Algorithms”, RFC 3370, IETF, August 2002. 10. [ACCMGM2975], B. Aboba et al., “Introduction to Accounting Management”, IETF, RFC 2975, October 2000. 11. [ACCATT2924], N. Brownlee, A. Blount, “Accounting Attributes and Record Format”, IETF, RFC 2924,

September 2000.

12. [IANAWEB], Internet Assigned Number Authority, website URL, http://www.iana.org/

13. [DIACCDR], H. Hakala et al., “Diameter Credit Control Application”, IETF work in progress, Internet draft, draft-ietf-aaa-diameter-cc-06.txt, August 2004.

14. [DIAMIPDR], P. Calhoun et al., “Diameter Mobile IPv4 Application”, IETF work in progress, draft-ietf-aaa- diameter-mobileip-20.txt, August 2004.

15. [DIAEAPDR], P. Eronen et al., “Diameter Extensible Authentication Protocol (EAP) Application”, IETF work in progress, Internet draft, draft-ietf-aaa-eap-07.txt, June 2004.

16. [RAD3576], M. Chiba et al., “Dynamic Authorization Extensions to RADIUS”, IETF, RFC 3576, July 2003. 17. [RADEXT2869], C. Rigney et al., “RADIUS Extensions”, IETF, RFC 2869, June 2000.

18. [DIA3G3589], J. Loughney, “Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5”, IETF, RFC 3589, September 2003.

19. [3GPPDIA], “Diameter Applications, 3G Specific Codes and Identifiers”, 3rd Generation Partnership Project, June 2004.

AAA and Network Security for Mobile Access: Radius, Diameter, EAP, PKI and IP Mobility

Madjid Nakhjiri and Mahsa Nakhjiri © 2005 John Wiley & Sons, Ltd

8