idnits 2.17.1 draft-ietf-roamops-sec-00.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-03-28) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 586 lines 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 92: '... MUST This word, or the adjective "re...' RFC 2119 keyword, line 99: '... MUST NOT This phrase means that the ...' RFC 2119 keyword, line 102: '... SHOULD This word, or the adjective "...' RFC 2119 keyword, line 107: '... MAY This word, or the adjective "opt...' RFC 2119 keyword, line 109: '...h does not include this option MUST be...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A proxy Radius server must strip the Signature attribute, if present, in an Access-Request packet received from a NAS or an up-stream Radius server and must add its own Signature attribute to the packet when sending to the down-stream Radius server. An Access-Request packet MUST not contain more than one Signature attribute. -- 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 (October 1997) is 9661 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: '6' is mentioned on line 293, but not defined == Missing Reference: '7' is mentioned on line 344, but not defined == Missing Reference: '8' is mentioned on line 393, but not defined == Missing Reference: '9' is mentioned on line 443, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-05 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '2') ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '5') Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Yuan John Jiang 3 Internet Draft MCI 4 expires in six months October 1997 6 Secure Radius Server Operation Guidelines for Dial Roaming 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use 20 Internet-Drafts as reference material or to cite them other 21 than as work in progress. 23 To learn the current status of any Internet-Draft, please check 24 the id-abstracts.txt listing contained in the Internet-Drafts 25 Shadow Directories on ds.internic.net (US East Coast), 26 ic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 27 munnari.oz.au (Pacific Rim). 29 The distribution of this memo is unlimited. It is filed as 30 , and expires in April, 1998. 31 Please send comments to the author. 33 Abstract 35 Authenticating and authorizing roaming dialup users requires 36 messages to be exchanged among facilities managed by two or 37 more service providers, and secure operation of the facilities 38 is of vital importance. This document provides guidelines for 39 operating such facilities when using the Remote Authentication 40 Dial In User Service (RADIUS) protocol and the companion 41 accounting protocol for authentication and accounting message 42 exchange. 1 44 Y. J. Jiang [1] 46 October, 1997 48 1 Introduction 50 Internet dial roaming is described in [1] and demonstrated in 51 [2]. Such a service usually requires that user authentication 52 messages be exchanged among facilities administrated by 53 different service providers. 55 It is common practice to use the RADIUS protocol as defined in 56 [3] for authentication and the RADIUS accounting protocol [4] 57 for accounting message exchanges. The protocols have a few 58 weaknesses, which make roaming services particularly prone to 59 security risks. 61 This document does not intend to invent new schemes to overcome 62 difficulties in secure operation but rather defines good 63 practices within the limits of the current RADIUS framework. 65 1.1 Terminology 67 This document frequently uses the following terms: 69 Network Access Server (NAS) 70 A network device that users dial up in order to obtain access 71 to the network. 73 RADIUS server 74 A network component that receives RADIUS or Accounting 75 Request packets. 77 Home RADIUS server 78 A Radius server that verifies a dialup user's identity. 80 Proxy RADIUS server 81 An intermediate Radius server between a NAS and a home Radius 82 server used to relay and modify RADIUS or Accounting packets. 83 A proxy server acts as a RADIUS client to the downstream 84 Radius server and a server to an upstream server or a NAS. 86 1.2 Specification of Requirements 88 In this document, several words are used to signify the 89 requirements of the specification. These words are often 90 capitalized. 92 MUST This word, or the adjective "required", means that the 93 definition is an absolute requirement of the specification. 95 Y. J. Jiang [2] 97 October, 1997 99 MUST NOT This phrase means that the definition is an absolute 100 prohibition of the specification. 102 SHOULD This word, or the adjective "recommended", means that 103 there may exist valid reasons in particular circumstances to 104 this item, but the full implications must be understood and 105 carefully weighed before choosing a different course. 107 MAY This word, or the adjective "optional", means that this 108 item is one of an allowed set of alternatives. An 109 implementation which does not include this option MUST be 110 prepared to interoperate with another implementation which 111 does include the option. 113 1.3 RADIUS and dial roaming 115 The primitive use of RADIUS protocol is for the authentication 116 message exchange between a NAS receiving a user's call and a 117 Radius authentication server maintaining the user database. 118 RADIUS 119 NAS <---------> RADIUS Server 120 Typically, the NAS sends the server an Access-Request packet 121 containing the user's username, authentication data and 122 requested service and resource information, and the server 123 replies with an Access-Reject or Access-Accept packet 124 containing the rejection reason or the information on the 125 service and resources authorized for the user. The accounting 126 Request and response packets are exchanged in a similar 127 fashion. 129 In dial roaming, to authenticate a user, message exchanges are 130 not limited to one client and one server. At least one proxy 131 Radius server is involved between the NAS and the home Radius 132 authentication server containing the user database. 133 RADIUS RADIUS 134 NAS <-------> Proxy RADIUS Server <-------> Home RADIUS Server 135 More complicated operation models described in [2] involve two 136 or more cascading proxy Radius servers or one RADIUS packet 137 branched out to two or more Radius servers. For roaming user 138 authentication, authorization and accounting, the Radius 139 facilities -- the NASs and the proxy and home Radius servers -- 140 are managed by different service providers, and the RADIUS 141 packets are transported over the public network beyond the 142 control of the NAS and the home Radius server operators. 143 Security risks increase because authentication and accounting 145 Y. J. Jiang [3] 147 October, 1997 149 packets have much higher chance than in a single operator 150 environment to be captured, modified and injected by 151 adversaries. 153 2 Security weaknesses in RADIUS protocol 155 2.1 Packet integrity and sender identity checking 157 A Radius client and server maintain between them a shared 158 secret. If a server can derive from a received packet that the 159 sender has the correct IP address and knows the shared secret, 160 it is convinced of the client's identity. The same scheme 161 applies when a client checks a server's identity from a 162 response packet received. 164 RADIUS protocol and the accounting protocol frequently use an 165 Authenticator field in combination with the shared secret to 166 check packet integrity and sender identity. For example, the 167 Authenticator is the MD5 digest of 168 Accounting-Request Code + Identifier + zero-filled Authenticator 169 + Attributes + Shared Secret 170 for an Accounting-Request packet or 171 Response Code + Identifier + Request Authenticator + Attributes 172 + Shared Secret 173 for an Access or Accounting Response packet. 175 RADIUS Access-Request packets, however, contain no packet 176 integrity checking fields, nor have they sender identity 177 checking fields unless User-Password attributes are present. 178 An Authenticator field in an Access-Request packet is a random 179 number and does not offer any packet integrity checking. A 180 User-Password attribute is the plain-text user password encoded 181 with the MD5 digest of the octet stream consisting the shared 182 secret and the Authenticator. 184 A home Radius server has the correct user password in its user 185 database to compare with the one decoded from the User-Password 186 attribute. When the comparison is successful, it can be sure 187 of the NAS's identity; otherwise, it cannot tell whether the 188 sender does not know the shared secret or does not have the 189 correct user password. Further, the User-Password attribute 190 does not help at all a proxy server, which does not have the 191 correct user password at hand, to check the packet sender's 192 identity. 194 Y. J. Jiang [4] 196 October, 1997 198 2.2 Hop-by-hop vs. end-to-end security 200 In dial roaming, the packet sender identity and message 201 integrity checking mechanism used between a client and server 202 described above is carried over to the checking between the 203 RADIUS components in every hop. This is considered an 204 advantage. For example, an intermediate hop may provide some 205 user services, which require modification of the attributes in 206 the Access-Request and Access-Accept packets to reflect the 207 resources requested and the resources authorized according to 208 the service specifics. 210 On the other hand, for user authentication, this hop-by-hop 211 model is considered to be less secure than full end-to-end 212 authentication if the intermediate hops cannot be fully 213 trusted. This is the case when an adversary can pose as a 214 legitimate RADIUS component in the chain of packet passage, or 215 when some of the intermediate proxy servers may alter the 216 packet content beyond their business contract or legal 217 capacities or even inject fraudulent packets in the passage. 219 The hop-by-hop vs. end-to-end dilemma arises from the facts 220 that RADIUS protocol is used not only for authentication but 221 also for resource authorization purposes and that the 222 intermediate Radius servers in a proxy chain are often needed 223 to play roles in resource authorization rather than simply for 224 packet relay. 226 The attributes a Radius server is interested in depends on the 227 role it plays. However, a Radius server may play more than one 228 role, and more than one server may be interested in the same 229 attributes. Framed-IP-Address attribute in an Access-Accept 230 packet, for example, is assigned sometimes by the NAS 231 operator's Radius server and sometimes by the home Radius 232 server. 234 2.3 Data confidentiality 236 RADIUS protocol and the companion accounting protocol have no 237 attribute information hiding capability except on 238 authentication credential attributes such as User-Password. 239 The password hiding in CHAP-Password attribute is inherent from 240 CHAP, but the password hiding in a User-Password attribute is 241 limited considering the intermediate RADIUS components not 242 involved in user authentication can decode the password. 244 Y. J. Jiang [5] 246 October, 1997 248 User password checking is usually the role of the home Radius 249 server. No intermediate Radius servers should have any 250 business in the User-Password attribute, but unfortunately they 251 all can decode and even edit the user password. 253 The lack of data confidentiality leaves exposed 254 - dialup users' usage information, 255 - network operators' facility information, and 256 - service providers' customer bases. 257 It puts users' privacy and service providers and operators' 258 trade secret at risk. 260 It would be desirable if an attribute could be inspected only 261 by the designated RADIUS facility. 263 2.4 Using IPsec 265 Many have suggested using IPsec to overcome the security 266 problems with RADIUS and the accounting protocols. This may 267 help in packet integrity and sender identity checking, 268 preventing replay attacks and, to some extent, data 269 confidentiality. However, as a lower layer measure, IPsec 270 cannot solve the hop-by-hop vs. end-to-end dilemma in the upper 271 layer and prevent a proxy server from tampering with attributes 272 beyond its intended scope. 274 2.5 Attribute level security 276 The ultimate solution to the hop-by-hop vs. end-to-end dilemma 277 and the data confidentiality problem lies with attribute level 278 security, with which an attribute can be inspected and edited 279 only by the specified Radius servers in the proxy chain. 280 However, RADIUS, designed as a simple protocol, is not likely 281 ever to be extended to include attribute level security. 282 Without attribute level security, the length of a proxy chain 283 and the complexity of a roaming relation are limited by trust, 284 and proxy servers should not be used only for packet relay 285 without any other benefit. 287 3 Security risks 289 Because of the above RADIUS protocol weaknesses, the immediate 290 risks in roaming user authentication are 291 - theft of user passwords, 293 Y. J. Jiang [6] 295 October, 1997 297 - theft of services, 298 - denial of services, and 299 - fraudulent packet injection. 301 For example, lack of Access-Request packet sender identity 302 checking unless a User-Password attribute is used gives an 303 adversary a chance to pose as a legitimate RADIUS client using 304 IP spoofing techniques. This adversary can take advantage of 305 lack of message integrity and sender identity checking 306 - to launch a dictionary attack and obtain a user's CHAP 307 password, 308 - to replay a captured Access-Request packet and exhaust the 309 resources 310 authorized to a user, or 311 - to replay captured Access-Request packets and overload the 312 Radius server. 314 4 Signature attribute 316 An Internet Draft [5] has proposed adding a Signature attribute 317 to overcome the security weakness in checking sender identity 318 and content integrity of Access-Request packets. The content 319 of the attribute is an MD-5 [3] digest of the shared secret 320 followed by the entire Access-Request packet, including the 321 Code, ID, Length and Authenticator. When the digest is 322 calculated the signature string is filled with sixteen octets 323 of zero. 325 At this writing, a few NAS vendors have planned to implement 326 this feature in their products. In a roaming relation, the 327 Signature attribute MUST be used in any Access-Request packet 328 sent across administrative boundaries. This attribute should 329 be used even when the packet contains a User-Password 330 attribute. 332 A proxy Radius server must strip the Signature attribute, if 333 present, in an Access-Request packet received from a NAS or an 334 up-stream Radius server and must add its own Signature 335 attribute to the packet when sending to the down-stream Radius 336 server. An Access-Request packet MUST not contain more than 337 one Signature attribute. 339 5 Authenticator 341 The Authenticator field in an Access-Request packet must be 342 used strictly accordingly to [3]. Otherwise, intercepted 344 Y. J. Jiang [7] 346 October, 1997 348 Access-Request packets can be replayed by an adversary for 349 denial of service attacks, and intercepted Access-Accept 350 packets can be used for theft of services. 352 The RADIUS protocol specification states: 354 In Access-Request Packets, the Authenticator value is a 16 355 octet random number, called the Request Authenticator. The 356 value SHOULD be unpredictable and unique over the lifetime 357 of a secret (the password shared between the client and the 358 RADIUS server), since repetition of a request value in 359 conjunction with the same secret would permit an attacker to 360 reply with a previously intercepted response. Since it is 361 expected that the same secret MAY be used to authenticate 362 with servers in disparate geographic regions, the Request 363 Authenticator field SHOULD exhibit global and temporal 364 uniqueness. 366 The Request Authenticator value in an Access-Request packet 367 SHOULD also be unpredictable, lest an attacker trick a 368 server into responding to a predicted future request, and 369 then use the response to masquerade as that server to a 370 future Access-Request. 372 A proxy Radius server typically has many clients and with each 373 maintains a different shared secret. It is possible that more 374 than one Accept-Request packet with the same Authenticator 375 content may come from different clients but destined for the 376 same down-stream Radius server. Therefor, to maintain the 377 uniqueness and unpredictable nature of the Authenticator, the 378 proxy server MUST strip the Authenticator from a received 379 Access-Request packet and insert its own when forwarding the 380 packet to the downstream Radius server. 382 This Authenticator alteration may not be compatible with the 383 practice of many NASs when authenticating using Challenge 384 Handshake Authentication Protocol (CHAP). These NASs fill the 385 Authenticator with the 16-byte CHAP challenges. A Radius 386 server identifies this situation by the presence of a 387 CHAP-Password attribute in a received Access-Request packet and 388 the absence a CHAP-Challenge attribute. In this case, the 389 proxy Radius server MUST copy the Authenticator to a 390 CHAP-Challenge attribute and insert its own Authenticator 391 before forwarding the packet to the down-stream Radius server. 393 Y. J. Jiang [8] 395 October, 1997 397 6 User-Password attribute 399 In a proxy chain of a roaming authentication, any intermediate 400 hop can decode the user password contained in a User-Password 401 attribute. The revelation or editing of the user password by 402 intermediate parties imposes security risks. Therefore, this 403 User-Password attribute MAY not be used in roaming user 404 authentication unless a one-time user password system is used. 405 This usually means that PAP may not be used. 407 7 Acknowledgements 409 The author wishes to thank Cesar Cortes of MCI, Sara Lee of 410 Concert and Jill Hacker for insightful comments. 412 8 References 414 [1] B. Aboba, G. Zorn. "Dialing Roaming Requirements." 415 Internet draft (work in progress), 416 draft-ietf-roamops-roamreq-05.txt, Microsoft, July, 1997. 418 [2] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of 419 Roaming Implementations." RFC 2194, Microsoft, Aimnet, i-Pass 420 Alliance, Asiainfo, Merit, September, 1997. 422 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote 423 Authenti-cation Dial In User Service (RADIUS)." RFC 2138, 424 Livingston, Merit, Daydreamer, April, 1997. 426 [4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, 427 April, 1997. 429 [5] C. Rigney, W. Willats. "RADIUS Extensions." Internet 430 draft (work in progress), draft-ietf-radius-ext-00.txt, 431 Livingston, January, 1997. 9 433 Author's Addresse 435 Yuan John Jiang 436 MCI Internet Engineering 437 2100 Reston Parkway 438 Reston, VA 20191 440 Phone: 703-715-7480 441 EMail: yjj@mci.net 443 Y. J. Jiang [9]