idnits 2.17.1 draft-calhoun-diameter-authent-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 63 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 64 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... MUST This word, or the adject...' RFC 2119 keyword, line 130: '... MUST NOT This phrase means that t...' RFC 2119 keyword, line 133: '... SHOULD This word, or the adject...' RFC 2119 keyword, line 139: '... MAY This word, or the adject...' RFC 2119 keyword, line 141: '...hich does not include this option MUST...' (233 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 2967, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-03 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-03) exists of draft-calhoun-diameter-eap-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-authent-04.txt William Bulley 5 Date: July 1998 Merit Network, Inc. 7 DIAMETER 8 User Authentication Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 DIAMETER is a Policy and AAA protocol which can be used for a variety 32 of services. This document defines DIAMETER messages that are used 33 for the authentication, authorization and accounting of users. 35 A considerable amount of effort was put into the design of this 36 protocol to ensure that an implementation could support both DIAMETER 37 and RADIUS concurrently. 39 Table of Contents 41 1.0 Introduction 42 1.1 Specification of Requirements 43 2.0 Command Codes 44 2.1 Domain-Discovery-Request 45 2.2 Domain-Discovery-Answer 46 2.3 AA-Request 47 2.4 AA-Answer 48 2.5 AA-Challenge-Ind 49 3.0 DIAMETER AVPs 50 3.1 User-Name 51 3.2 User-Password 52 3.3 CHAP-Password 53 3.4 NAS-Port 54 3.5 Service-Type 55 3.6 Framed-Protocol 56 3.7 Framed-IP-Address 57 3.8 Framed-IP-Netmask 58 3.9 Framed-Routing 59 3.10 Filter-Id 60 3.11 Framed-MTU 61 3.12 Framed-Compression 62 3.13 Login-IP-Host 63 3.14 Login-Service 64 3.15 Login-TCP-Port 65 3.16 Reply-Message 66 3.17 Callback-Number 67 3.18 Callback-Id 68 3.19 Framed-Route 69 3.20 Framed-IPX-Network 70 3.21 State 71 3.22 Class 72 3.23 Vendor-Specific 73 3.24 Session-Timeout 74 3.25 Idle-Timeout 75 3.26 Termination-Action 76 3.27 Called-Station-Id 77 3.28 Calling-Station-Id 78 3.29 Proxy-State 79 3.30 Login-LAT-Service 80 3.31 Login-LAT-Node 81 3.32 Login-LAT-Group 82 3.33 Framed-AppleTalk-Link 83 3.34 Framed-AppleTalk-Network 84 3.35 Framed-AppleTalk-Zone 85 3.36 CHAP-Challenge 86 3.37 NAS-Port-Type 87 3.38 Port-Limit 88 3.39 Login-LAT-Port 89 3.40 Filter-Rule 90 3.41 Framed-Password-Policy 91 3.42 Table of Attributes 92 4.0 Protocol Definition 93 4.1 Feature Advertisement/Discovery 94 4.2 Authorization Procedure 95 4.3 Integration with Resource-Management 96 4.4 RADIUS Proxies 97 4.5 DIAMETER Proxies 98 4.6 Domain Discovery 99 5.0 References 100 6.0 Acknowledgements 101 7.0 Authors' Addresses 103 1.0 Introduction 105 This document describes the DIAMETER User Authentication Extensions 106 that can be used for a variety of services including Dial-up users 107 via NAS, WWW User Authentication, Firewall User Authentication[5][6]. 109 This document describes Authentication/Authorization messages as well 110 as a set of messages which allow DIAMETER hosts to bypass proxies. 112 Since Most of the AVPs found in this document was copied from the 113 RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER 114 servers read the same dictionary and users files. The backward 115 compatibility that DIAMETER offers is intended to facilitate 116 deployment. 118 The Extension number for this draft is two (2). This value is used in 119 the Extension-Id AVP as defined in [2]. 121 1.1 Specification of Requirements 123 In this document, several words are used to signify the requirements 124 of the specification. These words are often capitalized. 126 MUST This word, or the adjective "required", means that the 127 definition is an absolute requirement of the 128 specification. 130 MUST NOT This phrase means that the definition is an absolute 131 prohibition of the specification. 133 SHOULD This word, or the adjective "recommended", means that 134 there may exist valid reasons in particular circumstances 135 to ignore this item, but the full implications must be 136 understood and carefully weighed before choosing a 137 different course. 139 MAY This word, or the adjective "optional", means that this 140 item is one of an allowed set of alternatives. An 141 implementation which does not include this option MUST 142 be prepared to interoperate with another implementation 143 which does include the option. 145 2.0 Command Codes 147 This document defines the following DIAMETER Commands. All DIAMETER 148 implementations supporting this extension MUST support all of the 149 following commands: 151 Command Name Command Code 152 ----------------------------------- 153 Domain-Discovery-Request 261 154 Domain-Discovery-Answer 262 155 AA-Request 263 156 AA-Answer 264 157 AA-Challenge-Ind 265 159 2.1 Domain-Discovery-Request (DDR) 161 Description 163 The Domain-Discovery-Request message is used by a DIAMETER device 164 wishing to get contact information about a domain's home 165 authentication server as well as to receive password policy 166 information. This message MUST contain the User-Name attribute in 167 order to pass along the user's domain information. 169 The X509-Certificate or the X509-Certificate-URL [2] MUST be 170 present in this message in order to inform the home authentication 171 server of the issuing host's certificate. 173 Message Format 175 ::= 176 177 178 [] 179 180 [] 181 [] 182 183 184 { || 185 ::= 261 262 263 [] 264 265 [] 266 [] 267 268 269 { || 270 ::= 338 339 340 341 [] 342 { || 343 345 346 347 { || 348 ::= 439 440 441 442 443 [] 444 445 446 447 { || 448 538 539 540 541 542 [] 543 544 545 546 { || 547 +------+ ------> +------+ 2740 | | | | | | 2741 | NASB +--------------------+ RADB +--------------------+ RADA | 2742 | | | | | | 2743 +------+ <----- +------+ <------ +------+ 2744 (Access-Accept) (Access-Accept) 2746 The example shown above NASB generates an authentication request on 2747 behalf of the dial-in user to the RADB Authentication server. In this 2748 case, the user's identity would include a domain identifier [3] that 2749 would enable RADB to identify the authentication server (i.e. 2750 user@ISPA.com). 2752 The RADB server then forwards the request to RADA which authenticates 2753 the user based on information found within the request. If 2754 successfully authenticated the RADA server returns a successful 2755 response along with authorization information. If the user 2756 authentication fails RADA replies with a failed response. 2758 In the past this model has caused much concern over it's security 2759 implication. The model is much worse in the when there exists an 2760 intermediate provider between ISPB and ISPA (say ISPC). The following 2761 diagram depicts such an example where RADB must forward any requests 2762 for RADA through RADC. 2764 (Accounting-Request) (Accounting-Request) 2765 +------+ -----> +------+ ------> +------+ 2766 | | | | | | 2767 | RADB +--------------------+ RADC +--------------------+ RADA | 2768 | | | | | | 2769 +------+ <----- +------+ <------ +------+ 2770 (Accounting-Response) (Accounting-Response) 2772 The problem with the above scenario is that complete trust is placed 2773 in RADC (and hence ISPC) since it is very simple to modify any 2774 attributes found within the request or the response. The example 2775 shows an accounting request sent from RADB to RADA through RADC. The 2776 following is a list of a few attacks which can be generated by a 2777 malicious proxy: 2779 - Generating Accounting Records by replaying old 2780 authentication/accounting records. In this example it is very 2781 simple for RADC to simple retain old packets and replay then at a 2782 later date. This will cause RADA to "pay" for services which were 2783 never rendered. 2785 - Modify Attributes within the request or response. In this case 2786 RADC can modify attributes, such as the length of the call, that 2787 would fool RADA into believing the call was longer than in 2788 reality. 2790 - Stealing PAP Passwords is another problem with today's proxies. 2791 In the current model PAP passwords are encrypted using a shared 2792 secret which is shared between each hop in the proxy chain. In 2793 this case each hop has the opportunity to decrypt, and possibly 2794 save for future use, the user's password. 2796 Given the problems identified above with the current proxy model it 2797 is necessary to create a mechanism which allows for non-repudiation, 2798 end-to-end data integrity as well as end-to-end encryption. Given the 2799 current encryption technology this can only be achieved with the use 2800 of asymetric encryption and digital signatures. 2802 4.5 DIAMETER Proxies 2804 The DIAMETER protocol also makes use of proxies in order to keep the 2805 existing arrangements while migrating from RADIUS to DIAMETER. 2806 However since DIAMETER makes use of asymetric encryption and digital 2807 signatures it solves many of the problems shown above. 2809 (AA-Request) (AA-Request) 2810 +------+ -----> +------+ ------> +------+ 2811 | | | | | | 2812 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 2813 | | | | | | 2814 +------+ <----- +------+ <------ +------+ 2815 (AA-Answer) (AA-Answer) 2817 In this example NASB generates an AA-Request that is forwarded to 2818 DIA2. The AA-Request contains a digital signature AVP which 2819 "protects" all mandatory (or non-editable) AVPs within the request. 2820 All AVPs which may be modified, or removed appear after the digital 2821 signature AVP. Once DIA2 receives the request, it MAY authenticate 2822 the request to ensure that it was originated by NASB (verifying the 2823 signature is not necessary if the link between NASB and DIA2 is 2824 secured using IPSEC). 2826 The DIA2 Server may then add new attributes to the request. All 2827 mandatory AVPs MUST be present prior to the non mandatory AVPs and 2828 MUST be preceeded by a Digital Signature AVP (using DIA2's private 2829 key). Note that all non-mandatory AVPs added to the packet by NASB 2830 must appear after DIA2's digital signature AVP. The message is then 2831 forwarded towards the DIA1 server. 2833 Since all packets between NASB and DIA1 must flow through DIA2, it is 2834 not possible to use IPSEC between both hosts. Therefore DIA1 MUST 2835 validate NASB's digital signature AVP. However it is not necessary to 2836 validate DIA2's digital signature if the link between DIA2 and DIA1 2837 is secured using IPSEC. 2839 This mechanism now provides a method for DIA1 to prove that NASB was 2840 the initiator of the request (note that DIAMETER also includes a 2841 timestap to prevent replay attacks). It also provides a method of 2842 ensuring that DIA2 cannot modify any "non-editable" attributes (such 2843 as length of call, etc). 2845 In addition, this same mechanism can be used for end-to-end 2846 encryption of AVPs. In the case where NASB needs to encrypt an AVP it 2847 is done using asymetric encryption using DIA1's public key. This 2848 ensures that only DIA1 can decrypt the AVP. 2850 An attack has been identified in this proposal which allows a 2851 malicous man in the middle attack as shown in the following diagram. 2853 (AA-Request) (AA-Request) (AA-Request) 2854 +------+ -----> +------+ -----> +------+ -----> +------+ 2855 | | | | | | | | 2856 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 2857 | | | | | | | | 2858 +------+ <----- +------+ <----- +------+ <----- +------+ 2859 (AA-Answer) (AA-Answer) (AA-Answer) 2861 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 2862 removes the AVPs added by DIA2 and inserts its own AVPs (posibly by 2863 trying to convince DIA1 to pay DIA3 for the services). This attack 2864 can be prevented by supporting a new Next-Hop AVP. In this case when 2865 NASB prepares a request it inserts a non-editable Next-Hop AVP which 2866 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 2867 as the next hop. 2869 This mechanism ensures that a man in the middle cannot alter the 2870 packet by overriding the previous hop's additions and signature. DIA1 2871 could easily validate the packet's path with the use of the Next-Hop 2872 AVPs. 2874 4.6 Domain Discovery 2875 The Domain Discovery message set is very useful in determining the 2876 Home authentication server, the password policies for the domain, as 2877 a mechanism to retrieve a certificate (or a pointer to a 2878 certificate). 2880 The following example shows a case where DIA1 needs to communicate 2881 with DIA3. In this example it is necessary to use DIA2 as a proxy in 2882 order for both ISPs to communicate. Although this MAY be desireable 2883 in some business models, there are cases where it is beneficial to 2884 remove the proxy altogether and allow both DIA3 and DIA1 to 2885 communicate in a secure fashion. 2887 (DD-Request) (DD-Request) 2888 +------+ -----> +------+ ------> +------+ 2889 | | | | | | 2890 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 | 2891 | | | | | | 2892 +------+ <----- +------+ <------ +------+ 2893 (DD-Response) (DD-Response) 2895 The way the Domain Discovery works is that prior to sending out an 2896 authentication request DIA1 would issue a Domain Discovery message 2897 towards DIA2. This message is protected with the digital signature as 2898 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 2899 including the Next-Hop and the digital signature AVP. 2901 When DIA3 receives the request, it MUST save the certificate (or the 2902 pointer to the certificate) and respond back including the local 2903 password policy, DIA3's certificate, it's contact information (i.e. 2904 IP address) and protect the response with the digital signature. 2906 Note that in all cases the TimeStamp AVP is also present to ensure no 2907 reply packets are accepted. 2909 When DIA2 receives the packet, it must add the Next-Hop AVP as well 2910 as the digital signature AVP. When DIA1 receives the packet it then 2911 knows a direct route to communicate with DIA3 since the contact 2912 information is present in the response. The fact that both DIA1 and 2913 DIA3 can now communicate directly allows both peers to use IPSEC to 2914 protect the message exchange (note that it MAY be desirable to also 2915 use the digital signature in order to keep the information in the 2916 DIAMETER logs). 2918 (AA-Request) 2919 +------+ -----> +------+ 2920 | | | | 2921 | DIA1 +--------------------+ DIA3 | 2922 | | | | 2923 +------+ <----- +------+ 2924 (AA-Answer) 2926 In addition, the password policy is also present which can indicate 2927 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 2929 Note that the Domain-Discovery-Request/Answer MAY include the 2930 Supported-Extension AVPs [2]. 2932 5.0 References 2934 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 2936 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 2937 draft-calhoun-diameter-03.txt, May 1998. 2939 [3] Aboba, Beadles, "Network Address Identifier", Internet- 2940 Draft, draft-ietf-roamops-nai-10.txt, February 1998. 2942 [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, 2943 July 1997. 2945 [5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication 2946 Protocol Extensions", Internet-Draft, draft-calhoun- 2947 diameter-eap-01.txt, March 1998. 2949 [6] Calhoun, Haag, Zorn, "EAP Authentication for SOCKS 2950 Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998. 2952 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2953 links", RFC 1144, February 1990. 2955 [8] ISO 8859. International Standard -- Information Processing -- 2956 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2957 Alphabet No. 1, ISO 8859-1:1987. 2958 2960 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2961 (MP)", RFC 1717, November 1994. 2963 [10] Calhoun, Greene, "DIAMETER Resource Management Extension", 2964 Internet-Draft, draft-calhoun-diameter-res-mgmt-01.txt, 2965 May 1998. 2967 [11] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 2968 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 2970 6.0 Acknowledgements 2972 The Author wishes to thank Carl Rigney since much of the text in the 2973 document was shamefully copied from [1] as well as the following 2974 people for their help in the development of this protocol: 2976 Nancy Greene, Ryan Moats 2978 7.0 Authors' Addresses 2980 Questions about this memo can be directed to: 2982 Pat R. Calhoun 2983 Technology Development 2984 Sun Microsystems, Inc. 2985 15 Network Circle 2986 Menlo Park, California, 94025 2987 USA 2989 Phone: 1-650-786-7733 2990 Fax: 1-650-786-6445 2991 E-mail: pcalhoun@eng.sun.com 2993 William Bulley 2994 Merit Network, Inc. 2995 4251 Plymouth Road, Suite C 2996 Ann Arbor, Michigan, 48105-2785 2997 USA 2999 Phone: 1-734-764-9993 3000 Fax: 1-734-647-3185 3001 E-mail: web@merit.edu