[-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-] {+has been deleted. Unrevised+} documents [-of-] {+placed in+} 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-] {+directories have+} a maximum {+life+} 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,-] {+months. After that time,+} 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.-] {+deleted.+} This {+Internet-Draft was not published as an RFC. Internet-Drafts are not an archival+} 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-] {+series,+} 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-] {+expired drafts, such+} 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-] {+one, are not available; please do not ask+} 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-] {+copies... they are+} not [-use RADIUS User-Password?-] {+available.+} 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-] {+Secretariat+} 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)-] {+not have information as+} to [-avoid cleartext transmission-] {+future plans+} 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-] {+authors+} or {+working groups WRT+} the [-server. If the nonce is generated by the client, the server may choose to accept it-] {+deleted Internet-Draft. For more information+} 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-] {+copy+} 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-] {+document, contact+} 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