idnits 2.17.1 draft-ietf-roamops-cert-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 27 has weird spacing: '...t>, and expir...' == Line 250 has weird spacing: '...t>, and expir...' -- 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.) -- The document date (11 February 1999) is 9199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 175 looks like a reference -- Missing reference section? '8' on line 196 looks like a reference -- Missing reference section? '7' on line 193 looks like a reference -- Missing reference section? '11' on line 206 looks like a reference -- Missing reference section? '3' on line 181 looks like a reference -- Missing reference section? '2' on line 178 looks like a reference -- Missing reference section? '4' on line 184 looks like a reference -- Missing reference section? '5' on line 188 looks like a reference -- Missing reference section? '6' on line 190 looks like a reference -- Missing reference section? '9' on line 200 looks like a reference -- Missing reference section? '10' on line 203 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track 5 6 11 February 1999 8 Certificate-Based roaming 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1999. Please send comments 28 to the authors. 30 2. Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 3. Abstract 36 To date, roaming implementations have been based on the concept of proxy 37 chaining, where packets are routed between the NAS and home server 38 through a series of proxies. While commonly used, proxy chaining 39 introduces difficult security problems that have prevented its 40 implementation on a wide scale. 42 This document describes a new approach to roaming based on certificates 43 that eliminates the need for proxy chaining. As described, this approach 44 provides improved security as well as scalability. 46 4. Introduction 48 As noted in [1], roaming implementations have been based on the concept 49 of proxy chaining, where packets are routed between the NAS and home 50 server through a series of proxies. Current roaming implementations 51 based on proxy chaining as described in [8] provide only hop-by-hop 52 security, guarding only against modification of packets in transit 53 between hops. This makes it possible for untrusted proxies to modify 54 packets sent between a NAS and a home server without detection, as well 55 as to decrypt PAP passwords, Tunnel passwords, and other hidden 56 attributes which are available to proxies in cleartext. These security 57 issues have to date prevented the implementation of roaming on a wide 58 scale. 60 This document describes a new approach to roaming based on certificates 61 that eliminates the need for proxy chaining. As described, this approach 62 provides improved security as well as scalability. 64 5. Requirements language 66 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 67 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 68 described in [7]. 70 6. Certificate-based roaming 72 In certificate-based roaming, the user utilizes a public-key based 73 smartcard or other certificate in order to authenticate to the local 74 ISP. This is accomplished through use of an EAP-based certificate 75 authentication protocol such as EAP-TLS, described in [11]. 77 Through use of certificate-based authentication, it is possible for the 78 local ISP authentication server to verify the user's identity without 79 the need to proxy the authentication to the home server. In order to 80 achieve proxy-less authorization, the authorization parameters are 81 derived from the certificate. This can be achieved either by embedding 82 the authorization parameters directly, or by deriving them from 83 certificate parameters such as the Network Access Identifier, described 84 in [3]. 86 In this model, it is necessary for a chain of trust to be established 87 between the user and the local ISP. In the simplest case this can be 88 accomplished by presenting a certificate signed by a trusted third 89 party, such as a roaming association to which the local ISP belongs. 90 Note that in order to verify that the user certificate remains valid, 91 the local authentication server will typically need to check the 92 Certificate Revocation List (CRL). 94 Since certificate-based roaming eliminates the use of proxy 95 authentication and authorization, the home server no longer receives 96 authentication and authorization requests from the local ISP. As a 97 result, a mechanism must be provided for verification of the resulting 98 charges. In particular, it is desirable to be able to prove that the 99 user requested service at the date, time and place claimed by the local 100 ISP. 102 This can be achieved as part of the EAP-based certificate authentication 103 protocol. For example, if the user were to use a smartcard or 104 certificate in order to sign a ticket providing information on the 105 number called, NAI used, time of day, date, etc. then this ticket could 106 be included in the local ISP accounting packet and would represent proof 107 of the user access attempt. Since the time of day and NAI are embedded 108 in the ticket, it would not be possible to replay the ticket in order to 109 commit fraud. 111 7. Security issues 113 The following security threats have been identified in roaming systems: 115 Rogue proxies 116 Theft of passwords 117 Theft of accounting data 118 Replay attacks 119 Connection hijacking 120 Fraudulent accounting 122 Certificate-based roaming reduces or eliminates each of these threats. 124 7.1. Rogue proxies 126 In certificate-based roaming, authentication and authorization need not 127 be proxied from the local ISP to the home server. As a result, where the 128 local ISP is operating a dedicated network, the authentication request 129 never leaves the local ISP domain and the risk of rogue authentication 130 proxies is eliminated. 132 The risk of rogue accounting proxies is also reduced, since it is no 133 longer necessary to proxy the accounting packets back to the home server 134 in order to provide proof of usage. Since the user signs a ticket 135 certifying the access attempt as part of authentication, it is only 136 necessary to send the accounting packet to the settlement agent. If 137 audited, the settlement agent can then produce the ticket to provide 138 verification. 140 7.2. Theft of passwords or keys 142 In certificate-based roaming, no passwords are sent in the clear, and it 143 is not necessary to derive a session key unless PPP encryption is 144 desired. Avoiding key derivation reduces the need to transmit the 145 derived key between the authentication server and the local ISP NAS 146 handling the user, this eliminating the risk of key compromise. 148 7.3. Integrity and confidentiality of accounting data 150 While certificate-based roaming does not provide for confidentiality in 151 accounting data, it does provide for integrity protection through use of 152 a digital signature. 154 7.4. Replay attacks 156 By signing a ticket including the time of day, NAI and called phone 157 number, certificate-based roaming eliminates the risk of replay attacks. 159 7.5. Connection hijacking 161 Since certificate-based roaming avoids proxying of authentication and 162 authorization, the risk of connection hijacking is reduced. This risk 163 can be further minimized via integrity protection during the user 164 authentication process, thereby preventing modification of the packets 165 in transit. 167 7.6. Fraudulent accounting 169 Through use of a signed ticket, certificate-based roaming prevents 170 accounting for non-existent sessions. It does not however prevent 171 submission of exaggereated session times for actual sessions. 173 8. References 175 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming 176 Implementations", RFC 2194, September 1997. 178 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 179 Protocols", RFC 2477, January 1999. 181 [3] Aboba, B., and M. Beadles, "The Network Access Identifier", 182 RFC 2486, January 1999. 184 [4] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 185 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 186 1997. 188 [5] Rigney, C., "RADIUS Accounting." RFC 2139, April 1997. 190 [6] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 191 1321, April 1992. 193 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 194 Levels", BCP 14, RFC 2119, March 1997. 196 [8] Aboba, B., Vollbrecht, J.R., "Proxy Chaining and Policy 197 Implementation in Roaming", Internet draft (work in progress), 198 draft-ietf-roamops-auth-09.txt, December 1998. 200 [9] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 201 (EAP)", RFC 2284, March 1998. 203 [10] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 204 November 1998. 206 [11] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", draft- 207 ietf-pppext-eaptls-05.txt, Internet Draft (work in progress), 208 January 1999. 210 9. Acknowledgments 212 Thanks to Glen Zorn of Microsoft for useful discussions of this problem 213 space. 215 10. Authors' Addresses 217 Bernard Aboba 218 Microsoft Corporation 219 One Microsoft Way 220 Redmond, WA 98052 222 Phone: 206-936-6605 223 EMail: bernarda@microsoft.com 225 11. Full Copyright Statement 227 Copyright (C) The Internet Society (1999). All Rights Reserved. 228 This document and translations of it may be copied and furnished to 229 others, and derivative works that comment on or otherwise explain it or 230 assist in its implmentation may be prepared, copied, published and 231 distributed, in whole or in part, without restriction of any kind, 232 provided that the above copyright notice and this paragraph are included 233 on all such copies and derivative works. However, this document itself 234 may not be modified in any way, such as by removing the copyright notice 235 or references to the Internet Society or other Internet organizations, 236 except as needed for the purpose of developing Internet standards in 237 which case the procedures for copyrights defined in the Internet 238 Standards process must be followed, or as required to translate it into 239 languages other than English. The limited permissions granted above are 240 perpetual and will not be revoked by the Internet Society or its 241 successors or assigns. This document and the information contained 242 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 243 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 244 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 248 12. Expiration Date 250 This memo is filed as , and expires 251 August 1, 1999.