doc/rfc/draft-sterman-aaa-sip-00.txt

   1 Internet Engineering Task Force                        B. Sterman
   2 AAA Working Group                                   D. Sadolevsky
   3 Internet Draft                                        D. Schwartz
   4 draft-sterman-aaa-sip-00.txt                     deltathree, Inc.
   5 Nov 12, 2001                                          D. Williams
   6 Expires: Apr 12 2002                                Cisco Systems
   7
   8
   9            RADIUS Extension for Digest Authentication
  10
  11 STATUS OF THIS MEMO
  12
  13    This  document is an Internet-Draft and is in full conformance
  14    with all provisions of Section 10 of RFC2026.
  15
  16    Internet-Drafts are working documents of  the  Internet  Engií
  17    neering  Task Force (IETF), its areas, and its working groups.
  18    Note that other groups may also distribute  working  documents
  19    as Internet-Drafts.
  20
  21    Internet-Drafts are draft documents valid for a maximum of six
  22    months and may be updated, replaced,  or  obsoleted  by  other
  23    documents  at  any time.  It is inappropriate to use Internet-
  24    Drafts as reference material or to cite  them  other  than  as
  25    "work in progress".
  26
  27    The  list  of  current  Internet-Drafts  can  be  accessed  at
  28    http://www.ietf.org/ietf/1id-abstracts.txt
  29
  30    To  view  the  list  Internet-Draft  Shadow  Directories,  see
  31    http://www.ietf.org/shadow.html.
  32
  33 Abstract
  34
  35    Basic  and  Digest  authentication  schemes  (RFC2617 [1]) are
  36    widely used in protocols such as SIP (RFC2543  [2])  and  HTTP
  37    (RFC2616 [3]). RADIUS (RFC2865 [4]) is a protocol for back end
  38    authentication. RADIUS supports Basic authentication natively,
  39    as well as several other authentication schemes, such as CHAP,
  40    but does not support Digest authentication scheme. This  docuí
  41    ment  describes  an extension to RADIUS for Digest authenticaí
  42    tion and provides a scenario of Digest user authentication.
  43
  44
  45
  46 1 Introduction
  47
  48 1.1 Terminology
  49
  50    In this document, the  key  words  "MUST",  "MUST  NOT",  "REí
  51    QUIRED",  "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMí
  52    MENDED", "MAY", and "OPTIONAL" are to be  interpreted  as  deí
  53    scribed in RFC 2119.
  54
  55 1.2 Scenario
  56
  57    Figure  1 depicts the scenario that is relevant for this docuí
  58    ment. It shows a generic case where entities A and B  communií
  59    cate  in the front-end using protocols such as HTTP/SIP, while
  60    entities B and C communicate in the back-end using RADIUS.
  61
  62
  63           HTTP/SIP           RADIUS
  64
  65     +-----+    (1)    +-----+           +-----+
  66     |     |==========>|     |           |     |
  67     |     |    (2)    |     |           |     |
  68     |     |<==========|     |           |     |
  69     |     |    (3)    |     |           |     |
  70     |     |==========>|     |           |     |
  71     |  A  |           |  B  |    (4)    |  C  |
  72     |     |           |     |---------->|     |
  73     |     |           |     |    (5)    |     |
  74     |     |           |     |<----------|     |
  75     |     |    (6)    |     |           |     |
  76     |     |<==========|     |           |     |
  77     +-----+           +-----+           +-----+
  78
  79     ====> HTTP/SIP
  80     ----> RADIUS
  81
  82     Figure 1: Scenario relevant to document
  83
  84
  85    The roles played by the entities in this scenario are as  folí
  86    lows:
  87
  88    A: HTTP client / SIP UA
  89
  90    B:  {HTTP  server / HTTP proxy server / SIP proxy server / SIP
  91    UAS} acting also as a RADIUS NAS
  92
  93    C: RADIUS server
  94
  95    The relevant order of messages sent in  this  scenario  is  as
  96    follows:
  97
  98    A  sends  B  an  HTTP/SIP request without authorization header
  99    (step 1). B challenges A sending an HTTP/SIP  "(Proxy)  Authoí
 100    rization  required"  response  containing  a locally generated
 101    nonce (step 2). A sends B an HTTP/SIP request with  authorizaí
 102    tion  header  (step 3). B sends C a RADIUS Access-Request with
 103    attributes described in this document (step 4). C responds  to
 104    B with a RADIUS Access-Accept/Access-Reject response (step 5).
 105    If credentials were accepted B receives an  Access-Accept  reí
 106    sponse and the message sent from A is considered authentic. If
 107    B receives an Access-Reject response, however, B then responds
 108    to  A  with  a "(Proxy) Authorization required" response (step
 109    6).
 110
 111
 112 1.3 Motivation
 113
 114    Basic and Digest authentication are used within protocols such
 115    as HTTP and SIP. Recently, there have been efforts towards the
 116    use of an Extensible Authentication Protocol (EAP) within proí
 117    tocols  such  as HTTP and SIP. [5] is one such effort. The adí
 118    vantage here is that, new authentication schemes may  be  used
 119    without any modification to the SIP/HTTP protocol itself. This
 120    is because the EAP packet for  the  particular  authentication
 121    scheme is carried transparently by the SIP/HTTP protocol.
 122
 123    However,  the use of Basic and Digest authentication is likely
 124    to continue to be  used  directly  within  protocols  such  as
 125    SIP/HTTP  in the near future, and hence their interoperability
 126    with a back-end authentication  protocol  such  as  RADIUS  is
 127    needed.
 128
 129    There  is  also an ongoing effort to accomplish the same thing
 130    as this document does in relation to DIAMETER [6], but  DIAMEí
 131    TER  itself  has  not reached the RFC status as of the time of
 132    writing this. When it happens and when  [6]  reaches  the  RFC
 133    status too, implementers are encouraged to switch to [6].
 134
 135 1.4 Approach
 136
 137    The  approach taken here is to extend RADIUS to support Digest
 138    authentication by mimicking its native support  for  CHAP  auí
 139    thentication. According to [4], the RADIUS server distinguishí
 140    es between different authentication schemes by looking at  the
 141    presence  of  an  attribute  specific for that scheme. For the
 142    three natively supported  authentication  schemes,  these  atí
 143    tributes  are:  User-Password for PAP (or any other clear-text
 144    password scheme), CHAP-Password for CHAP, and  State  +  User-
 145    Password for challenge-response scheme. This document adds aní
 146    other attribute to be used in this role: Digest-Response.  Alí
 147    so  according  to  [4], "An Access-Request packet MUST contain
 148    either a User-Password or a CHAP-Password or a State.  It MUST
 149    NOT  contain both a User-Password and a CHAP-Password.  If fuí
 150    ture extensions allow other kinds of  authentication  informaí
 151    tion  to  be  conveyed, the attribute for that can be used iní
 152    stead of User-Password or CHAP-Password."  The Digest-Response
 153    introduced here therefore can be used instead of User-Password
 154    or CHAP-Password.
 155
 156    The HTTP Authentication parameters found in  the  Proxy-Authoí
 157    rization  or  Authorization request header are mapped into two
 158    newly defined experimental RADIUS attributes.  The  Digest-Reí
 159    sponse  attribute and the Digest-Attributes attribute carrying
 160    multiple HTTP Digest parameters as subattributes. These 2  new
 161    RADIUS  attributes  are  defined in the document together with
 162    some other information required for  calculating  the  correct
 163    digest  response  on  the  RADIUS server with exception of the
 164    password, which the RADIUS server is assumed to be able to reí
 165    trieve  from a data store given the username. The structure of
 166    Digest-Response, the structure of  Digest-Attributes  and  the
 167    mapping/meaning of its subattributes are described in the next
 168    chapter.
 169
 170
 171
 172 2  New RADIUS attributes
 173
 174 2.1 Digest-Response attribute
 175
 176       Description
 177
 178       This attribute contains the request-digest  response  value
 179       contained  in  a  Digest (Proxy)Authorization header. It is
 180       only used in Access-Request packets. If this  attribute  is
 181       present,  the  RADIUS server SHOULD view the Access-Request
 182       as a Digest one.
 183
 184    A summary of the Digest-Attributes attribute format  is  shown
 185    below. The fields are transmitted from left to right.
 186
 187     0                   1                   2
 188     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
 189    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 190    |     Type      |  Length       | String...
 191    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 192
 193    Type
 194
 195       206(Experimental) for Digest-Response.
 196
 197    Length
 198
 199       34
 200
 201    String
 202       String  which proves the user knows a password.  The String
 203       field is 32 octets long and contains hexadecimal  represení
 204       tation of 16 octet digest value as it was calculated by the
 205       authenticated client. The String  field  SHOULD  be  copied
 206       from request-digest of digest-response ([1]).
 207
 208
 209 2.2 Digest-Attributes attribute
 210
 211    Description
 212
 213       This  attribute  contains  subattributes which indicate the
 214       values contained in a  Digest  (Proxy)Authorization  header
 215       together  with other information necessary to calculate the
 216       correct digest response value. It is only used  in  Access-
 217       Request  packets.   There can be multiple Digest-Attributes
 218       attributes contained in one Access-Request packet. In  this
 219       case  RADIUS server MUST interpret a concatenation of their
 220       values as if it came in one attribute.
 221
 222    A summary of the Digest-Attributes attribute format  is  shown
 223    below. The fields are transmitted from left to right.
 224
 225     0                   1                   2
 226     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 227    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 228    |     Type      |  Length       | String...
 229    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 230
 231    Type
 232
 233       207(Experimental) for Digest-Attributes.
 234
 235    Length
 236
 237       >= 5
 238
 239    String
 240
 241       The  String  field  is 3 or more octets and contains one or
 242       more subattributes. Format of a subattribute is  shown  beí
 243       low. The fields are transmitted from left to right.
 244
 245        0                   1                   2
 246        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
 247       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 248       |     Sub-Type  |  Sub-Length   | Sub-Value...
 249       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 250
 251       Sub-Type
 252
 253          Subattribute  type.  Meanings  of  the following defined
 254          types can be found in section 2.3
 255
 256          1      Realm
 257          2      Nonce
 258          3      Method
 259          4      URI
 260          5      QOP
 261          6      Algorithm
 262          7      Body-Digest
 263          8      CNonce
 264          9      Nonce-Count
 265          10     User-Name
 266
 267       Sub-Length
 268
 269          >= 3
 270
 271       Sub-Value
 272
 273          Subattribute-specific value
 274
 275 2.3.1 Realm
 276
 277    Sub-Type
 278
 279       1
 280
 281    Sub-Length
 282
 283       >= 3
 284
 285    Sub-Value
 286
 287       String, copied from realm-value of digest-response ([1])
 288
 289 2.3.2 Nonce
 290
 291    Sub-Type
 292
 293       2
 294
 295    Sub-Length
 296
 297       >= 3
 298
 299    Sub-Value
 300
 301       String, copied from nonce-value of digest-response ([1])
 302
 303 2.3.3 Method
 304
 305    Sub-Type
 306
 307       3
 308
 309    Sub-Length
 310
 311       >= 3
 312
 313    Sub-Value
 314
 315       String, copied from digest-response. Method is  taken  from
 316       request-URI of message ([2/3])
 317
 318 2.3.4 URI
 319
 320    Sub-Type
 321
 322       4
 323
 324    Sub-Length
 325
 326       >= 3
 327
 328    Sub-Value
 329
 330       String,  copied  from  digest-uri-value  of digest-response
 331       ([1])
 332
 333 2.3.5 QOP
 334
 335    Sub-Type
 336
 337       5
 338
 339    Sub-Length
 340
 341       >= 3
 342
 343    Sub-Value
 344
 345       String, copied from qop-value of digest-response ([1])
 346
 347 2.3.6 Algorithm
 348
 349    Sub-Type
 350
 351       6
 352
 353    Sub-Length
 354
 355       >= 3
 356
 357    Sub-Value
 358
 359       String, "MD5" | "MD5-sess" | token, copied  from  algorithm
 360       of digest-response ([1])
 361
 362
 363 2.3.7 Body-Digest
 364
 365    Sub-Type
 366
 367       7
 368
 369    Sub-Length
 370
 371       34
 372
 373    Sub-Value
 374
 375       String,  hexadecimal  representation of a digest calculated
 376       over entity-body of HTTP/SIP request ([1/2]).  Computed  by
 377       entity  B  in  figure 1.  This attribute is not part of the
 378       HTTP Digest response.
 379
 380 2.3.8 CNonce
 381
 382    Sub-Type
 383
 384       8
 385
 386    Sub-Length
 387
 388       >= 3
 389
 390    Sub-Value
 391
 392       String copied from cnonce-value of digest-response ([1])
 393
 394 2.3.9 Nonce-Count
 395
 396    Sub-Type
 397
 398       9
 399
 400    Sub-Length
 401
 402       = 10
 403
 404    Sub-Value
 405
 406       String, 8LHEX,  copied  from  nc-value  of  digest-response
 407       ([1])
 408
 409 2.3.10 User-Name
 410
 411    Sub-Type
 412
 413       10
 414
 415    Sub-Length
 416
 417       >= 3
 418
 419    Sub-Value
 420
 421       String  copied from username-value of digest-response ([1])
 422       the RADIUS server SHOULD NOT use this  value  for  password
 423       finding,  but only for digest calculation purpose. In order
 424       to find the user record  containing  password,  the  RADIUS
 425       server SHOULD use the value of the User-Name _attribute_
 426
 427
 428 3 Example
 429    This  is  an  example  sniffed from the traffic between HearMe
 430    softphone (A), Cisco Systems Proxy Server (B)  and  deltathree
 431    RADIUS  server  (C)  (The  communication between Cisco Systems
 432    Proxy Server and a SIP PSTN gateway is omitted for brevity):
 433
 434 A->B
 435
 436    INVITE sip:97226491335@213.137.69.38 SIP/2.0
 437    Via: SIP/2.0/UDP 213.137.67.67:5061
 438    From: <sip:12345678@213.137.67.67>;tag=216ae97f
 439    To: sip:97226491335@213.137.69.38
 440    Contact: sip:12345678@213.137.67.67:5061
 441    Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
 442    CSeq: 2544265 INVITE
 443    Content-Length: 150
 444    Content-Type: application/sdp
 445    User-Agent: HearMe SoftPHONE
 446
 447    v=0
 448    o=HearMe 2544265 2544265 IN IP4 213.137.67.67
 449    s=HearMe
 450    c=IN IP4 213.137.67.67
 451    t=0 0
 452    m=audio 8000 RTP/AVP 0 4
 453    a=ptime:20
 454    a=x-ssrc:009aa330
 455
 456 B->A
 457
 458    SIP/2.0 100 Trying
 459    Via: SIP/2.0/UDP 213.137.67.67:5061
 460    Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
 461    From: <sip:12345678@213.137.67.67>;tag=216ae97f
 462    To: sip:97226491335@213.137.69.38
 463    CSeq: 2544265 INVITE
 464    Content-Length: 0
 465
 466 B->A
 467
 468    SIP/2.0 407 Proxy Authentication Required
 469    Via: SIP/2.0/UDP 213.137.67.67:5061
 470    Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
 471    From: <sip:12345678@213.137.67.67>;tag=216ae97f
 472    To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
 473    CSeq: 2544265 INVITE
 474    Proxy-Authenticate: DIGEST realm="deltathree", nonce="3bada1a0", algorithm="md5"
 475    Content-Length: 0
 476
 477 A->B
 478
 479    ACK sip:97226491335@213.137.69.38 SIP/2.0
 480    Via: SIP/2.0/UDP 213.137.67.67:5061
 481    From: <sip:12345678@213.137.67.67>;tag=216ae97f
 482    To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
 483    Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
 484    CSeq: 2544265 ACK
 485    Content-Length: 0
 486
 487 A->B
 488
 489    INVITE sip:97226491335@213.137.69.38 SIP/2.0
 490    Via: SIP/2.0/UDP 213.137.67.67:5061
 491    From: <sip:12345678@213.137.67.67>;tag=29e97f
 492    To: sip:97226491335@213.137.69.38
 493    Contact: sip:12345678@213.137.67.67:5061
 494    Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
 495    CSeq: 2544266 INVITE
 496    Content-Length: 150
 497    Content-Type: application/sdp
 498    User-Agent: HearMe SoftPHONE
 499    Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0",opaque=""
 500         ,realm="deltathree",response="2ae133421cda65d67dc50d13ba0eb9bc"
 501         ,uri="sip:97226491335@213.137.69.38",username="12345678"
 502
 503    v=0
 504    o=HearMe 2544265 2544265 IN IP4 213.137.67.67
 505    s=HearMe
 506    c=IN IP4 213.137.67.67
 507    t=0 0
 508    m=audio 8000 RTP/AVP 0 4
 509    a=ptime:20
 510    a=x-ssrc:009aa330
 511
 512 B->A
 513
 514    SIP/2.0 100 Trying
 515    Via: SIP/2.0/UDP 213.137.67.67:5061
 516    Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
 517    From: <sip:12345678@213.137.67.67>;tag=29e97f
 518    To: sip:97226491335@213.137.69.38
 519    CSeq: 2544266 INVITE
 520    Content-Length: 0
 521
 522 B->C
 523
 524    Code = 1 (Access-Request)
 525    Identifier = 1
 526    Length = 164
 527    Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e
 528    Attributes:
 529    NAS-IP-Address = d5 89 45 26 (213.137.69.38)
 530    NAS-Port-Type = 5 (Virtual)
 531    User-Name = "12345678"
 532    Digest-Response (206) = "2ae133421cda65d67dc50d13ba0eb9bc"
 533    Digest-Attributes (207) = [Realm (1) = "deltathree"]
 534    Digest-Attributes (207) = [Nonce (2) = "3bada1a0"]
 535    Digest-Attributes (207) = [Method (3) = "INVITE"]
 536    Digest-Attributes (207) = [URI (4) = "sip:97226491335@213.137.69.38"]
 537    Digest-Attributes (207) = [Algorithm (5) = "md5"]
 538    Digest-Attributes (207) = [User-Name (10) = "12345678"]
 539
 540 C->B
 541
 542    Code = 2 (Access-Accept)
 543    Identifier = 1
 544    Length = 20
 545    Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d
 546
 547 B->A
 548
 549    SIP/2.0 180 Ringing
 550    Via: SIP/2.0/UDP 213.137.67.67:5061
 551    From: <sip:12345678@213.137.67.67>;tag=29e97f
 552    To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
 553    Date: Tue, 25 Jan 2000 03:41:00 gmt
 554    Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
 555    Server: Cisco-SIPGateway/IOS-12.x
 556    Record-Route: <sip:97226491335@213.137.69.38:5060;maddr=213.137.69.38>
 557    CSeq: 2544266 INVITE
 558    Content-Length: 0
 559
 560 B->A
 561
 562    SIP/2.0 200 OK
 563    Via: SIP/2.0/UDP 213.137.67.67:5061
 564    From: <sip:12345678@213.137.67.67>;tag=29e97f
 565    To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
 566    Date: Tue, 25 Jan 2000 03:41:00 gmt
 567    Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
 568    Server: Cisco-SIPGateway/IOS-12.x
 569    Record-Route: <sip:97226491335@213.137.69.38:5060;maddr=213.137.69.38>
 570    CSeq: 2544266 INVITE
 571    Contact: <sip:97226491335@213.137.69.36:5060;user=phone>
 572    Content-Type: application/sdp
 573    Content-Length: 158
 574
 575    v=0
 576    o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36
 577    s=SIP Call
 578    c=IN IP4 213.137.69.36
 579    t=0 0
 580    m=audio 17724 RTP/AVP 0
 581    a=rtpmap:0 PCMU/8000
 582
 583 A->B
 584
 585    ACK sip:97226491335@213.137.69.38:5060 SIP/2.0
 586    Via: SIP/2.0/UDP 213.137.67.67:5061
 587    From: <sip:12345678@213.137.67.67>;tag=29e97f
 588    To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
 589    Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
 590    CSeq: 2544266 ACK
 591    Content-Length: 0
 592    Route: <sip:97226491335@213.137.69.36:5060;user=phone>
 593
 594
 595 References
 596
 597    [1]  J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,
 598         P. Leach, A. Luotonen, L. Stewart, "HTTP Authentication:
 599         Basic and Digest Access Authentication", RFC 2617, June
 600         1999.
 601
 602    [2]  M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
 603         "SIP: Session Initiation Protocol",
 604         draft-ietf-sip-rfc2543bis-03.txt, IETF work in progress,
 605         May 2001.
 606
 607    [3]  R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
 608         L. Masinter, P. Leach, T. Berners-Lee, "Hypertext
 609         Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 610
 611    [4]  C. Rigney, S. Willens, Livingston, A. Rubens, Merit,
 612         W. Simpson, Daydreamer, "Remote Authentication Dial In
 613         User Service (RADIUS)", RFC 2865, June 2000
 614
 615    [5]  J. Arkko, V. Torvinen, A. Niemi, "HTTP Authentication
 616         with EAP", draft-http-eap-basic-04.txt, IETF work in
 617         progress, June 2001.
 618
 619    [6]  Srinivas, Chan, Sengodan, Costa-Requena, "Mapping of
 620         Basic and Digest Authentication to DIAMETER AAA
 621         Messages", draft-srinivas-aaa-basic-digest-00.txt,
 622         IETF work in progress, July 2001
 623
 624
 625 Acknowledgements
 626
 627    We would like to acknowledge Kevin Mcdermott  (Cisco  Systems)
 628    for providing comments and experimental implementation.
 629
 630 Authors's Addresses
 631
 632    Baruch Sterman
 633    Daniel Sadolevsky
 634    David  Schwartz
 635
 636    deltathree, Inc.
 637    Jerusalem Technology Park
 638    P.O. Box 48265
 639    Jerusalem 91481 Israel
 640    {baruch,daniels,davids}@deltathree.com
 641
 642    David Williams
 643    Cisco Systems
 644    7025 Kit Creek Road
 645    P.O. Box 14987
 646    Research Triangle Park, NC 27709
 647    USA
 648    Email: dwilli@cisco.com