idnits 2.17.1 draft-sterman-aaa-sip-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 18 instances of lines with control characters in the document. == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 45 has weird spacing: '... Basic and D...' == Line 49 has weird spacing: '...e. This docum...' == Line 144 has weird spacing: '...unicate in th...' == Line 169 has weird spacing: '... are as follo...' == Line 178 has weird spacing: '...sent in this ...' == (10 more instances...) -- 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 (February 6, 2004) is 7378 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) == Unused Reference: 'RFC1750' is defined on line 770, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sterman 3 Internet-Draft Kayote Networks 4 Expires: August 6, 2004 D. Sadolevsky 5 SecureOL, Inc. 6 D. Schwartz 7 Kayote Networks 8 D. Williams 9 Cisco Systems 10 W. Beck 11 Deutsche Telekom AG 12 February 6, 2004 14 RADIUS Extension for Digest Authentication 15 draft-sterman-aaa-sip-01.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 6, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 Basic and Digest authentication schemes are widely used in 46 protocols such as SIP and HTTP . RADIUS is a protocol for back end 47 authentication. RADIUS supports Basic authentication natively, as 48 well as several other authentication schemes, such as CHAP, but does 49 not support Digest authentication scheme. This document describes 50 an extension to RADIUS for Digest authentication and provides a 51 scenario of Digest user authentication. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . 7 61 2.1 Digest-Response attribute . . . . . . . . . . . . . . . . . 7 62 2.2 Digest-Attributes attribute . . . . . . . . . . . . . . . . 8 63 2.3 Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.4 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 2.5 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.6 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.7 QOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 2.8 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.9 Body-Digest . . . . . . . . . . . . . . . . . . . . . . . . 11 70 2.10 CNonce . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 2.11 Nonce-Count . . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.12 User-Name . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 3. Detailed Description . . . . . . . . . . . . . . . . . . . . 14 74 3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . . 14 75 3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . . 14 76 4. Security Considerations . . . . . . . . . . . . . . . . . . 16 77 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Normative References . . . . . . . . . . . . . . . . . . . . 21 79 Informative References . . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 81 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 82 Intellectual Property and Copyright Statements . . . . . . . 26 84 1. Introduction 86 1.1 Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 1.2 Motivation 94 Digest authentication is a simple authentication mechanism for HTTP 95 and SIP. While it was not too successful in HTTP environments, it is 96 the only SIP authentication mechanism that has been widely adopted. 97 Due to the weaknesses of Digest authentication (see Section 4), 98 PKI-based authentication and encryption mechanisms have been 99 introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However, 100 most SIP user agents that support TLS don't send client certificates. 101 SIP with S/MIME is lacking support, too: even two years after the 102 inclusion of S/MIME into SIP, almost no implementations exist. 104 SIP service providers whishing to authenticate their clients have the 105 following options: they can 107 o build a PKI and wait for interopable S/MIME capable SIP 108 implementations, 110 o build a PKI and wait for SIP implementations supporting TLS with 111 client-side certificates, 113 o replace their existing RADIUS infrastructure with DIAMETER 114 [RFC3588], when DIAMETER supports HTTP Digest authentication, 116 o use TLS for server authentication and plaintext passwords (Basic) 117 for client authentication, which can be done with standard RADIUS, 119 o upgrade their existing RADIUS servers with the functionality 120 described in this document 122 PKI solutions only cover authentication, not authorization (EAP could 123 change this, but its use with SIP is not standardized). TLS / Basic 124 authentication works only with the limited number of SIP devices that 125 implement TLS. Basic authentication has been deprecated for SIP in 126 [RFC3261]. 128 Current RADIUS-based AAA infrastructures have been built and debugged 129 over years. Deficiencies of RADIUS have been mitigated with 130 proprietary (ie costly) extensions. Operators are therefore reluctant 131 to replace their RADIUS infrastructure in order to enable a single 132 new authentication mechanism. 134 Given the complexity of S/MIME, simple clients will continue to 135 support HTTP digest authentication only. Its interopability with a 136 back-end authentication protocol such as RADIUS is needed. 138 Operators that are about to replace their RADIUS-based AAA 139 infrastructure are strongly recommended to use DIAMETER. 141 1.3 Scenario 143 Figure 1 depicts the scenario that is relevant for this document. It 144 shows a generic case where entities A and B communicate in the 145 front-end using protocols such as HTTP/SIP, while entities B and C 146 communicate in the back-end using RADIUS. 148 HTTP/SIP RADIUS 150 +-----+ (1) +-----+ +-----+ 151 | |==========>| | | | 152 | | (2) | | | | 153 | |<==========| | | | 154 | | (3) | | | | 155 | |==========>| | | | 156 | A | | B | (4) | C | 157 | | | |---------->| | 158 | | | | (5) | | 159 | | | |<----------| | 160 | | (6) | | | | 161 | |<==========| | | | 162 +-----+ +-----+ +-----+ 164 ====> HTTP/SIP 165 ----> RADIUS 167 Figure 1: Overview of operation 169 The roles played by the entities in this scenario are as follows: 171 A: HTTP client / SIP UA 173 B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} 174 acting also as a RADIUS NAS 176 C: RADIUS server 178 The relevant order of messages sent in this scenario is as 179 follows: 181 A sends B an HTTP/SIP request without authorization header (step 1). 182 B challenges A sending an HTTP/SIP "(Proxy) Authorization required" 183 response containing a locally generated nonce (step 2). A sends B 184 an HTTP/SIP request with authorization header (step 3). B sends C a 185 RADIUS Access-Request with attributes described in this document 186 (step 4). C responds to B with a RADIUS Access-Accept/Access-Reject 187 response (step 5). If credentials were accepted B receives an 188 Access-Accept response and the message sent from A is considered 189 authentic. If B receives an Access-Reject response, however, B then 190 responds to A with a "(Proxy) Authorization required" response (step 191 6). 193 1.4 Approach 195 The approach taken here is to extend RADIUS to support Digest 196 authentication by mimicking its native support for CHAP 197 authentication. According to [RFC2865], the RADIUS server 198 distinguishes between different authentication schemes by looking at 199 the presence of an attribute specific for that scheme. For the three 200 natively supported authentication schemes, these attributes are: 201 User-Password for PAP (or any other clear-text password scheme), 202 CHAP-Password for CHAP, and State + User- Password for 203 challenge-response scheme. This document adds another attribute to be 204 used in this role: Digest-Response. Also according to [RFC2865], "An 205 Access-Request packet MUST contain either a User-Password or a 206 CHAP-Password or a State. It MUST NOT contain both a User-Password 207 and a CHAP-Password. If future extensions allow other kinds of 208 authentication information to be conveyed, the attribute for that can 209 be used instead of User-Password or CHAP-Password." The 210 Digest-Response introduced here therefore can be used instead of 211 User-Password or CHAP-Password. 213 The HTTP Authentication parameters found in the Proxy-Authorization 214 or Authorization request header are mapped into two newly defined 215 RADIUS attributes. The Digest-Response attribute and the 216 Digest-Attributes attribute carrying multiple HTTP Digest parameters 217 as subattributes. These two new RADIUS attributes are defined in the 218 document together with some other information required for 219 calculating the correct digest response on the RADIUS server with 220 exception of the password, which the RADIUS server is assumed to be 221 able to retrieve from a data store given the username. The structure 222 of Digest-Response, the structure of Digest-Attributes and the 223 mapping/meaning of its subattributes are described in the next 224 chapter. 226 2. New RADIUS attributes 228 DIG-RES and DIG-ATTRS are placeholders for values that will be 229 assigned by IANA, if this specification becomes a working group 230 document. 232 2.1 Digest-Response attribute 234 If this attribute is present, the RADIUS server SHOULD view the 235 Access-Request as a Digest one. The following paragraphs apply for 236 RADIUS servers implementing this specification. 238 Access-Request packets MUST contain an Digest-Response attribute. In 239 Access-Request packets, this attribute contains the digest taken from 240 request-digest field in Digest (Proxy)Authorization header, as 241 received from the HTTP or SIP client. 243 Access-Accept packets MUST contain a Digest-Response attribute. In 244 Access-Accept packets, this attribute contains a digest that can be 245 used for generating Authentication-Info headers. The calculation of 246 this digest is described [RFC2617], section 3.2.3. A summary of the 247 Digest-Response attribute format is shown below. The fields are 248 transmitted from left to right. 250 0 1 2 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Length | String... 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Type 258 DIG-RES for Digest-Response. Early implementations have used 259 the experimental type 206. 261 Length 263 34 265 String 266 In Access-Requests, this string proves the user knows a 267 password. The String field is 32 octets long and contains 268 hexadecimal representation of 16 octet digest value as it was 269 calculated by the authenticated client. The String field 270 SHOULD be copied from request-digest of digest-response 271 ([RFC2617]). In Access-Accepts, this string proves the RADIUS 272 server knows the password. The RADIUS server calculates a 273 digest according to section 3.2.3 of [RFC2617] and copies the 274 result into this string. 276 2.2 Digest-Attributes attribute 278 This attribute contains subattributes which indicate the values 279 contained in a Digest (Proxy)Authorization header and other 280 information necessary to calculate the correct digest response. It 281 is only used in Access- Request packets. There can be multiple 282 Digest-Attributes attributes contained in one Access-Request packet. 283 In this case RADIUS server MUST interpret a concatenation of their 284 values as if it came in one attribute. 286 A summary of the Digest-Attributes attribute format is shown below. 287 The fields are transmitted from left to right. 289 0 1 2 290 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | String... 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Type 297 DIG-ATTRS for Digest-Attributes. Early implementations have 298 used the experimental type 207. 300 Length 302 >= 5 304 String 305 The String field is 3 or more octets and contains one or more 306 subattributes. Format of a subattribute is shown below. The 307 fields are transmitted from left to right. 309 0 1 2 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 312 | Sub-Type | Sub-Length | Sub-Value... 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 315 Sub-Type 317 Subattribute type. Meanings of the following defined types 318 can be found in section Section 2.3 320 1 Realm 321 2 Nonce 322 3 Method 323 4 URI 324 5 QOP 325 6 Algorithm 326 7 Body-Digest 327 8 CNonce 328 9 Nonce-Count 329 10 User-Name 331 Sub-Length >= 3 333 Sub-Value Subattribute-specific value 335 2.3 Realm 336 Sub-Type 338 1 340 Sub-Length 342 >= 3 344 Sub-Value 346 String, copied from realm-value of digest-response ([RFC2617]) 348 2.4 Nonce 350 Sub-Type 352 2 354 Sub-Length 356 >= 3 358 Sub-Value 360 String, copied from realm-value of digest-response ([RFC2617]) 362 2.5 Method 364 Sub-Type 366 3 368 Sub-Length 370 >= 3 372 Sub-Value 374 String, copied from digest-response. Method is taken from HTTP 375 or SIP request ([RFC2616], [RFC3261]) 377 2.6 URI 378 Sub-Type 380 4 382 Sub-Length 384 >= 3 386 Sub-Value 388 String, copied from digest-uri-value of digest-response 389 ([RFC2617]) 391 2.7 QOP 393 Sub-Type 395 5 397 Sub-Length 399 >= 3 401 Sub-Value 403 String, copied from qop-value of digest-response ([RFC2617]) 405 2.8 Algorithm 407 Sub-Type 409 6 411 Sub-Length 413 >= 3 415 Sub-Value 417 String, "MD5" | "MD5-sess" | token, copied from of 418 digest-response ([RFC2617]) 420 2.9 Body-Digest 421 Sub-Type 423 7 425 Sub-Length 427 34 429 Sub-Value 431 String, hexadecimal representation of a digest calculated over 432 entity-body of HTTP/SIP request ([RFC2616], [RFC3261]). 433 Computed by entity B in figure Figure 1. This attribute is not 434 part of the HTTP Digest response. See [RFC2617] section 435 3.2.2.3. 437 2.10 CNonce 439 Sub-Type 441 8 443 Sub-Length 445 >= 3 447 Sub-Value 449 String copied from cnonce-value of digest-response ([RFC2617]) 451 2.11 Nonce-Count 453 Sub-Type 455 9 457 Sub-Length 459 10 461 Sub-Value 463 String, 8LHEX, copied from nc-value of digest-response 464 ([RFC2617]) 466 2.12 User-Name 468 Sub-Type 470 10 472 Sub-Length 474 >= 3 476 Sub-Value 478 String copied from username-value of digest-response 479 ([RFC2617]) the RADIUS server SHOULD NOT use this value for 480 password finding, but only for digest calculation purpose. In 481 order to find the user record containing password, the RADIUS 482 server SHOULD use the value of the User-Name _attribute_ 484 3. Detailed Description 486 The term 'HTTP-style' denotes any protocol that uses HTTP-like 487 headers and uses HTTP digest authentication as described in 488 [RFC2617]. Examples are HTTP and SIP. 490 3.1 RADIUS Client Behaviour 492 A RADIUS client without an encrypted or otherwise secured connection 493 to its RADIUS server only accepts unsecured connections from its 494 HTTP-style clients (or else the clients would have a false sense of 495 security). 497 The RADIUS client examines the (Proxy-)Authorization header of an 498 incoming HTTP-style request message. If this header is present and 499 contains HTTP digest information, the RADIUS client checks the 500 'nonce' parameter. If the 'nonce' parameter has not been issued by 501 the RADIUS client, it responds with a 401 (Unauthorized) or 407 502 (Proxy Authentication Required) to the HTTP-style client. In this 503 error response, the RADIUS client issues a new nonce. 505 If the RADIUS client recognizes the nonce, it takes the header 506 parameters and puts them into a RADIUS Access-Request message. It 507 puts the 'response' parameter into a Digest-Response attribute and 508 the realm / nonce / qop / algorithm / cnonce / nc / username into a 509 Digest-Attributes attribute. The request URI and the request method 510 are put into the Digest-Attributes attribute, too. Now, the RADIUS 511 client sends the Access-Request message to the RADIUS server. 513 The RADIUS server processes the message and responds with an 514 Access-Accept or an Access-Reject. If the RADIUS client receives an 515 Access-Accept, it examines the Digest-Response attribute contained in 516 the message. It constructs an Authentication-Info header and puts the 517 contents of Digest-Response into the 'rspauth' header parameter. Now 518 it can send a HTTP-style response. 520 If the RADIUS client did not receive a (Proxy-)Authorization header 521 from its HTTP-style client, it generates a new nonce and sends an 522 error response (401 or 407) containing a (Proxy-)Authenticate header. 524 If the RADIUS client receives an Access-Reject or no response from 525 the RADIUS server, it sends an error response to the HTTP-style 526 request it has received. 528 3.2 RADIUS Server Behaviour 530 If the RADIUS server receives an Access-Request message containing a 531 Digest-Response attribute, it looks for the Digest-Attributes 532 attribute. If it does not find this attribute, it responds with an 533 Access-Reject message. If the Digest-Attribute attribute is present, 534 the RADIUS server calculates the digest response as described in 535 [RFC2617]. To look up the password, the RADIUS server uses the RADIUS 536 User-Name attribute. All other values are taken from the 537 Digest-Attribute attribute. If the calculated digest response equals 538 the string received in the Digest-Response attribute, the 539 authentication was successful. If not, the RADIUS server responds 540 with an Access-Reject. 542 If the authentication was successful, the RADIUS server calculates a 543 Digest-Response attribute that can be used by the RADIUS client to 544 construct an Authentication-Info header. The calculation of this 545 response is described in [RFC2617], section 3.2.3. The 546 Digest-Response attribute is send to the RADIUS client in an 547 Access-Accept message. 549 4. Security Considerations 551 The RADIUS extensions described in this document make RADIUS a 552 transport protocol for the data that is required to perform a digest 553 calculation. It adds the vulnerabilities of HTTP Digest (see 554 [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or 555 here [1])). 557 If an attacker gets access to a RADIUS client, it can perform 558 man-in-the-middle attacks even if the connections between A, B and B, 559 C (Figure 1) have been secured with TLS or IPSec. 561 SIP or HTTP requests occur much more frequently than dial-in 562 requests. RADIUS servers implementing this specification must meet 563 that additional performance requirements. An attacker could try to 564 overload the RADIUS infrastructure by excessively sending SIP or HTTP 565 requests. This kind of attack was more difficult when RADIUS was just 566 used for dial-in authentication: the attacker could be identified by 567 the DSL / Cable interface or with some help of the PSTN provider. 569 To make simple denial of service attacks more difficult, RADIUS 570 clients MUST check if nonces received from a client have been issued 571 by them. This SHOULD be done statelessly. For example, a nonce could 572 consist of a cryptographically random part and some kind of signature 573 of the RADIUS client, as described in [RFC2617], section 3.2.1. 575 HTTP-style clients can use TLS with server side certificates together 576 with HTTP-Digest authentication. IPSec can be used in a similar way. 577 TLS or IPSec secure the connection while Digest Authentication 578 authenticates the user. If a RADIUS client accepts such connections, 579 it MUST have a secure connection to the RADIUS server. 581 5. Example 583 This is an example sniffed from the traffic between HearMe softphone 584 (A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C) 585 (The communication between Cisco Systems Proxy Server and a SIP PSTN 586 gateway is omitted for brevity): 588 A->B 590 INVITE sip:97226491335@213.137.69.38 SIP/2.0 591 Via: SIP/2.0/UDP 213.137.67.67:5061 592 From: ;tag=216ae97f 593 To: sip:97226491335@213.137.69.38 594 Contact: sip:12345678@213.137.67.67:5061 595 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 596 CSeq: 2544265 INVITE 597 Content-Length: 150 598 Content-Type: application/sdp 599 User-Agent: HearMe SoftPHONE 601 v=0 602 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 603 s=HearMe 604 c=IN IP4 213.137.67.67 605 t=0 0 606 m=audio 8000 RTP/AVP 0 4 607 a=ptime:20 608 a=x-ssrc:009aa330 610 B->A 612 SIP/2.0 100 Trying 613 Via: SIP/2.0/UDP 213.137.67.67:5061 614 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 615 From: ;tag=216ae97f 616 To: sip:97226491335@213.137.69.38 617 CSeq: 2544265 INVITE 618 Content-Length: 0 620 B->A 622 SIP/2.0 407 Proxy Authentication Required 623 Via: SIP/2.0/UDP 213.137.67.67:5061 624 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 625 From: ;tag=216ae97f 626 To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc 627 CSeq: 2544265 INVITE 628 Proxy-Authenticate: DIGEST realm="deltathree" 629 ,nonce="3bada1a0", algorithm="md5" 630 Content-Length: 0 632 A->B 634 ACK sip:97226491335@213.137.69.38 SIP/2.0 635 Via: SIP/2.0/UDP 213.137.67.67:5061 636 From: ;tag=216ae97f 637 To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc 638 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 639 CSeq: 2544265 ACK 640 Content-Length: 0 642 A->B 644 INVITE sip:97226491335@213.137.69.38 SIP/2.0 645 Via: SIP/2.0/UDP 213.137.67.67:5061 646 From: ;tag=29e97f 647 To: sip:97226491335@213.137.69.38 648 Contact: sip:12345678@213.137.67.67:5061 649 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 650 CSeq: 2544266 INVITE 651 Content-Length: 150 652 Content-Type: application/sdp 653 User-Agent: HearMe SoftPHONE 654 Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0" 655 ,opaque="",realm="deltathree" 656 ,response="2ae133421cda65d67dc50d13ba0eb9bc" 657 ,uri="sip:97226491335@213.137.69.38",username="12345678" 659 v=0 660 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 661 s=HearMe 662 c=IN IP4 213.137.67.67 663 t=0 0 664 m=audio 8000 RTP/AVP 0 4 665 a=ptime:20 666 a=x-ssrc:009aa330 668 B->C 669 Code = 1 (Access-Request) 670 Identifier = 1 671 Length = 164 672 Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e 673 Attributes: 674 NAS-IP-Address = d5 89 45 26 (213.137.69.38) 675 NAS-Port-Type = 5 (Virtual) 676 User-Name = "12345678" 677 Digest-Response (206) = "2ae133421cda65d67dc50d13ba0eb9bc" 678 Digest-Attributes (207) = [Realm (1) = "deltathree"] 679 Digest-Attributes (207) = [Nonce (2) = "3bada1a0"] 680 Digest-Attributes (207) = [Method (3) = "INVITE"] 681 Digest-Attributes (207) = 682 [URI (4) = "sip:97226491335@213.137.69.38"] 683 Digest-Attributes (207) = [Algorithm (5) = "md5"] 684 Digest-Attributes (207) = [User-Name (10) = "12345678"] 686 C->B 688 Code = 2 (Access-Accept) 689 Identifier = 1 690 Length = 20 691 Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d 692 Attributes: 693 Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954" 695 B->A 697 SIP/2.0 180 Ringing 698 Via: SIP/2.0/UDP 213.137.67.67:5061 699 From: ;tag=29e97f 700 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 701 Date: Tue, 25 Jan 2000 03:41:00 gmt 702 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 703 Server: Cisco-SIPGateway/IOS-12.x 704 Record-Route: 706 CSeq: 2544266 INVITE 707 Content-Length: 0 709 B->A 711 SIP/2.0 200 OK 712 Via: SIP/2.0/UDP 213.137.67.67:5061 713 From: ;tag=29e97f 714 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 715 Date: Tue, 25 Jan 2000 03:41:00 gmt 716 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 717 Authentication-Info: nextnonce="ef0189c5", 718 rspauth="6303c41b0e2c3e524e413cafe8cce954" 719 Server: Cisco-SIPGateway/IOS-12.x 720 Record-Route: 722 CSeq: 2544266 INVITE 723 Contact: 724 Content-Type: application/sdp 725 Content-Length: 158 727 v=0 728 o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36 729 s=SIP Call 730 c=IN IP4 213.137.69.36 731 t=0 0 732 m=audio 17724 RTP/AVP 0 733 a=rtpmap:0 PCMU/8000 735 A->B 737 ACK sip:97226491335@213.137.69.38:5060 SIP/2.0 738 Via: SIP/2.0/UDP 213.137.67.67:5061 739 From: ;tag=29e97f 740 To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E 741 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 742 CSeq: 2544266 ACK 743 Content-Length: 0 744 Route: 746 Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, March 1997. 751 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 752 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 753 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 755 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 756 Leach, P., Luotonen, A. and L. Stewart, "HTTP 757 Authentication: Basic and Digest Access Authentication", 758 RFC 2617, June 1999. 760 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 761 "Remote Authentication Dial In User Service (RADIUS)", RFC 762 2865, June 2000. 764 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 765 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 766 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 768 Informative References 770 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 771 Recommendations for Security", RFC 1750, December 1994. 773 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 774 RFC 2246, January 1999. 776 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 777 RFC 2633, June 1999. 779 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 780 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 782 URIs 784 [1] 786 Authors' Addresses 788 Baruch Sterman 789 Kayote Networks 790 P.O. Box 1373 791 Efrat 90435 792 Israel 794 EMail: baruch@kayote.com 796 Daniel Sadolevsky 797 SecureOL, Inc. 798 Jerusalem Technology Park 799 P.O. Box 16120 800 Jerusalem 91160 801 Israel 803 EMail: dscreat@dscreat.com 805 David Schwartz 806 Kayote Networks 807 P.O. Box 1373 808 Efrat 90435 809 Israel 811 EMail: david@kayote.com 813 David Williams 814 Cisco Systems 815 7025 Kit Creek Road 816 P.O. Box 14987 817 Research Triangle Park NC 27709 818 USA 820 EMail: dwilli@cisco.com 821 Wolfgang Beck 822 Deutsche Telekom AG 823 Am Kavalleriesand 3 824 Darmstadt 64295 825 Germany 827 EMail: beckw@t-systems.com 829 Appendix A. Acknowledgements 831 We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or 832 providing comments and experimental implementation. 834 Intellectual Property Statement 836 The IETF takes no position regarding the validity or scope of any 837 intellectual property or other rights that might be claimed to 838 pertain to the implementation or use of the technology described in 839 this document or the extent to which any license under such rights 840 might or might not be available; neither does it represent that it 841 has made any effort to identify any such rights. Information on the 842 IETF's procedures with respect to rights in standards-track and 843 standards-related documentation can be found in BCP-11. Copies of 844 claims of rights made available for publication and any assurances of 845 licenses to be made available, or the result of an attempt made to 846 obtain a general license or permission for the use of such 847 proprietary rights by implementors or users of this specification can 848 be obtained from the IETF Secretariat. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights which may cover technology that may be required to practice 853 this standard. Please address the information to the IETF Executive 854 Director. 856 Full Copyright Statement 858 Copyright (C) The Internet Society (2004). All Rights Reserved. 860 This document and translations of it may be copied and furnished to 861 others, and derivative works that comment on or otherwise explain it 862 or assist in its implementation may be prepared, copied, published 863 and distributed, in whole or in part, without restriction of any 864 kind, provided that the above copyright notice and this paragraph are 865 included on all such copies and derivative works. However, this 866 document itself may not be modified in any way, such as by removing 867 the copyright notice or references to the Internet Society or other 868 Internet organizations, except as needed for the purpose of 869 developing Internet standards in which case the procedures for 870 copyrights defined in the Internet Standards process must be 871 followed, or as required to translate it into languages other than 872 English. 874 The limited permissions granted above are perpetual and will not be 875 revoked by the Internet Society or its successors or assignees. 877 This document and the information contained herein is provided on an 878 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 879 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 880 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 881 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 882 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 884 Acknowledgment 886 Funding for the RFC Editor function is currently provided by the 887 Internet Society.