INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-authent-01.txt Date: March 1998 DIAMETER User Authentication Extensions <draft-calhoun-diameter-authent-01.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract DIAMETER is a management protocol used between Network Access Servers and DIAMETER Servers for authentication, authorization, accounting of dial-up users. A considerable amount of effort was put into the design of this protocol to ensure that an implementation could support both DIAMETER and RADIUS at the same time. This document details the RADIUS authentication messages and how they may be used with the DIAMETER protocol. Table of Contents 1.0 Introduction 1.1 Specification of Requirements 2.0 Command Name and Command Code 3.0 Command Meanings 3.1 Domain-Discovery-Request 3.2 Domain-Discovery-Response Calhoun expires September 1998 [Page 1]
INTERNET DRAFT March 1998 3.3 Authentication-Request 3.4 Authentication-Success 3.5 Authentication-Failure 4.0 Protocol Definition 4.1 RADIUS Proxies 4.2 DIAMETER Proxies 4.2 Domain Discovery 5.0 References 6.0 Authors' Addresses 1.0 Introduction This document specifies extensions to the original RADIUS[1] authentication messages. There exists a scenario where services providers wish to proxy the authentication of a user to a remote DIAMETER Server, yet wishes to perform the authorization for the said user. There are also many instances where a NAS may wish to simply authenticate a user and not have any authorization assigned to the request. 1.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Calhoun expires September 1998 [Page 2]
INTERNET DRAFT March 1998 2.0 Command Name and Command Code Command Name: Domain-Discovery-Request Command Code: 6 Command Name: Domain-Discovery-Response Command Code: 7 Command Name: Authentication-Request Command Code: 8 Command Name: Authentication-Success Command Code: 9 Command Name: Authentication-Failure Command Code: 10 3.0 Command Meanings 3.1 Domain-Discovery-Request Description The Domain-Discovery-Request message is used by a DIAMETER device wishing to get contact information about a domain's home authentication server as well as to receive password policy information. This message MUST contain the User-Name attribute in order to pass along the user's domain information. A summary of the Domain-Discovery-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command Length The length of this attribute MUST be 7. Calhoun expires September 1998 [Page 3]
INTERNET DRAFT March 1998 Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 6 (Domain-Discovery-Request). 3.2 Domain-Discovery-Response Description The Domain-Discovery-Response message is sent in response to the Domain-Discovery-Request message by the domain's Home authentication server. The message MUST contain either the X509- Certificate or the X509-Certificate-URL attribute and MAY contain the Password-Policy attribute. A summary of the Domain-Discovery-Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command Length The length of this attribute MUST be 7. Flags The flag field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 7 (Domain-Discovery- Response). Calhoun expires September 1998 [Page 4]
INTERNET DRAFT March 1998 3.3 Authentication-Request Description The Authentication-Request message is used in order to request authentication and authorization for a given user. Note that this command does not require the presence of a user name as the credentials used MAY be a telephone number (i.e. DNIS, ANI) instead. Note that the flag field MAY be used in this command in order to indicate that either Authentication-Only or Authorization-Only is required for the request. If the Authentication-Only bit is set the response MUST NOT include any authorization information. At least one of the Authenticate/Authorize flag bits MUST be set. A summary of the Authentication-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command Length The length of this attribute MUST be 7. Flags The flag field MUST have bit 1 (Mandatory Support) set. In addition, the following bits may be used (note these bits are mutually exclusive): bit 3 - Authenticate-Only bit 4 - Authorize-Only Command Type The Command Type field MUST be set to 8 (Authentication-Request). Calhoun expires September 1998 [Page 5]
INTERNET DRAFT March 1998 3.4 Authentication-Success Description The Authentication-Success message is used in order to indicate that Authentication (or authorization) was successful. If authorization was requested a list of AVPs with the authorization information MUST be attached to the message (see [1]). Note that the flag field MUST be set to the same value that was found in the Authentication-Request message. A summary of the Access-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command Length The length of this attribute MUST be 7. Flags following bits may be used (note these bits are mutually exclusive): bit 3 - Authenticate-Only bit 4 - Authorize-Only Command Type The Command Type field MUST be set to 9 (Authentication-Success). 3.5 Authentication-Failure Description Calhoun expires September 1998 [Page 6]
INTERNET DRAFT March 1998 The Authentication-Failure message is used in order to indicate that Authentication (or authorization) was unsuccessful. The list of AVPs that may be attached to this message can be found in [1]. Note that the flag field MUST be set to the same value that was found in the Authentication-Request message. A summary of the Access-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command Length The length of this attribute MUST be 7. Flags following bits may be used (note these bits are mutually exclusive): bit 3 - Authenticate-Only bit 4 - Authorize-Only Command Type The Command Type field MUST be set to 10 (Authentication-Failure). 4.0 Protocol Definition This section will outline how the DIAMETER Authentication Extension can be used. 4.1 RADIUS Proxies In today's dial up networks the RADIUS protocol is used to Calhoun expires September 1998 [Page 7]
INTERNET DRAFT March 1998 authentication, authorize and perform accounting for dial-up users. However, it has become common practice to make use of RADIUS Servers known as proxies. The use of proxies has become widespread especially with the popularity of Internet Roaming[4]. In this example a user has a single user account with a local service provider. When this user roams outside of his ISPs service area, it is possible for the user to connect to another service provider (see [4] for more details). In this scenario, the new service provider (ISPB) provides internet access for the user through a NAS (NASB). ISPB owns an authentication server (RADB), which proxies the authentication request to the user's original provider's authentication server (RADA). (Access-Request) (Access-Request) +------+ -----> +------+ ------> +------+ | | | | | | | NASB +--------------------+ RADB +--------------------+ RADA + | | | | | | +------+ <----- +------+ <------ +------+ (Access-Accept) (Access-Accept) The example shown above NASB generates an authentication request on behalf of the dial-in user to the RADB Authentication server. In this case, the user's identity would include a domain identifier [3] that would enable RADB to identify the authentication server (i.e. user@ISPA.com). The RADB server then forwards the request to RADA which authenticates the user based on information found within the request. If successfully authentication the RADA server returns a successful response along with authorization information. If the user authentication fails RADA replies with a failed response. In the past this model has caused much concern over it's security implication. The model is much worse in the model where there exists an intermediate provider between ISPB and ISPA (say ISPC). The following diagram depicts such an example where RADB must forward any requests for RADA through RADC. (Accounting-Request) (Accounting-Request) +------+ -----> +------+ ------> +------+ | | | | | | | RADB +--------------------+ RADC +--------------------+ RADA + | | | | | | +------+ <----- +------+ <------ +------+ (Accounting-Response) (Accounting-Response) Calhoun expires September 1998 [Page 8]
INTERNET DRAFT March 1998 The problem with the above scenario is that complete trust is placed in RADC (and hence ISPC) since it is very simple to modify any attributes found within the request or the response. The example shows an accounting request sent from RADB to RADA through RADC. The following is a list of a few attacks which can be generated by a malicious proxy: - Generating Accounting Records by replaying old authentication/accounting records. In this example it is very simple for RADC to simple retain old packets and replay then at a later date. This will cause RADA to "pay" for services which were never rendered. - Modify Attributes within the request or response. In this case RADC can modify attributes, such as the length of the call, that would fool RADA into believing the call was longer than in reality. - Stealing PAP Passwords is another problem with today's proxies. In the current model PAP passwords are encrypted using a shared secret which is shared between each hop in the proxy chain. In this case each hop has the opportunity to decrypt, and possibly save for future use, the user's password. fool RADA into believing that Given the problems identified above with the current proxy model it is necessary to create a mechanism which allows for non-repudiation, end-to-end data integrity as well as end-to-end encryption. Given the current encryption technology this can only be achieved with the use of asymetric encryption and digital signatures. 4.2 DIAMETER Proxies The DIAMETER protocol also the use of proxies in order to keep the existing arrangements while migrating from RADIUS to DIAMETER. However since DIAMETER makes use of asymetric encryption and digital signatures it solves many of the problems shown above. (Access-Request) (Access-Request) +------+ -----> +------+ ------> +------+ | | | | | | | NASB +--------------------+ DIA2 +--------------------+ DIA1 + | | | | | | +------+ <----- +------+ <------ +------+ (Access-Accept) (Access-Accept) In this example NASB generates an Authentication-Request that is forwarded to DIA2. The Authentication-Request contains a digital signature AVP which "protects" all mandatory (or non-editable) AVPs within the request. All AVPs which may be modified, or removed appear after the digital signature AVP. Once DIA2 receives the request, it Calhoun expires September 1998 [Page 9]
INTERNET DRAFT March 1998 MAY authenticate the request to ensure that it was originated by NASB (verifying the signature is not necessary if the link between NASB and DIA2 is secured using IPSEC). The DIA2 Server may then add new attributes to the request. All mandatory AVPs MUST be present prior to the non mandatory AVPs and MUST be preceeded by a Digital Signature AVP (using DIA2's private key). Note that all non-mandatory AVPs added to the packet by NASB must appear after DIA2's digital signature AVP. The message is then forwarded towards the DIA1 server. Since all packets between NASB and DIA1 must flow through DIA2, it is not possible to use IPSEC between both hosts. Therefore DIA1 MUST validate NASB's digital signature AVP. However it is not necessary to validate DIA2's digital signature if the link between DIA2 and DIA1 is secured using IPSEC. This mechanism now provides a method for DIA1 to prove that NASB was the initiator of the request (note that DIAMETER also includes a timestap to prevent replay attacks). It also provides a method of ensuring that RADB cannot modify any "non-editable" attributes (such as length of call, etc). In addition, this same mechanism can be used for end to end encryption of AVPs. In the case where NASB needs to encrypt an AVP it is done using asymetric encryption using DIA1's public key. This ensures that only RADA can decrypt the AVP. An attack has been identified in this proposal which allows a malicous man in the middle attack as shown in the following diagram. (Access-Request) (Access-Request) (Access-Request) +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 + | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Access-Accept) (Access-Accept) (Access-Accept) In this example, DIA3 traps packets generated from DIA2 towards DIA1, removes the AVPs added by DIA2 and inserts its own AVPs (posibly by trying to convince DIA1 to pay DIA3 for the services). This attack can be prevented by supporting a new Next-Hop AVP. In this case when NASB prepares a request it inserts a non-editable Next-Hop AVP which contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 as the next hop. This mechanism ensures that a man in the middle cannot alter the packet by overriding the previous hop's additions and signature. DIA1 could easily validate the packet's path with the use of the Next-Hop Calhoun expires September 1998 [Page 10]
INTERNET DRAFT March 1998 AVPs. 4.3 Domain Discovery The Domain Discovery message set is very useful in determining the Home authentication server, the password policies for the domain, as a mechanism to retrieve a certificate (or a pointer to a certificate). The following example shows a case where DIA1 needs to communicate with DIA3. In this example it is necessary to use DIA2 as a proxy in order for both ISPs to communicate. Although this MAY be desireable in some business models, there are cases where it is beneficial to remove the proxy altogether and allow both DIA3 and DIA2 to communicate in a secure fashion. (DD-Request) (DD-Request) +------+ -----> +------+ ------> +------+ | | | | | | | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 + | | | | | | +------+ <----- +------+ <------ +------+ (DD-Response) (DD-Response) The way the Domain Discovery works is that prior to sending out an authentication request DIA1 would issue a Domain Discovery message towards DIA2. This message is protected with the digital signature as well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 including the Next-Hop and the digital signature AVP. When DIA3 receives the request, it MUST save the certificate (or the pointer to the certificate) and respond back including the local password policy, DIA3's certificate, it's contact information (i.e. IP address) and protect the response with the digital signature. Note that in all cases the TimeStamp AVP is also present to ensure no reply packets are accepted. When DIA2 receives the packet, it must add the Next-Hop AVP as well as the digital signature AVP. When DIA1 receives the packet is now knows a direct route to communicate with DIA3 since the contact information is present in the response. The fact that both DIA1 and DIA3 can now communicate directly allows both peers to use IPSEC to protect the message exchange (note that it MAY be desirable to also use the digital signature in order to keep the information in the DIAMETER logs). (Authentication-Request) +------+ -----> +------+ Calhoun expires September 1998 [Page 11]
INTERNET DRAFT March 1998 | | | | | DIA1 +--------------------+ DIA3 + | | | | +------+ <----- +------+ (Authentication-Response) In addition, the password policy is also present which can indicate whether DIA3 is willing to accept CHAP, PAP or EAP authentication. Note that the Domain-Request/Response MAY include the Features- Supported AVPs. 5.0 References [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997 [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-00.txt, February 1998. [3] B. Aboba. "The Network Access Identifier." Internet-Draft, August 1997. [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, July 1997. 6.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-847-548-9587 Fax: 1-650-786-6445 E-mail: pcalhoun@toast.net Calhoun expires September 1998 [Page 12]