idnits 2.17.00 (12 Aug 2021) /tmp/idnits2355/draft-byerly-sip-radius-00.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 13) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 3 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Missing Reference: 'RADIUS' is mentioned on line 76, but not defined == Missing Reference: 'RFC 2617' is mentioned on line 243, but not defined ** Obsolete undefined reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Looks like a reference, but probably isn't: '1' on line 398 -- Looks like a reference, but probably isn't: '2' on line 420 -- Looks like a reference, but probably isn't: '3' on line 437 -- Looks like a reference, but probably isn't: '4' on line 447 -- Looks like a reference, but probably isn't: '5' on line 465 -- Looks like a reference, but probably isn't: '6' on line 482 -- Looks like a reference, but probably isn't: '7' on line 499 -- Looks like a reference, but probably isn't: '8' on line 505 == Unused Reference: 'PAP' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'REQ' is defined on line 623, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2138 (ref. 'RAD') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2617 (ref. 'DIG') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 1334 (ref. 'PAP') (Obsoleted by RFC 1994) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Bryan J. Byerly 2 Internet Draft David Williams 3 draft-byerly-sip-radius-00.txt Cisco Systems 4 October, 2000 5 Expires: March, 2001 7 SIP Authentication using CHAP-Password 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a proposed extension to SIP. This 33 document proposes using an alternative SIP authentication mechanism 34 for use in Proxy-Authorization or Authorization headers in order 35 to support SIP client Authentication using backend RADIUS servers. 37 The introduction of this extension would allow a SIP proxy 38 (or called SIP client) to authenticate a SIP client using a backend 39 RADIUS server. 41 1 Introduction 43 Some ISPs currently use RADIUS servers to authenticate 44 (and implicitly authorize) dialup users for PPP service. 45 It would be advantageous to allow the re-use of this same 46 RADIUS infrastructure for SIP client authentication. 48 Although the currently defined mechanisms for SIP client 49 authentication [section 3.2.2.2 of RFC 2617] and RADIUS 50 authentication using a User-Password or CHAP-Password 51 [sections 5.2, 5.3 of RFC 2138] both use MD5, they run MD5 52 across differently formatted messages. There are two 53 approaches to solving this problem. One is to extend 54 RADIUS to support HTTP-Digest; the other is to extend 55 the SIP list of authentication schemes to support a CHAP-Password. 56 This document proposes extending the SIP list of authentication 57 schemes to support a CHAP-Password. 59 2 Definitions 61 The definitions of several terms used in this document follow: 63 nonce 65 A nonce is a octet string that is uniquely generated each time a 66 request is made. It is recommended that a nonce be constructed 67 to exhibit global and temporal uniqueness. 69 The SIP specification [SIP] calls this a "nonce-value" 70 (Section 3.2.1 of [DIG]). 72 The RADIUS specification calls this a (random) challenge. 73 (Section 2.2 of [RAD]) 74 In RADIUS, the nonce can be placed in the Request Authenticator 75 (Section 4.2 of [RADIUS]) or in the CHAP-Challenge attribute. 76 (Section 5.40 of [RADIUS]) 78 The CHAP Response in the CHAP-Password and the 79 nonce-value in the HTTP-Digest use a 16-octet nonce. 81 sequence number 83 A sequence number is a monotonically increasing integer. 84 Sequence numbers allow detection of replays. 86 The "nonce-count" of the HTTP-Digest is a 32-bit sequence number 87 (formatted as 8 hex digit characters) 89 The "Chap-ID" in the CHAP-Password is a 1 octet sequence number. 91 shared secret 93 A secret shared between two entities. 95 In this document, we assume that: 97 - A user shares a secret (i.e. password) with 98 the RADIUS server. 100 - The PPP NAS (or SIP proxy) also shares a secret 101 with the RADIUS server. 103 3 Analogous Model - PPP 105 When a SIP proxy is used for user authentication 106 an analogy can be drawn from PPP message flows. 108 3.1 Message flow for PPP user authentication with Radius backend: 110 dialup PPP RADIUS 111 user NAS server 112 | | | 113 |--modem connection--->| | 114 | | | 115 | PPP | | 116 |<-Configure-Request---| | 117 | | | 118 | PPP | | 119 |--Configure-Ack------>| | 120 | | | 121 | |--Access-Request------>| 122 | | | 123 | |<-Access-Challenge-----| 124 | | | 125 |<-CHAP Challenge------| | 126 | | | 127 |--CHAP Response------>| | 128 | | | 129 | |--Access-Request------>| 130 | | | 131 | |<-Access-Accept--------| 132 | | | 133 | | | 135 3.2 Message flow for SIP user authentication with Radius backend: 137 SIP SIP RADIUS 138 client proxy server 139 | | | 140 |--[1] INVITE--------->| | 141 | | | 142 | |--[2] Access-Request-->| 143 | | | 144 | |<-[3] Access-Challenge-| 145 | | | 146 |<-[4] 407-------------| | 147 | (Proxy-Authenticate:) | 148 | | | 149 |--[5] INVITE--------->| | 150 |(Proxy-Authorization:) | 151 | | | 152 | |--[6] Access-Request-->| 153 | | | 154 | |<-[7] Access-Accept----| 155 | | | 156 | |--[8] INVITE------------------> 157 | | | 158 . 159 . 160 . 161 |<--200---------------|<--200------------------------ 163 When a PPP client authentication failure occurs, in some 164 cases the PPP NAS implementation terminates the link. 165 However, other PPP NAS implementations may choose to allow 166 the client to continue, but with a filtered list of services. 167 A PPP NAS may allow traffic which lets the user update his credentials 168 (such as email to the sysadmin). 170 Similarly, a SIP proxy server may wish to allow the user to place 171 calls to the ISP's home office (to obtain updated credentials). 172 A SIP proxy server may also wish to allow 911 calls to complete. 174 4 Current PAP/CHAP/SIP/HTTP Authentication mechanisms 176 The following sections briefly describe the current mechanisms 177 used for user authentication in PPP (PAP/CHAP) and HTTP/SIP 178 (Basic and Digest). 180 4.1 PAP authentication mechanism 182 Why not use RADIUS User-Password? 184 The RADIUS User-Password attribute is calculated as: 186 User-Password = md5hash(NAS-secret, nonce) XOR user-password 188 If a PPP user sends his password in cleartext (eg. using PAP), then 189 the PPP server can calculate the User-Password attribute of the 190 Access-Request to authenticate the user. 192 It is undesirable for a SIP user to send his password in cleartext. 194 If the user does NOT send his password in cleartext, 195 the User-Password cannot be calculated by either the PPP client 196 (because he doesn't know the NAS-secret) or the NAS 197 (because he doesn't know the user-password). 199 4.2 CHAP authentication mechanism 201 PPP defines usage of the CHAP-Password (as an alternative 202 to User-Password) to avoid cleartext transmission of the 203 users's password. 205 When a CHAP-Password is used a cleartext sequence number, cleartext 206 nonce, and the following MD5 hash are transmitted by the client: 208 md5hash(seqnum, user-password, nonce) 210 The nonce can be generated by the client or the server. 211 If the nonce is generated by the client, the server may choose 212 to accept it or may challenge the client with a new nonce. 214 4.3 SIP/HTTP authentication mechanisms: 216 SIP and HTTP define two basic authentication mechanisms. 217 HTTP-Basic and HTTP-Digest. Usage of HTTP-Basic involves 218 sending the the user's password in cleartext, and is thus 219 undesirable. 221 The currently defined mechanisms for SIP client authentication 222 using HTTP-Digest are taken from section 3.2.2.2 of RFC 2617 223 and the hash constructions are repeated here for 224 clarity: 226 If the directive's value is "MD5" or is unspecified, then A1 is: 228 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 230 If the directive's value is "MD5-sess", then A1 is 231 calculated only once - on the first request by the client following 232 receipt of a WWW-Authenticate challenge from the server. It uses 233 the server nonce from the challenge, and the first client nonce 234 value to construct A1 as follows: 236 A1 = H( unq(username-value) ":" unq(realm-value) 237 ":" passwd 238 ":" unq(nonce-value) ":" unq(cnonce-value)) 240 This creates a 'session key' for the authentication of subsequent 241 requests and responses which is different for each "authentication 242 session", thus limiting the amount of material hashed with any one 243 key. [RFC 2617] 245 5 Interaction/Mapping problems 247 There are two problems: 249 5.1 CHAP-Password construction problem: 251 If a SIP proxy receives an HTTP-Digest from a SIP client 252 (without CHAP-Password support), the SIP proxy is unable 253 to construct a CHAP-Password. This is because the SIP proxy 254 doesn't have access to the client's password. 255 The SIP proxy only has access to a hash of the client's password, 256 and (as dicussed above) this hash is computed across a 257 message whose format is different than the RADIUS server expects. 259 Nor can the SIP proxy simply forward the hash calculated in 260 the HTTP-Digest: 262 5.2 Message mapping problem: 264 Since the message format over which a hash is computed 265 is different for the CHAP-Password than the message format 266 used for the HTTP-Digest "MD5" or "MD5-sess" algorithms, 267 a RADIUS server could not verify a proxied HTTP-Digest 268 (which uses either the "MD5" or "MD5-sess" algorithms). 269 The RADIUS server would discard such a HTTP-Digest 270 formulated hash as invalid. 272 Here is the proposed solution to these problems: 274 6 SIP Authentication using CHAP-Password 276 To solve these problems, we specify an additional mechanism 277 for SIP authentication which uses a CHAP-Password. CHAP-Password 278 can either be used for endpoint-to-endpoint authentication 279 (when used in WWW-Authenticate and Authorization) or for 280 endpoint-to-proxy authentication (when used in Proxy-Authenticate 281 and Proxy-Authorization). 283 6.1 The WWW-Authenticate Response Header 285 When a CHAP-Password is used for SIP authentication, 286 the WWW-Authenticate Response Header (3.2.2 of RFC 2617) 287 is defined as: 289 WWW-Authenticate = "WWW-Authenticate" ":" "CHAP-Password" chap-challenge 290 chap-challenge = * (";" chap-params ) 291 chap-params = chap-username | chap-algorithm | chap-id | nonce 292 chap-algorithm = "algorithm" "=" ( "MD5" | token ) 293 chap-username = quoted-string 294 chap-id = "id" "=" + ( digit ) 295 chap-nonce = "nonce" "=" nonce-value 296 chap-nonce-value = <"> 32LHEX <"> 297 LHEX = "0" | "1" | "2" | "3" | 298 "4" | "5" | "6" | "7" | 299 "8" | "9" | "a" | "b" | 300 "c" | "d" | "e" | "f" 302 chap-algorithm: A string indicating the authentication 303 method to be used. 305 chap-username: A string containing the user name. 307 chap-id: The CHAP Identifier is a one octet sequence number. 309 nonce: A string of 32 hex digits. The contents of the 310 nonce are implementation dependent. The quality 311 of the implementation depends on a good choice. 312 Example: 314 WWW-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5" 315 ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb" 317 The chap-username is copied from the User-Name attribute 318 of the Access-Challenge message received from the RADIUS server. 320 The chap-id is copied from the (1-octet) Identifier field of the 321 Access-Challenge message received from the RADIUS server. 323 The chap-nonce-value is copied from the Access-Challenge message 324 from the RADIUS server (from the CHAP-Challenge attribute if 325 present, otherwise from the Request Authenticator). 327 6.2 The Authorization Request Header 329 When challenged, the SIP client is expected to retry the request, 330 passing an Authorization header line, which is defined as follows: 332 Authorization = "Authorization" ":" "CHAP-Password" chap-response-line 333 chap-response-line = * (";" chap-response-params ) 334 chap-response-params = chap-username | chap-id | nonce | chap-response 335 chap-response = "response" "=" chap-response-value 336 chap-response-value = <"> 32LHEX <"> 338 chap-response-value: A string of 32 hex digits computed as defined 339 in Section 4.1 of RFC1994, which proves that the user knows a 340 password. 342 Example: 344 Authorization: CHAP-Password ;username="byerly" ;id=0 345 ;nonce="10131973aaa511bb05261975aaa505fb" 346 ;response="f53a66e43c12a383aa65219ec873ce35" 348 The client MUST increment the CSeq header before resubmitting 349 the request. 351 A server MAY be configured not to generate nonces only if replay 352 attacks are not a concern. 354 The Response Value (chap-response-value) of the CHAP-Password is 355 computed per Section 4.1 of RFC 1994 [CHAP]. The 16-octet 356 Response Value of the CHAP-Password should be formatted as 357 32 hex digits and placed in the "chap-response-value" of 358 the Authorization request. 360 The chap-id should be placed in the (1-octet) Identifier field 361 of the Access-Request message to the RADIUS server. The chap-id 362 should also be placed in the (1-octet) CHAP Identifier field 363 of the CHAP-Password attribute of the Access-Request message 364 to the RADIUS server. (See sections 3, 5.3, [RAD]) 366 The nonce-value SHOULD be placed in the Request Authenticator 367 of the Access-Request message to the RADIUS server. 368 (See section 3, [RAD]) 369 Alternatively, the nonce-value MAY be placed in a CHAP-Challenge 370 attribute in the Access-Request message to the RADIUS server. 371 (See section 5.3, [RAD]) 373 The chap-response-value should be placed in the 16-octet 374 String field of the CHAP-Password attribute in the Access-Request 375 message to the RADIUS server. (See section 5.3, [RAD]) 377 7 Proxy-Authenticate and Proxy-Authorization 379 The CHAP-Password authentication scheme may also be used 380 for authenticating users to proxies. 382 8 Security Considerations 384 Security issues are the primary topic of this RFC. 386 The security issues for this document are the same as those 387 in the Security Considerations sections of RFC 1994 [CHAP] 388 and RFC 2617 [DIG]. 390 9 Further Examples 392 Only the relevant headers have been included in the following 393 examples. 395 9.1 User Authentication using backend RADIUS server - 396 With Server Challenge. 398 [1] SIP Client to SIP proxy server: 400 INVITE sip:+19195551212@cisco.com SIP/2.0 401 From: sip:+19195551234@domain.com 402 To: sip:+19195551212@cisco.com 403 Call-ID: 12345600@cisco.com 404 CSeq: 1 INVITE 405 Proxy-Authorization: CHAP-Password 406 ;username="byerly" 407 ;algorithm="MD5" 408 ;id=0 409 ;nonce="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" 410 ;response="bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" 411 Content-Type: application/sdp 413 NOTE: The Proxy-Authorization header sent in the first message 414 may have been cached from a previous exchange with the 415 SIP proxy. If the SIP client does not place a 416 Proxy-Authorization header in the INVITE, the RADIUS server will 417 (transitting through SIP proxy) challenge him with a 418 new nonce. 420 [2] SIP proxy server to RADIUS server: 422 Code = 1 (Access-Request) 423 ID = 0 424 Length = 71 425 Request Authenticator = {16 octet random number also used as 426 CHAP challenge 427 (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)} 429 Attributes: 430 User-Name = "byerly" 431 CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet 432 CHAP response 433 (bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb)} 434 NAS-IP-Address = 192.168.1.16 435 NAS-Port = 5 437 [3] RADIUS server to SIP proxy server: 439 Code = 11 (Access-Challenge} 440 ID = 0 (same as in Access-Request) 441 Length = 68 442 Attributes: 443 Reply-Message = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" 444 State = {Magic Cookie to be returned along with user's 445 response; in this example 8 octets of data} 447 [4] SIP proxy server to client: 449 SIP/2.0 407 Proxy Authentication required 450 From: sip:+19195551234@domain.com 451 To: sip:+19195551212@cisco.com 452 Call-ID: 12345600@cisco.com 453 CSeq: 1 INVITE 454 Proxy-Authenticate: CHAP-Password 455 ;username="byerly" 456 ;algorithm="MD5" 457 ;id=0 458 ;nonce="cccccccccccccccccccccccccccccccc" 459 State: {Magic Cookie from Access-Challenge packet, unchanged} 460 (formatted as hex digits) 462 NOTE: In this instance, the RADIUS server chooses to re-challenge 463 the SIP client with a new nonce. 465 [5] SIP Client to SIP proxy server: 467 INVITE sip:+19195551212@cisco.com SIP/2.0 468 From: sip:+19195551234@domain.com 469 To: sip:+19195551212@cisco.com 470 Call-ID: 12345600@cisco.com 471 CSeq: 2 INVITE 472 Content-Type: application/sdp 473 Proxy-Authorization: CHAP-Password 474 ;username="byerly" 475 ;algorithm="MD5" 476 ;id=0 477 ;nonce="cccccccccccccccccccccccccccccccc" 478 ;response="dddddddddddddddddddddddddddddddd" 479 State: {Magic Cookie from Access-Challenge packet, unchanged} 480 (formatted as hex digits) 482 [6] SIP proxy server to RADIUS server: 484 Code = 1 (Access-Request) 485 ID = 1 (Note that this changes) 486 Length = 71 487 Request Authenticator = {NEW 16 octet CHAP challenge 488 ()} 489 Attributes: 490 User-Name = "byerly" 491 CHAP-Password = {1 octet CHAP ID followed by 16 octet 492 CHAP response 493 (dddddddddddddddddddddddddddddddd)} 494 NAS-IP-Address = 192.168.1.16 495 NAS-Port = 5 496 State = {Magic Cookie from Access-Challenge packet, 497 unchanged} 499 [7] RADIUS server to SIP proxy server: 501 Code = 2 (Access-Accept) 502 ID = 1 (same as in Access-Request) 503 Length = 30 505 [8] SIP proxy server to next hop UAS: 507 INVITE sip:+19195551212@cisco.com SIP/2.0 508 From: sip:+19195551234@domain.com 509 To: sip:+19195551212@cisco.com 510 Call-ID: 12345600@cisco.com 511 CSeq: 2 INVITE 512 Content-Type: application/sdp 514 9.2 User Authentication using backend RADIUS server - 515 Without Server Challenge. 517 [a] SIP Client to SIP proxy server: 519 INVITE sip:+19195551212@cisco.com SIP/2.0 520 From: sip:+19195551234@domain.com 521 To: sip:+19195551212@cisco.com 522 Call-ID: 12345601@cisco.com 523 CSeq: 3 INVITE 524 Proxy-Authorization: CHAP-Password 525 ;username="byerly" 526 ;algorithm="MD5" 527 ;id=0 528 ;nonce="eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" 529 ;response="ffffffffffffffffffffffffffffffff" 530 Content-Type: application/sdp 532 [b] SIP proxy server to RADIUS server: 534 Code = 1 (Access-Request) 535 ID = 0 536 Length = 71 537 Request Authenticator = {16 octet random number also used as 538 CHAP challenge 539 (eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)} 540 Attributes: 541 User-Name = "byerly" 542 CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet 543 CHAP response 544 (ffffffffffffffffffffffffffffffff)} 545 NAS-IP-Address = 192.168.1.16 546 NAS-Port = 5 548 [c] RADIUS server to SIP proxy server: 550 Code = 2 (Access-Accept) 551 ID = 1 (same as in Access-Request) 552 Length = 56 554 [d] SIP proxy server to next hop UAS: 556 INVITE sip:+19195551212@cisco.com SIP/2.0 557 From: sip:+19195551234@domain.com 558 To: sip:+19195551212@cisco.com 559 Call-ID: 12345601@cisco.com 560 CSeq: 3 INVITE 561 Content-Type: application/sdp 563 There are two cases when a SIP client could pre-send a 564 Proxy-Authorization that the RADIUS server might accept: 565 1) The RADIUS server originally generated the nonce 566 when challenging the SIP client on a previous call. 567 The SIP client is reusing the previously sucessful 568 Authorization for a new call. 569 2) The SIP client originally generated the nonce. 570 The parsed format of the nonce is known to both the SIP 571 client and the RADIUS server. The nonce contains a timestamp 572 which the RADIUS server can extract and use to limit the 573 replay window. Since a RADIUS server silently discards 574 invalid/unauthorized requests, this scheme is not subject 575 to the form of the man-in-the-middle attack where Mallory 576 sends a bogus request to the server and uses the response 577 to make the client believe she is a legitimate server. 579 To dos: 580 1) Fix the RADIUS Lengths to be correct 581 2) Calculate real MD5 hashes 582 Outstanding issues: 583 1) Do we/how do we support the RADIUS State: attribute? 584 What are the implications for collision with (DCS-)State: 585 object? 586 2) Do we reuse the RADIUS NAS-Port and NAS-Port-Type attributes to 587 allow the RADIUS server to have media port control over calls? 588 (eg. using UDP port numbers for RTP streams) 590 10 Acknowledgements 592 We would like to thank Roger Levesque, David Oran, Mike Thomas, 593 David Daiker, Shail Bhatnagar, and Denise Caballero-McCann for 594 discussions on the need for and improvements to this draft. 595 We would also like to thank Tyrone Floryanzia for his insights on 596 H.323 gateway/gatekeeper call authorization using RADIUS. 598 11 References 600 [SIP] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: 601 Session Initiation Protocol", RFC 2543, March 1999. 603 [RAD] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote 604 Authentication Dial in User Service (RADIUS)," RFC 2138, 605 April 1997. 607 [DIG] Franks, J, et al. "HTTP Authentication: Basic and Digest Access 608 Authentication," RFC 2617, June 1999. 610 [CHAP] Simpson, W. "PPP Challenge Handshake Authentication Protocol 611 (CHAP)", RFC 1994, August 1996. 613 [PAP] Lloyd, B, W. Simpson. "PPP Authentication Protocols", 614 RFC 1334, October 1992. 616 [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 617 51, RFC 1661, DayDreamer, July 1994. 619 [MD5] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 620 MIT Laboratory for Computer Science and RSA Data Security, 621 Inc., RFC 1321, April 1992. 623 [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement 624 Levels," RFC-2119, March 1997. 626 Authors' Addresses 628 Bryan J. Byerly 629 Cisco Systems 630 7025 Kit Creek Road 631 P.O. Box 14987 632 Research Triangle Park, NC 27709 633 USA 634 Email: byerly@cisco.com 636 David Williams 637 Cisco Systems 638 7025 Kit Creek Road 639 P.O. Box 14987 640 Research Triangle Park, NC 27709 641 USA 642 Email: dwilli@cisco.com