Internet Engineering Task Force Bryan J. Byerly Internet Draft David Williams draft-byerly-sip-radius-00.txt Cisco Systems October, 2000 Expires: March, 2001 SIP Authentication using CHAP-Password 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/lid-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a proposed extension to SIP. This document proposes using an alternative SIP authentication mechanism for use in Proxy-Authorization or Authorization headers in order to support SIP client Authentication using backend RADIUS servers. The introduction of this extension would allow a SIP proxy (or called SIP client) to authenticate a SIP client using a backend RADIUS server. Byerly/Williams draft-byerly-sip-radius-00.txt Page 1 Internet Draft SIP Authentication using CHAP-Password October 2000 1 Introduction Some ISPs currently use RADIUS servers to authenticate (and implicitly authorize) dialup users for PPP service. It would be advantageous to allow the re-use of this same RADIUS infrastructure for SIP client authentication. Although the currently defined mechanisms for SIP client authentication [section 3.2.2.2 of RFC 2617] and RADIUS authentication using a User-Password or CHAP-Password [sections 5.2, 5.3 of RFC 2138] both use MD5, they run MD5 across differently formatted messages. There are two approaches to solving this problem. One is to extend RADIUS to support HTTP-Digest; the other is to extend the SIP list of authentication schemes to support a CHAP-Password. This document proposes extending the SIP list of authentication schemes to support a CHAP-Password. 2 Definitions The definitions of several terms used in this document follow: nonce A nonce is a octet string that is uniquely generated each time a request is made. It is recommended that a nonce be constructed to exhibit global and temporal uniqueness. The SIP specification [SIP] calls this a "nonce-value" (Section 3.2.1 of [DIG]). The RADIUS specification calls this a (random) challenge. (Section 2.2 of [RAD]) In RADIUS, the nonce can be placed in the Request Authenticator (Section 4.2 of [RADIUS]) or in the CHAP-Challenge attribute. (Section 5.40 of [RADIUS]) The CHAP Response in the CHAP-Password and the nonce-value in the HTTP-Digest use a 16-octet nonce. sequence number A sequence number is a monotonically increasing integer. Sequence numbers allow detection of replays. The "nonce-count" of the HTTP-Digest is a 32-bit sequence number (formatted as 8 hex digit characters) The "Chap-ID" in the CHAP-Password is a 1 octet sequence number. Byerly/Williams draft-byerly-sip-radius-00.txt Page 2 Internet Draft SIP Authentication using CHAP-Password October 2000 shared secret A secret shared between two entities. In this document, we assume that: - A user shares a secret (i.e. password) with the RADIUS server. - The PPP NAS (or SIP proxy) also shares a secret with the RADIUS server. 3 Analogous Model - PPP When a SIP proxy is used for user authentication an analogy can be drawn from PPP message flows. 3.1 Message flow for PPP user authentication with Radius backend: dialup PPP RADIUS user NAS server | | | |--modem connection--->| | | | | | PPP | | |<-Configure-Request---| | | | | | PPP | | |--Configure-Ack------>| | | | | | |--Access-Request------>| | | | | |<-Access-Challenge-----| | | | |<-CHAP Challenge------| | | | | |--CHAP Response------>| | | | | | |--Access-Request------>| | | | | |<-Access-Accept--------| | | | | | | Byerly/Williams draft-byerly-sip-radius-00.txt Page 3 Internet Draft SIP Authentication using CHAP-Password October 2000 3.2 Message flow for SIP user authentication with Radius backend: SIP SIP RADIUS client proxy server | | | |--[1] INVITE--------->| | | | | | |--[2] Access-Request-->| | | | | |<-[3] Access-Challenge-| | | | |<-[4] 407-------------| | | (Proxy-Authenticate:) | | | | |--[5] INVITE--------->| | |(Proxy-Authorization:) | | | | | |--[6] Access-Request-->| | | | | |<-[7] Access-Accept----| | | | | |--[8] INVITE------------------> | | | . . . |<--200---------------|<--200------------------------ When a PPP client authentication failure occurs, in some cases the PPP NAS implementation terminates the link. However, other PPP NAS implementations may choose to allow the client to continue, but with a filtered list of services. A PPP NAS may allow traffic which lets the user update his credentials (such as email to the sysadmin). Similarly, a SIP proxy server may wish to allow the user to place calls to the ISP's home office (to obtain updated credentials). A SIP proxy server may also wish to allow 911 calls to complete. 4 Current PAP/CHAP/SIP/HTTP Authentication mechanisms The following sections briefly describe the current mechanisms used for user authentication in PPP (PAP/CHAP) and HTTP/SIP (Basic and Digest). Byerly/Williams draft-byerly-sip-radius-00.txt Page 4 Internet Draft SIP Authentication using CHAP-Password October 2000 4.1 PAP authentication mechanism Why not use RADIUS User-Password? The RADIUS User-Password attribute is calculated as: User-Password = md5hash(NAS-secret, nonce) XOR user-password If a PPP user sends his password in cleartext (eg. using PAP), then the PPP server can calculate the User-Password attribute of the Access-Request to authenticate the user. It is undesirable for a SIP user to send his password in cleartext. If the user does NOT send his password in cleartext, the User-Password cannot be calculated by either the PPP client (because he doesn't know the NAS-secret) or the NAS (because he doesn't know the user-password). 4.2 CHAP authentication mechanism PPP defines usage of the CHAP-Password (as an alternative to User-Password) to avoid cleartext transmission of the users's password. When a CHAP-Password is used a cleartext sequence number, cleartext nonce, and the following MD5 hash are transmitted by the client: md5hash(seqnum, user-password, nonce) The nonce can be generated by the client or the server. If the nonce is generated by the client, the server may choose to accept it or may challenge the client with a new nonce. 4.3 SIP/HTTP authentication mechanisms: SIP and HTTP define two basic authentication mechanisms. HTTP-Basic and HTTP-Digest. Usage of HTTP-Basic involves sending the the user's password in cleartext, and is thus undesirable. The currently defined mechanisms for SIP client authentication using HTTP-Digest are taken from section 3.2.2.2 of RFC 2617 and the hash constructions are repeated here for clarity: If the directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd If the directive's value is "MD5-sess", then A1 is Byerly/Williams draft-byerly-sip-radius-00.txt Page 5 Internet Draft SIP Authentication using CHAP-Password October 2000 calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server. It uses the server nonce from the challenge, and the first client nonce value to construct A1 as follows: A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ":" unq(nonce-value) ":" unq(cnonce-value)) This creates a 'session key' for the authentication of subsequent requests and responses which is different for each "authentication session", thus limiting the amount of material hashed with any one key. [RFC 2617] 5 Interaction/Mapping problems There are two problems: 5.1 CHAP-Password construction problem: If a SIP proxy receives an HTTP-Digest from a SIP client (without CHAP-Password support), the SIP proxy is unable to construct a CHAP-Password. This is because the SIP proxy doesn't have access to the client's password. The SIP proxy only has access to a hash of the client's password, and (as dicussed above) this hash is computed across a message whose format is different than the RADIUS server expects. Nor can the SIP proxy simply forward the hash calculated in the HTTP-Digest: 5.2 Message mapping problem: Since the message format over which a hash is computed is different for the CHAP-Password than the message format used for the HTTP-Digest "MD5" or "MD5-sess" algorithms, a RADIUS server could not verify a proxied HTTP-Digest (which uses either the "MD5" or "MD5-sess" algorithms). The RADIUS server would discard such a HTTP-Digest formulated hash as invalid. Here is the proposed solution to these problems: 6 SIP Authentication using CHAP-Password To solve these problems, we specify an additional mechanism for SIP authentication which uses a CHAP-Password. CHAP-Password can either be used for endpoint-to-endpoint authentication (when used in WWW-Authenticate and Authorization) or for endpoint-to-proxy authentication (when used in Proxy-Authenticate and Proxy-Authorization). Byerly/Williams draft-byerly-sip-radius-00.txt Page 6 Internet Draft SIP Authentication using CHAP-Password October 2000 6.1 The WWW-Authenticate Response Header When a CHAP-Password is used for SIP authentication, the WWW-Authenticate Response Header (3.2.2 of RFC 2617) is defined as: WWW-Authenticate = "WWW-Authenticate" ":" "CHAP-Password" chap-challenge chap-challenge = * (";" chap-params ) chap-params = chap-username | chap-algorithm | chap-id | nonce chap-algorithm = "algorithm" "=" ( "MD5" | token ) chap-username = quoted-string chap-id = "id" "=" + ( digit ) chap-nonce = "nonce" "=" nonce-value chap-nonce-value = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" chap-algorithm: A string indicating the authentication method to be used. chap-username: A string containing the user name. chap-id: The CHAP Identifier is a one octet sequence number. nonce: A string of 32 hex digits. The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. Example: WWW-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb" The chap-username is copied from the User-Name attribute of the Access-Challenge message received from the RADIUS server. The chap-id is copied from the (1-octet) Identifier field of the Access-Challenge message received from the RADIUS server. The chap-nonce-value is copied from the Access-Challenge message from the RADIUS server (from the CHAP-Challenge attribute if present, otherwise from the Request Authenticator). Byerly/Williams draft-byerly-sip-radius-00.txt Page 7 Internet Draft SIP Authentication using CHAP-Password October 2000 6.2 The Authorization Request Header When challenged, the SIP client is expected to retry the request, passing an Authorization header line, which is defined as follows: Authorization = "Authorization" ":" "CHAP-Password" chap-response-line chap-response-line = * (";" chap-response-params ) chap-response-params = chap-username | chap-id | nonce | chap-response chap-response = "response" "=" chap-response-value chap-response-value = <"> 32LHEX <"> chap-response-value: A string of 32 hex digits computed as defined in Section 4.1 of RFC1994, which proves that the user knows a password. Example: Authorization: CHAP-Password ;username="byerly" ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb" ;response="f53a66e43c12a383aa65219ec873ce35" The client MUST increment the CSeq header before resubmitting the request. A server MAY be configured not to generate nonces only if replay attacks are not a concern. The Response Value (chap-response-value) of the CHAP-Password is computed per Section 4.1 of RFC 1994 [CHAP]. The 16-octet Response Value of the CHAP-Password should be formatted as 32 hex digits and placed in the "chap-response-value" of the Authorization request. The chap-id should be placed in the (1-octet) Identifier field of the Access-Request message to the RADIUS server. The chap-id should also be placed in the (1-octet) CHAP Identifier field of the CHAP-Password attribute of the Access-Request message to the RADIUS server. (See sections 3, 5.3, [RAD]) The nonce-value SHOULD be placed in the Request Authenticator of the Access-Request message to the RADIUS server. (See section 3, [RAD]) Alternatively, the nonce-value MAY be placed in a CHAP-Challenge attribute in the Access-Request message to the RADIUS server. (See section 5.3, [RAD]) The chap-response-value should be placed in the 16-octet String field of the CHAP-Password attribute in the Access-Request message to the RADIUS server. (See section 5.3, [RAD]) Byerly/Williams draft-byerly-sip-radius-00.txt Page 8 Internet Draft SIP Authentication using CHAP-Password October 2000 7 Proxy-Authenticate and Proxy-Authorization The CHAP-Password authentication scheme may also be used for authenticating users to proxies. 8 Security Considerations Security issues are the primary topic of this RFC. The security issues for this document are the same as those in the Security Considerations sections of RFC 1994 [CHAP] and RFC 2617 [DIG]. 9 Further Examples Only the relevant headers have been included in the following examples. 9.1 User Authentication using backend RADIUS server - With Server Challenge. [1] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 1 INVITE Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ;response="bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" Content-Type: application/sdp NOTE: The Proxy-Authorization header sent in the first message may have been cached from a previous exchange with the SIP proxy. If the SIP client does not place a Proxy-Authorization header in the INVITE, the RADIUS server will (transitting through SIP proxy) challenge him with a new nonce. [2] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 0 Length = 71 Request Authenticator = {16 octet random number also used as CHAP challenge (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)} Byerly/Williams draft-byerly-sip-radius-00.txt Page 9 Internet Draft SIP Authentication using CHAP-Password October 2000 Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet CHAP response (bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 [3] RADIUS server to SIP proxy server: Code = 11 (Access-Challenge} ID = 0 (same as in Access-Request) Length = 68 Attributes: Reply-Message = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" State = {Magic Cookie to be returned along with user's response; in this example 8 octets of data} [4] SIP proxy server to client: SIP/2.0 407 Proxy Authentication required From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 1 INVITE Proxy-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="cccccccccccccccccccccccccccccccc" State: {Magic Cookie from Access-Challenge packet, unchanged} (formatted as hex digits) NOTE: In this instance, the RADIUS server chooses to re-challenge the SIP client with a new nonce. [5] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 2 INVITE Content-Type: application/sdp Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="cccccccccccccccccccccccccccccccc" ;response="dddddddddddddddddddddddddddddddd" State: {Magic Cookie from Access-Challenge packet, unchanged} (formatted as hex digits) Byerly/Williams draft-byerly-sip-radius-00.txt Page 10 Internet Draft SIP Authentication using CHAP-Password October 2000 [6] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 1 (Note that this changes) Length = 71 Request Authenticator = {NEW 16 octet CHAP challenge ()} Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID followed by 16 octet CHAP response (dddddddddddddddddddddddddddddddd)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 State = {Magic Cookie from Access-Challenge packet, unchanged} [7] RADIUS server to SIP proxy server: Code = 2 (Access-Accept) ID = 1 (same as in Access-Request) Length = 30 [8] SIP proxy server to next hop UAS: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345600@cisco.com CSeq: 2 INVITE Content-Type: application/sdp 9.2 User Authentication using backend RADIUS server - Without Server Challenge. [a] SIP Client to SIP proxy server: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345601@cisco.com CSeq: 3 INVITE Proxy-Authorization: CHAP-Password ;username="byerly" ;algorithm="MD5" ;id=0 ;nonce="eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" ;response="ffffffffffffffffffffffffffffffff" Content-Type: application/sdp Byerly/Williams draft-byerly-sip-radius-00.txt Page 11 Internet Draft SIP Authentication using CHAP-Password October 2000 [b] SIP proxy server to RADIUS server: Code = 1 (Access-Request) ID = 0 Length = 71 Request Authenticator = {16 octet random number also used as CHAP challenge (eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)} Attributes: User-Name = "byerly" CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet CHAP response (ffffffffffffffffffffffffffffffff)} NAS-IP-Address = 192.168.1.16 NAS-Port = 5 [c] RADIUS server to SIP proxy server: Code = 2 (Access-Accept) ID = 1 (same as in Access-Request) Length = 56 [d] SIP proxy server to next hop UAS: INVITE sip:+19195551212@cisco.com SIP/2.0 From: sip:+19195551234@domain.com To: sip:+19195551212@cisco.com Call-ID: 12345601@cisco.com CSeq: 3 INVITE Content-Type: application/sdp There are two cases when a SIP client could pre-send a Proxy-Authorization that the RADIUS server might accept: 1) The RADIUS server originally generated the nonce when challenging the SIP client on a previous call. The SIP client is reusing the previously sucessful Authorization for a new call. 2) The SIP client originally generated the nonce. The parsed format of the nonce is known to both the SIP client and the RADIUS server. The nonce contains a timestamp which the RADIUS server can extract and use to limit the replay window. Since a RADIUS server silently discards invalid/unauthorized requests, this scheme is not subject to the form of the man-in-the-middle attack where Mallory sends a bogus request to the server and uses the response to make the client believe she is a legitimate server. To dos: 1) Fix the RADIUS Lengths to be correct 2) Calculate real MD5 hashes Byerly/Williams draft-byerly-sip-radius-00.txt Page 12 Internet Draft SIP Authentication using CHAP-Password October 2000 Outstanding issues: 1) Do we/how do we support the RADIUS State: attribute? What are the implications for collision with (DCS-)State: object? 2) Do we reuse the RADIUS NAS-Port and NAS-Port-Type attributes to allow the RADIUS server to have media port control over calls? (eg. using UDP port numbers for RTP streams) 10 Acknowledgements We would like to thank Roger Levesque, David Oran, Mike Thomas, David Daiker, Shail Bhatnagar, and Denise Caballero-McCann for discussions on the need for and improvements to this draft. We would also like to thank Tyrone Floryanzia for his insights on H.323 gateway/gatekeeper call authorization using RADIUS. 11 References [SIP] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Session Initiation Protocol", RFC 2543, March 1999. [RAD] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote Authentication Dial in User Service (RADIUS)," RFC 2138, April 1997. [DIG] Franks, J, et al. "HTTP Authentication: Basic and Digest Access Authentication," RFC 2617, June 1999. [CHAP] Simpson, W. "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [PAP] Lloyd, B, W. Simpson. "PPP Authentication Protocols", RFC 1334, October 1992. [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DayDreamer, July 1994. [MD5] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT Laboratory for Computer Science and RSA Data Security, Inc., RFC 1321, April 1992. [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC-2119, March 1997. Byerly/Williams draft-byerly-sip-radius-00.txt Page 13 Internet Draft SIP Authentication using CHAP-Password October 2000 Authors' Addresses Bryan J. Byerly Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA Email: byerly@cisco.com David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA Email: dwilli@cisco.com