INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-authent-04.txt William Bulley Date: July 1998 Merit Network, Inc. DIAMETER User Authentication Extensions 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract DIAMETER is a Policy and AAA protocol which can be used for a variety of services. This document defines DIAMETER messages that are used for the authentication, authorization and accounting of 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 concurrently. Calhoun expires January 1999 [Page 1] INTERNET DRAFT July 1998 Table of Contents 1.0 Introduction 1.1 Specification of Requirements 2.0 Command Codes 2.1 Domain-Discovery-Request 2.2 Domain-Discovery-Answer 2.3 AA-Request 2.4 AA-Answer 2.5 AA-Challenge-Ind 3.0 DIAMETER AVPs 3.1 User-Name 3.2 User-Password 3.3 CHAP-Password 3.4 NAS-Port 3.5 Service-Type 3.6 Framed-Protocol 3.7 Framed-IP-Address 3.8 Framed-IP-Netmask 3.9 Framed-Routing 3.10 Filter-Id 3.11 Framed-MTU 3.12 Framed-Compression 3.13 Login-IP-Host 3.14 Login-Service 3.15 Login-TCP-Port 3.16 Reply-Message 3.17 Callback-Number 3.18 Callback-Id 3.19 Framed-Route 3.20 Framed-IPX-Network 3.21 State 3.22 Class 3.23 Vendor-Specific 3.24 Session-Timeout 3.25 Idle-Timeout 3.26 Termination-Action 3.27 Called-Station-Id 3.28 Calling-Station-Id 3.29 Proxy-State 3.30 Login-LAT-Service 3.31 Login-LAT-Node 3.32 Login-LAT-Group 3.33 Framed-AppleTalk-Link 3.34 Framed-AppleTalk-Network 3.35 Framed-AppleTalk-Zone 3.36 CHAP-Challenge 3.37 NAS-Port-Type Calhoun expires January 1999 [Page 2] INTERNET DRAFT July 1998 3.38 Port-Limit 3.39 Login-LAT-Port 3.40 Filter-Rule 3.41 Framed-Password-Policy 3.42 Table of Attributes 4.0 Protocol Definition 4.1 Feature Advertisement/Discovery 4.2 Authorization Procedure 4.3 Integration with Resource-Management 4.4 RADIUS Proxies 4.5 DIAMETER Proxies 4.6 Domain Discovery 5.0 References 6.0 Acknowledgements 7.0 Authors' Addresses 1.0 Introduction This document describes the DIAMETER User Authentication Extensions that can be used for a variety of services including Dial-up users via NAS, WWW User Authentication, Firewall User Authentication[5][6]. This document describes Authentication/Authorization messages as well as a set of messages which allow DIAMETER hosts to bypass proxies. Since Most of the AVPs found in this document was copied from the RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER servers read the same dictionary and users files. The backward compatibility that DIAMETER offers is intended to facilitate deployment. The Extension number for this draft is two (2). This value is used in the Extension-Id AVP as defined in [2]. 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. Calhoun expires January 1999 [Page 3] INTERNET DRAFT July 1998 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. 2.0 Command Codes This document defines the following DIAMETER Commands. All DIAMETER implementations supporting this extension MUST support all of the following commands: Command Name Command Code ----------------------------------- Domain-Discovery-Request 261 Domain-Discovery-Answer 262 AA-Request 263 AA-Answer 264 AA-Challenge-Ind 265 2.1 Domain-Discovery-Request (DDR) 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. The X509-Certificate or the X509-Certificate-URL [2] MUST be present in this message in order to inform the home authentication server of the issuing host's certificate. Message Format ::= [] Calhoun expires January 1999 [Page 4] INTERNET DRAFT July 1998 [] [] { || ::= [] [] [] { || ::= [] { || { || ::= [] { || [] { || +------+ ------> +------+ | | | | | | | 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 authenticated 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 when 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) 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 Calhoun expires January 1999 [Page 59] INTERNET DRAFT July 1998 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. 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.5 DIAMETER Proxies The DIAMETER protocol also makes 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. (AA-Request) (AA-Request) +------+ -----> +------+ ------> +------+ | | | | | | | NASB +--------------------+ DIA2 +--------------------+ DIA1 | | | | | | | +------+ <----- +------+ <------ +------+ (AA-Answer) (AA-Answer) In this example NASB generates an AA-Request that is forwarded to DIA2. The AA-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 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 Calhoun expires January 1999 [Page 60] INTERNET DRAFT July 1998 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 DIA2 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 DIA1 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. (AA-Request) (AA-Request) (AA-Request) +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (AA-Answer) (AA-Answer) (AA-Answer) 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 AVPs. 4.6 Domain Discovery Calhoun expires January 1999 [Page 61] INTERNET DRAFT July 1998 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 DIA1 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 it then 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). (AA-Request) +------+ -----> +------+ | | | | | DIA1 +--------------------+ DIA3 | | | | | Calhoun expires January 1999 [Page 62] INTERNET DRAFT July 1998 +------+ <----- +------+ (AA-Answer) 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-Discovery-Request/Answer MAY include the Supported-Extension AVPs [2]. 5.0 References [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, draft-calhoun-diameter-03.txt, May 1998. [3] Aboba, Beadles, "Network Address Identifier", Internet- Draft, draft-ietf-roamops-nai-10.txt, February 1998. [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, July 1997. [5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication Protocol Extensions", Internet-Draft, draft-calhoun- diameter-eap-01.txt, March 1998. [6] Calhoun, Haag, Zorn, "EAP Authentication for SOCKS Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998. [7] Jacobson, "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. [8] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol (MP)", RFC 1717, November 1994. [10] Calhoun, Greene, "DIAMETER Resource Management Extension", Internet-Draft, draft-calhoun-diameter-res-mgmt-01.txt, May 1998. [11] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- Draft, draft-calhoun-diameter-framework-00.txt, May 1998 Calhoun expires January 1999 [Page 63] INTERNET DRAFT July 1998 6.0 Acknowledgements The Author wishes to thank Carl Rigney since much of the text in the document was shamefully copied from [1] as well as the following people for their help in the development of this protocol: Nancy Greene, Ryan Moats 7.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-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com William Bulley Merit Network, Inc. 4251 Plymouth Road, Suite C Ann Arbor, Michigan, 48105-2785 USA Phone: 1-734-764-9993 Fax: 1-734-647-3185 E-mail: web@merit.edu Calhoun expires January 1999 [Page 64]