Internet Draft Mahler/Simunek/Biggs Expiration Date: September 2000 3Com April 2000 SIP CHAP Authentication Protocol draft-mahler-sip-chap-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses how to implement CHAP as an authentication method within SIP. One may wish to use CHAP as an authentication method to allow a SIP server to use a RADIUS server to perform authentication. Mahler/Simunek/Biggs Internet Draft [Page 1] Internet-Draft SIP CHAP Authentication Protocol April 2000 Table Of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The WWW-Authenticate and Proxy-Authenticate Response Headers 2 3. The Authorization and Proxy-Authorization Request Headers . 4 4. Response Generation . . . . . . . . . . . . . . . . . . . . 5 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 1. Introduction When authenticating users, it may be desirable to make use of available RADIUS servers for authentication. In order to use these servers, it is necessary to present a CHAP challenge to the user and for the user to return a CHAP response. This document discusses how this is accomplished. The authentication headers described in this draft draw heavily from Digest Authentication [5]. In fact many of the parameters in the headers are defined exactly as they are in Digest. 1.1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 2. The WWW-Authenticate and Proxy-Authenticate Response Headers If a server receives a request for an access-protected service, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code and a WWW-Authenticate header, or a "407 Proxy Authentication Required" and a Proxy-Authenticate header depending on the request submitted. These headers are defined as follows: Mahler/Simunek/Biggs Internet Draft [Page 2] Internet-Draft SIP CHAP Authentication Protocol April 2000 WWW-Authenticate = "WWW-Authenticate" ":" challenge Proxy-Authenticate = "Proxy-Authenticate" ":" challenge challenge = "Chap" chap-challenge chap-challenge = 1#( realm | [ domain ] | nonce | chap-id | [ opaque ] | [ stale ] | [ algorithm ] ) realm = "realm" "=" realm-value realm-value = quoted-string domain = "domain" "=" <"> 1#URI <"> nonce = "nonce" "=" nonce-value nonce-value = quoted-string chap-id = "chap-id" "=" chap-id-value chap-id-value = 1*3DIGIT ; 0 to 255 opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | token ) The meanings of the values of the parameters used above are as follows: realm: A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com". The realm is a "quoted-string" as specified in section 2.2 of the HTTP/1.1 specification [2]. domain: A comma-separated list of URIs, as specified for HTTP/1.0. The intent is that the client could use this information to know the set of URIs for which the same authentication information should be sent. The URIs in this list may exist on different servers. If this keyword is omitted or empty, the client should assume that the domain consists of all URIs on the responding server. nonce: A server-specified data string which may be uniquely generated each time a 401 or 407 response is made. It is recommended that this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string, the double-quote character is not allowed. Mahler/Simunek/Biggs Internet Draft [Page 3] Internet-Draft SIP CHAP Authentication Protocol April 2000 chap-id: This is the ASCII representation of the one-octet CHAP identifier. It can have a value of 0 to 255. This string must be converted to its one-octet value to be used in the response calculation. opaque: A string of data, specified by the server, which should be returned by the client unchanged. It is recommended that this string be base64 or hexadecimal data. This field is a "quoted-string" as specified in section 2.2 of the HTTP/1.1 specification [2]. stale: A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE (in upper or lower case), the client may wish to simply retry the request with a new encrypted response, without reprompting the user for a new username and password. The server should only set stale to true if it receives a request for which the nonce is invalid but with a valid response for that nonce (indicating that the client knows the correct username/password). algorithm: A string indicating the algorithm used to produce the response. At this time, CHAP only defines the use of MD5, so this is included as an option for future expansion. 3. The Authorization and Proxy-Authorization Request Headers Authorization = "Authorization" ":" credentials Proxy-Authorization = "Proxy-Authorization" ":" credentials credentials = "Chap" chap-response chap-response = 1#( username | realm | nonce | chap-uri | chap-id | response | [opaque] | [ algorithm ] ) username = "username" "=" username-value username-value = quoted-string chap-uri = "uri" "=" chap-uri-value chap-uri-value = request-URI chap-id = "chap-id" "=" chap-id-value chap-id-value = 1*3DIGIT ; 0 to 255 response = "response" "=" response-chap response-chap = <"> *LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" opaque = "opaque" "=" quoted-string algorithm = "algorithm" "=" ( "MD5" | token ) Mahler/Simunek/Biggs Internet Draft [Page 4] Internet-Draft SIP CHAP Authentication Protocol April 2000 username: This is the username of the user to be authenticated. It is a "quoted-string" as specified in section 2.2 of the HTTP/1.1 specification [3]. chap-id: This is the same chap-id that was in the challenge. response: This is the CHAP response. See the Response Generation section for a discussion of its calculation and representation. opaque: This is the original opaque string. algorithm: A string indicating a pair of algorithms used to produce the digest and a checksum. If this not present it is assumed to be "MD5". 4. Response Generation From 4.1 of RFC1994 [2]: The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value, followed by (concatenated with) the method, followed by (concatenated with) request URI. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). From 3.1.3 of RFC2617 [5]: For the purposes of this document, an MD5 digest of 128 bits is represented as 32 ASCII printable characters. The bits in the 128 bit digest are converted from most significant to least significant bit, four bits at a time to their ASCII presentation as follows. Each four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef. That is, binary 0000 gets represented by the character '0', 0001, by '1', and so on up to the representation of 1111 as 'f'. After a response (a new request with the authentication credentials) has been received from the client, the chap-ID, a challenge, and the response from the client may be presented to a RADIUS server for authentication. The challenge presented to the RADIUS server is the Challenge Value presented to the client followed by (concatenated with) the method, followed by (concatenated with) the chap-uri. Mahler/Simunek/Biggs Internet Draft [Page 5] Internet-Draft SIP CHAP Authentication Protocol April 2000 5. Examples For example, REGISTER F1 B->SIP server REGISTER sip:there.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: TheLittleGuy To: TheLittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: TheLittleGuy Contact: sip:+1-972-555-2222@gw1.there.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 Unauthorized F2 SIP server-> User B SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP there.com:5060 From: TheLittleGuy To: TheLittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER WWW-Authenticate: Chap realm="Generic Realm", domain="there.com", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", chap-id="210", stale="FALSE", algorithm="MD5" Content-Length: 0 REGISTER F3 B->SIP server REGISTER sip:there.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: TheLittleGuy To: TheLittleGuy Call-ID: 123456790@here.com CSeq: 1 REGISTER Contact: TheLittleGuy Contact: sip:+1-972-555-2222@gw1.there.com;user=phone Contact: tel:+1-972-555-2222 Mahler/Simunek/Biggs Internet Draft [Page 6] Internet-Draft SIP CHAP Authentication Protocol April 2000 Authorization:Digest username="UserB", realm="Generic Realm", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", chap-id="210", chap-uri="sip:there.com", response="dfe56131d1958046689cd83306477ecc" Content-Length: 0 200 OK F4 SIP server-> User B SIP/2.0 200 OK Via: SIP/2.0/UDP there.com:5060 From: TheLittleGuy To: TheLittleGuy Call-ID: 1234567890@here.com CSeq: 1 REGISTER Contact: TheLittleGuy Contact: sip:+1-972-555-2222@gw1.there.com;user=phone Contact: tel:+1-972-555-2222 Content-Length: 0 6. Security Considerations The security of this type of authentication method is limited in part by the security limitations of CHAP and the general security mechanism provided by SIP. SIP CHAP authentication suffers from many of the same limitations as does SIP Digest authentication, as discussed in Section 4 of RFC 2617. 7. References [1] Rigney C., Rubens A., Simpson W., Willens S., "Remote Authentication Dial In User Service (RADIUS)", RFC2138, April 1997 [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC1994 August 1996 [3] Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners-Lee T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC2616, June 1999 [4] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., "SIP: Session Initiation Protocol", RFC2543, March 1999 [5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen A., and Stewart, L., "HTTP Authentication: Basic and Digest Access Authentication", RFC2617, June 1999 [6] Crocker, David H., "Standard for the Format of ARPA Internet Text Messages", RFC822, August 13, 1982 Mahler/Simunek/Biggs Internet Draft [Page 7] Internet-Draft SIP CHAP Authentication Protocol April 2000 8. Authors' Addresses Jerry Mahler 3Com 3800 Golf Road Rolling Meadows, IL 60008 Jerry_Mahler@3com.com Paul Simunek 3Com 3800 Golf Road Rolling Meadows, IL 60008 Paul_Simunek@3com.com Billy Biggs 3Com 3800 Golf Road Rolling Meadows, IL 60008 Billy_Biggs@3com.com 13. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Mahler/Simunek/Biggs Internet Draft [Page 8] Internet-Draft SIP CHAP Authentication Protocol April 2000 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mahler/Simunek/Biggs Internet Draft [Page 9]