INTERNET-DRAFT SIP Security Framework Michael Thomas Cisco Systems 27 Jun 2001 SIP Security Framework draft-thomas-sip-sec-framework-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 The SIP security framework defines a range of possible threats that a SIP message in transit might be subject to and provides an extensible framework to counter many of the threats using various crypto sys- tems. _1. _I_n_t_r_o_d_u_c_t_i_o_n SIP, because of its many trust boundaries and modes of operation pro- vides a challenge for the effective application of security mechan- isms that address the various threats. It should be noted from the outset that there is no such thing as "absolute" security. There are Thomas draft-thomas-sip-sec-framework-00.txt [Page 1] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 different levels of risk that various deployments are willing to tolerate given the spectrum of risk versus operational and deployment ease. Adding to the confusion, there are many existing security mechanisms with overlapping functionality. This draft tries to accom- modate a reasonable number of the usual suspects, but does not prom- ise to provide a generalized framework for every security mechanism which has graced the Internet. _1._1. _D_e_f_i_n_i_t_i_o_n_s Crypto-System In this memo, crypto-system refers to the general security scheme which provides cryptographic services which are available with that scheme. These services may include privacy, message integrity, replay protection, etc. Typical crypto-systems including CHAP/RADIUS, Kerberos, IPsec/IKE, etc. Message-Integrity A message integrity check is means of insuring that a mes- sage in transit was not altered. In combination with a key, a message integrity check (or checksum, or keyed hash) insures that only the holders of the proper keying materiel will be able to modify a message in transit without detec- tion. Authentication Authentication is means of identifying another entity. There are many ways to authenticate another entity, but the typical computer based methods involve digitally signing a set of bytes using a keyed hash. Authentication usually relies on either direct knowledge of the other entity (say, a shared symmetric key or possession of the other person's public key), or third party schemes such as Kerberos and X.509 Certificate Authorities. Authorization Once indentification of a correspondent is achieved, a decision must be made as to whether that identity should be granted access for the requested services. This is the act of authorization Confidentiality Cryptographic confidentiality means that only the intended recipients will be able to determine the contents of the confidential area. This is typically done using encryption Thomas draft-thomas-sip-sec-framework-00.txt [Page 2] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 algorithms such as DES and AES. Keyed-Hash A keyed hash is a means of providing message integrity by use with a strong one-way hash over the message body and a secret. Keyed hashes may be used with both symmetric and asymmetric keys to provide message integrity. Main-Level-SIP-Headers In the context of the SIP security framework, the term "mail level SIP headers" refers to the SIP headers which are not contained within attachments, and are typically where volatile headers such as VIA's go. Challenge A challenge is a means of requesting that an entity prove its identity using a particular crypto-system. Transform A Transform is a generic cryptographic operation, be it a one-way hash such as SHA-1 or an encryption/decryption algorithm such as AES. Credentials Credentials are identifying information which are typically cryptographically protected by a third party. Kerberos tickets and X.509 certficates issued by a certificate authority are examples of credentials. Realm A realm defines the boundary of trust from one administra- tive domain to another. Security-Association A security association refers to the existence of shared cryptographic state between two or more entities. Security associations are typically installed to mitigate the compu- tational and message overhead of cryptographic operations which could otherwise be performed without any prior state. KINK KINK is a means of creating IPsec security associations using Kerberos as a trusted third party. IKE IKE is a means of creating IPsec security associations using a variety of means including using pre-shared secrets, X.509 certifications, etc. Thomas draft-thomas-sip-sec-framework-00.txt [Page 3] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 IPsec IPsec is the layer three means of providing transport and tunnel security services of message integrity, confiden- tiality, and replay protection. TLS TLS is the layer four means of protecting TCP connections providing the security services of message integrity, con- fidentiality, replay protection, as well as authentication services. SMIME SMIME provides a means of using X.509 certificates and pub- lic key cryptography to sign and seal MIME attachments. IANA IANA is the registry which we all know and love. _2. _T_h_r_e_a_t_s SIP deployments are expected to run the gambit of exposure to threats. They may be deployed into relatively safe environments where equipment is all mutually trustworthy and physical security is argue- ably sufficient, all the way to the hostile environment of the Inter- net where no assumptions should be made. We consider threats to be one of two kinds. Outside threats are the broad spectrum of threats which can be perpetrated by attackers who are not in any way party to the SIP transaction at hand. Inside threats, on the other hand, are comprized of attacks where at least one party who is part of a particular transaction is not entirely trustworthy. In this draft, we use the term "transaction" to mean a SIP message and response it elicits. A transaction may traverse many SIP entities before a final response is given to the initiator. _2._1. _O_u_t_s_i_d_e _T_h_r_e_a_t_s Outside threats are of the type where a SIP message may traverse an untrustworthy segment of the network where exposure to uninvolved Thomas draft-thomas-sip-sec-framework-00.txt [Page 4] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 third parties is both possible and likely. The threats involved for SIP are essentially the same as the threats for any other protocol such as HTTP and SMTP which can traverse the network as plain text. The following list is not intended to be a comprehensive list of attacks; we list them only to reenforce the notion that the Internet is a hostile medium. _2._1._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _2._1._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _2._1._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _2._1._4. _I_n_t_e_g_r_i_t_y _2._1._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _2._2. _I_n_s_i_d_e _T_h_r_e_a_t_s Inside threats are threats which can be mounted by one or more of the participants of a particular transaction. Of inside and outside threats, inside threats pose a harder set of security problems. The reason lies in the fact that a participant to a transaction must be trusted to some degree, but not wholely trusted. For example, a UA may be trusted to hang up a phone to stop a billing timer to which it is cryptographically bound to, but may not be trusted to not try to assume the identity of another subscriber. SIP further complicates matters by allowing both end to end transactions as well as transac- tions which pass through intermediate proxies. The trust relationship between each pair of hosts in the overall transaction may be dif- ferent. _2._2._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n Between any two hosts involved in a transaction, an attacker could forge the identity of a legitimate user of the service. For example, unless some entity checks, there is nothing to prevent a UA to forge a legitimate From: address in an INVITE. Likewise, it may be possible Thomas draft-thomas-sip-sec-framework-00.txt [Page 5] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 for a host involved in the transaction to spoof a legitimate server in the transaction. _2._2._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y In a particular transaction, various parts of the messages may reveal confidential information to eavesdroppers. An obvious example is that confidential information such as media encryption keys may be revealed to intermediate proxies thus allowing the operator of the proxy to decrypt media streams. Another example is that certain pieces of SIP headers may reveal confidential information such as internal network topology, etc. _2._2._3. _P_r_i_v_a_c_y Running SIP over an IP network provides the opportunity for a user or intermediary to reveal information which would like to be kept confi- dential. An example is that some services require that the identity of a participant of a session must be kept confidential (eg, caller ID blocking). _2._2._4. _2._2._4 _I_n_t_e_g_r_i_t_y It is possible that a party to a transaction could tamper with vari- ous parts of the transaction, perhaps acting as a malicious man in the middle. Another threat is a replay attack where a man in the mid- dle could replay a legitimate portion of a previously received mes- sage (perhaps encrypted), for which the end receiver could not dis- cern the difference between a legitimate piece of information and a replay. Thomas draft-thomas-sip-sec-framework-00.txt [Page 6] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _2._2._5. _A_u_t_h_o_r_i_z_a_t_i_o_n Even if the participants in a transaction are properly identified, there are threats where the requestor is not authorized to perform the action. Likewise, a responder may be not be authorized to perform the action which was requested. Given the vagueries of proxy routed traffic, forking, etc, this threat with SIP requires more provision than a simplistic "don't request something from somebody you don't trust". _3. _R_e_q_u_i_r_e_m_e_n_t_s _3._1. _O_v_e_r_a_l_l _R_e_q_u_i_r_e_m_e_n_t_s o Mutual Authentication o Confidentiality both outside and inside as possible o Integrity, both outside and inside as possible o Should consider direct and third party authentication models o Proxied authentication (for privacy, etc) o Multiple different authentication points o Support public key systems -- both public key and PKI based o Support secret key systems -- both local, Kerberos and other secret keys o Guard against hostile (MITM) intermediary proxies as must as possible o Provide end to end, end to middle, and middle to middle secure transport of certain bits (TBD, but, say, SMIME e2e...) o Should provide means of firewall proxy transit, with dynamic discovery of the existence of firewalls. Thomas draft-thomas-sip-sec-framework-00.txt [Page 7] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 o Must allow for stateless operation of any credential based authorization o May allow for cached credentials at various points; if allowed, credential providers must be signaled that the credentials were cached. o Should allow authorization to be bound to authentication tokens (eg, DCS state blobs, OSP tokens, Ticket extensions, etc) o Should allow for coupled media authorization (ie, allow SIP based authentication to be reused for QoS authorization to allow QoS signaling to rendevouz at a PEP) (aka DQoS) /* etc, etc, etc */ _3._2. _P_r_o_x_y _R_o_u_t_e_d _M_e_s_s_a_g_e _I_n_t_e_r_f_a_c_e _R_e_q_u_i_r_e_m_e_n_t_s SIP brings to the fore many different trust boundaries which need to be considered. It should be noted that "trust" is a relative term, situational, and not necessarily symmetric. For example, a UA may trust its first hop proxy to route INVITE's expeditiously, but it may not trust its proxy to not expose media encryption keys to third par- ties. We introduce the concept of a trust boundary. Simply put, a trust boundary is the edge of where trust policies and considerations change. This draft considers each of the various trust boundaries and what the security implications are for each of them. SIP trapezoid is typically modeled as a trapezoid where there is a UAC and UAS with two intermediate proxies for initial INVITE's. This model reenforces the notion that SIP may go through multiple proxies as well suggesting that the notion that UA's may associate with prox- ies which are trusted to some degree. This is a good start for SIP in general, but not entirely adequate for modeling the various threats that can arise with proxy routed INVITE's. The reason is that an INVITE may pass through a proxy for which neither the UAC or UAS have no direct trust relationship at all. For this reason, we model the SIP trust boundaries as a pentagon instead. To differentiate it from the SIP trapezoid, we will call this the SIP JITB (Jack in the Box). Thomas draft-thomas-sip-sec-framework-00.txt [Page 8] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 I / ( / ( / ( / ( H J / / M-----B UA to Internal Nodes _3._2._1. _M->_H, _B->_J _3._2._1._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._2._1._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._2._1._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _3._2._1._4. _I_n_t_e_g_r_i_t_y _3._2._1._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _3._2._1._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e _3._2._2. _M->_I, _B->_I _3._2._2._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._2._2._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._2._2._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) Thomas draft-thomas-sip-sec-framework-00.txt [Page 9] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _3._2._2._4. _I_n_t_e_g_r_i_t_y _3._2._2._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _3._2._2._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e _3._2._3. _M->_J, _B->_H _3._2._3._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._2._3._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._2._3._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _3._2._3._4. _I_n_t_e_g_r_i_t_y _3._2._3._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _3._2._3._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e _3._2._4. _M->_B _3._2._4._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._2._4._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._2._4._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _3._2._4._4. _I_n_t_e_g_r_i_t_y _3._2._4._5. _A_u_t_h_o_r_i_z_a_t_i_o_n Thomas draft-thomas-sip-sec-framework-00.txt [Page 10] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _3._2._4._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e _3._3. _I_n_t_e_r_n_a_l _N_o_d_e_s _3._3._1. _H->_I, _J->_I _3._3._1._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._3._1._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._3._1._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _3._3._1._4. _I_n_t_e_g_r_i_t_y _3._3._1._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _3._3._1._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e _3._3._2. _H->_J, _J->_H _3._3._2._1. _A_u_t_h_e_n_t_i_c_a_t_i_o_n _3._3._2._2. _C_o_n_f_i_d_e_n_t_i_a_l_i_t_y _3._3._2._3. _P_r_i_v_a_c_y (_i_e _c_a_l_l _p_r_i_v_a_c_y) _3._3._2._4. _I_n_t_e_g_r_i_t_y _3._3._2._5. _A_u_t_h_o_r_i_z_a_t_i_o_n _3._3._2._6. _D_e_n_i_a_l _o_f _S_e_r_v_i_c_e Thomas draft-thomas-sip-sec-framework-00.txt [Page 11] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _3._4. _R_e_d_i_r_e_c_t _a_n_d _R_e_g_i_s_t_r_a_t_i_o_n _I_n_t_e_r_f_a_c_e _R_e_q_u_i_r_e_m_e_n_t_s Same as UA's?? _4. _S_I_P _S_e_c_u_r_i_t_y _F_r_a_m_e_w_o_r_k The SIP security framework address two classes of threats. First, the framework addresses threats which originate from basic transport con- siderations (ie, vulnerabilities of transporting SIP in the clear over UDP and TCP). Next the framework addresses threats which ori- ginate at the SIP application layer, and where the participating entities in a transaction may not be trustworthy. SIP itself does not define any transport layer security mechanisms, but instead relies other encapsulations such as [TLS] or [IPSEC] to provide the required security for the whole message. Likewise, the SIP security framework itself does not specify a means of cryptographically protecting MIME messages for each crypto-system, but instead provides a framework and guidelines for other memos to instantiate SIP's ability to use other crypt-osystems. The general format of a SIP message using this frame- work is a main SIP message header, followed by any number of MIME attachments, any of which can be of type sip-secure, which provides the required cryptographic encapsulations. The actual contents of the attachments -- beyond the required headers to implement the crypto- system -- are normal SIP headers which are intended to be protected. Unlike message/sip attachments, sip-secure attachments (?), the con- tents of a sip-secure attachment should be viewed as a continuation of the headers in the main header section of the SIP message. Note that the following headers MUST NOT be placed in a secure attachment: Via The general format of the SIP message with secure attachments is as follows: Thomas draft-thomas-sip-sec-framework-00.txt [Page 12] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 +----------------------+ | | ~ ~ <--- Main SIP header | Volatile | | Headers | | | +----------------------+ | | | | ~ message/sip-secure ~ <--- SIP body, which may contain | | attachments +----------------------+ | | | | ~ message/sip-secure ~ <--- More attachments, and so forth | | +----------------------+ The SIP security framework provides a simple means of providing a challenge/response mechanism to elicit the proper cryptograhic mechanisms to be used by the initiator and respondent. In addi- tion, a simple negotiation mechanism for offering and choosing capabilities is also provided by the framework. This is acheived using the SIP security framework primatives: X-SIP-SECURE-SUPPORTS: Which tells the respondent which crypto systems the initiator is willing to support. X-SIP-SECURE-REQUIRES: Which tells the initiator which crypto systems the respondent requires to be used for subsequent messages. A respondent is not required to see an initial X-SIP-SECURE-SUPPORTS header in order to challenge the initiator. In general, the SIP security framework treats SIP messages and attachments with strict lexigraphic scoping rules. That is to say, the headers pertaining to security within a message or attachment refer to their immediate enclosing lexigraphic entity. For example, an initial INVITE to a UAC's upstream proxy, P1, for which it has no previous knowledge of which tran- sport layer mechanisms it should use might be willing to send an Thomas draft-thomas-sip-sec-framework-00.txt [Page 13] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 initial INFO in the clear to find out which crypto systems it should use to transport subsequent SIP messages: INFO P1@mtcc.com SIP/2.0 From: UAC@cisco.com X-SIP-SECURE-TO: P1@mtcc.com X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-SUPPORTS: ipsec.sec.sip.iana=(r:mtcc.com, k:kink); ipsec.sec.sip.iana=(r:bar.com, k:ike); tls.sec.sip.iana=(r:bar.com); This message tells the upstream proxy that it is willing to use either IPsec or TLS, and that it has credentials in the realms mtcc.com and bar.com for IPsec, but only bar.com for TLS. Note also that since exchange of keying material is outside of the scope of IPsec proper, that within each realm a key exchange method may be specified though there are transport method specific defaults, IKE in the case of IPsec. To this the proxy would choose one method and respond with a X- SIP-SECURE-REQUIRES header: SIP/2.0 200 OK X-SIP-SECURE-TO: UAC@mtcc.com X-SIP-SECURE-FROM: P1@mtcc.com X-SIP-SECURE-REQUIRES: ipsec.sec.sip.iana=(r:mtcc.com:kink) This informs the UAC that subsequent messages it sends should use transport mode IPsec using credentials from the realm "mtcc.com" using KINK to do the keying. The actual meaning of realm here is crypto-system dependent. Although the mechanisms to secure transport and application aren't identical, they do share many characteristics, namely: o The use of X-SUPPORTS and X-REQUIRES are used identically as main level SIP headers as they are as attachments. Commands may be challenged to provide proper credentials and security mechan- isms. o Secured entities, be they whole SIP messages or attachments, must be self-describing. That is, the message or attachment must fully describe the contents of the command or response within the lexigraphical scope of the message or attachment. That means that identifying information to determine which Thomas draft-thomas-sip-sec-framework-00.txt [Page 14] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 cryptographic transforms to perform on the o Credentials may be cached _4._1. _S_I_P _S_e_c_u_r_i_t_y _F_r_a_m_e_w_o_r_k _H_e_a_d_e_r_s _4._1._1. _X-_S_I_P-_S_E_C_U_R_E-_T_O The entity who the attachment is destined for. For end to end attach- ments, this would normally be the same as the SIP To: address. For intermediate destinations, however, it will normally be the entity which issued a challenge. If the ultimate destination is not known, the entity may be wildcarded by setting the left hand side of the RFC 822 address to "*". Wildcarding is useful for attachments which are signed using public key cryptography, since the sender need not know the ultimate destination. X-SIP-SECURE-TO MAY be used at the main SIP header level. If it is omitted, the To: address is implied with any other X-SIP-SECURE headers. This header MUST be present in attachments. Format: X-SIP-SECURE-TO: to-address Where: to-address an opaque and crypto system dependent string denoting the intended recepient and their realm. _4._1._2. _X-_S_I_P-_S_E_C_U_R_E-_F_R_O_M This is the entity that is supplying the attachment. For UAC's, this Thomas draft-thomas-sip-sec-framework-00.txt [Page 15] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 can be the From: address, but is in fact crypto-system specific. X-SIP-SECURE-FROM MAY be used at the main SIP header level. If it is omitted, the From: address is implied with any other X-SIP-SECURE headers. This header MUST be present in attachments. Format: X-SIP-SECURE-FROM: from-address Where: from-address an opaque and crypto system dependent string denoting the sender and realm. _4._1._3. _X-_S_I_P-_S_E_C_U_R_E-_S_U_P_P_O_R_T_S The X-SIP-SECURE-SUPPORTS header tells the respondent which crypto- systems the entity which inserts the SUPPORTS header is willing to provide. Note that transaction stateful proxies MAY insert X-SIP- SECURE-SUPPORTS headers along with the UAC. Proxies that add SUPPORTS headers MUST inspect responses to determine whether a matching X- SIP-SECURE-REQUIRES is present and take appropriate action. Format: X-SIP-SECURE-SUPPORTS: method[=([R:realm,] [K:keying,] [M] )] [; method[=([R:realm,] [K:keying,] [M] )]]* Where: Method Method describes the cryptographic method which the entity is willing to support. For example, TLS, SMIME, etc. All standard methods MUST be registered with IANA. R:realm Realm describes the realm that the X-SIP-SECURE-TO: must authenticate within. By default, this is the same realm as the value of the X-SIP-SECURE-FROM address if present, or Thomas draft-thomas-sip-sec-framework-00.txt [Page 16] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 the SIP From: header if not. K:keying Keying describes the key distribution method if there is more than one choice for keying for the method. For exam- ple, IPsec may be keyed manually, with IKE or KINK. All standard keying methods MUST be registered with IANA. M The "M" flag requests that mutual authentication be per- formed. When sent in a SUPPORTS header, this informs that the intended recipient if it chooses this method, it MUST be prepared to perform the method specific means of mutu- ally authentication. _4._1._4. _X-_S_I_P-_S_E_C_U_R_E-_R_E_Q_U_I_R_E_S X-SIP-SECURE-REQUIRES places a requirement on the listed entities that they must provide the security mechanism to make forward pro- gress. Note that there MUST only be a single entity listed which the some initiator path must provide the required cryptographic services for. A special entity, "*" may be inserted to inform the entity that any entity within the realm will be considered for the request. Transaction stateful proxies SHOULD inspect responses for X-SIP- SECURE-REQUIRES headers to determine whether the next hop in the for- warding path requires that the proxy provide cryptographic services for the next hop. Typically, this is useful for proxies to determine what security mechanism should be used for SIP message transport to adjacent proxies and/or UAS's. Format: X-SIP-SECURE-REQUIRES: method[=([R:realm,] [K:keying])] Where: Method Method describes the cryptographic method which the entity is willing to support. For example, TLS, SMIME, etc. All standard methods MUST be registered with IANA. R:realm Realm describes the realm that the X-SIP-SECURE-TO: must authenticate within. By default, this is the same realm as the value of the X-SIP-SECURE-FROM address if present, or the SIP From: header if not. Thomas draft-thomas-sip-sec-framework-00.txt [Page 17] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 K:keying Keying describes the key distribution method if there is more than one choice for keying for the method. For exam- ple, IPsec may be keyed manually, with IKE or KINK. All standard keying methods MUST be registered with IANA. _4._1._5. _X-_S_I_P-_S_E_C_U_R_E-_M_E_T_H_O_D X-SIP-SECURE-METHOD defines the actual method which has been used to secure a sip-secure attachment. The syntax is identical to X-SIP- SECURE-REQUIRES in that only one method should be present. Format: X-SIP-SECURE-METHOD: method[=([R:realm,] [K:keying,] [M] )] Where: Method Method describes the cryptographic method which the entity is willing to support. For example, TLS, SMIME, etc. All standard methods MUST be registered with IANA. R:realm Realm describes the realm that the X-SIP-SECURE-TO: must authenticate within. By default, this is the same realm as the value of the X-SIP-SECURE-FROM address if present, or the SIP From: header if not. K:keying Keying describes the key distribution method if there is more than one choice for keying for the method. For exam- ple, IPsec may be keyed manually, with IKE or KINK. All standard keying methods MUST be registered with IANA. M The "M" flag requests that mutual authentication be per- formed. The recipient MUST perform the method specific mutual authentication in the response back from the entity. Note that for entities like proxies, the authentication SHOULD be placed in the normal return reply when it is part of an attachment. _4._2. _S_I_P _S_e_c_u_r_i_t_y _A_t_t_a_c_h_m_e_n_t_s Thomas draft-thomas-sip-sec-framework-00.txt [Page 18] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 SIP security attachments are regular MIME attachments which contain the contents of type: message/sip-secure SIP security attachments may attached by any entity that receieves a SIP message, either as an initial SUPPORTS type attachments, a chal- lenge to a upstream entity, or as a response to a challenge. SIP security attachments all contain fields which identify the who the intended receipient is, the supplier of the attachment, and the specific cryptographic content of the body of this attachment. Actual SIP security attachments can be thought of as objects with a base class which are extended by other protocols which adhere to the SIP security framework. _4._2._1. _S_I_P-_S_e_c_u_r_e _A_t_t_a_c_h_m_e_n_t_s The SIP security framework defines a single attachment type, sip- secure. The sip-secure attachments has two variants which complement the main header level usage of X-SIP-SECURE-SUPPORTS and X-SIP- SECURE-REQUIRES. Sip-secure attachments all contain the required headers listed above. It should be noted that the use of supports/requires is strictly optional. That is, if a UA or Proxy has prior knowledge (usually through configuration) that it can attach sip-secure attachments with the proper cryptographic methods. Format: Required-headers [Required-headers]* [Other-headers]* Where the required headers are: o Content-Type: o Content-Length: o X-SIP-SECURE-TO: o X-SIP-SECURE-FROM: o X-SIP-SECURE-METHOD: Thomas draft-thomas-sip-sec-framework-00.txt [Page 19] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _4._2._2. _S_I_P-_S_e_c_u_r_e _S_u_p_p_o_r_t_s _V_a_r_i_a_n_t This form of the sip-secure attachment transports a single X-SIP- SECURE-SUPPORTS header. This form of the sip-secure attachment informs the destination what cyptosystem capabilities the supplier has. Since the sender of the Supports variant probably doesn't have any way to cryptographically protect the message, the built in NULL transform of the Pre-Shared crypto-system MAY be used. While the normal use of the sip-secure attachment is to produce cryp- tographically protected sip-secure attachments, the use of X-SIP- SECURE-SUPPORTS is fully general, and as such can be used to signal end to end transport security mechanisms. This is especially useful if the the initial INVITE results in an end to end Contact header between the UAC and UAS where further messages can be secured using transport layer security instead of attachments. It should be noted that SIP commands can be thought of as having an implicit sip-secure attachment around them with a NULL transform used with the Pre-Shared crypto-system. _4._2._3. _S_I_P-_S_e_c_u_r_e _R_e_q_u_i_r_e_s _V_a_r_i_a_n_t This variant of the sip-secure attachment demands that the entity in the X-SIP-SECURE-TO: address supply the appropriate cryptographic services listed. Note that this attachment could be subject to sub- ject to man in the middle attacks if the creator uses the NULL transform of the Pre-Shared crypto-system. This method SHOULD NOT be used if the creator of the attachment could have protected the attachment using the agreed upon crypto-systems, or alternatively, used end to end cryptographic methods to secure the entire SIP mes- sage. _4._3. _S_I_P _M_e_s_s_a_g_e _C_o_n_t_e_n_t_s _w_i_t_h _S_e_c_u_r_i_t_y SIP presents some challenges when the UAC (or Proxy for that matter) either doesn't know the cryptographic identity which it should use to sign and seal attachments, or doesn't know the realms or crypto- Thomas draft-thomas-sip-sec-framework-00.txt [Page 20] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 systems which the ultimate entity will support. This is especially true if INVITE's are forked, forwarded, redirected, etc. Thus if there is the desire to secure various SIP headers for which an ade- quately protected sip-secure attachment cannot be created on the ini- tial command, the command MUST NOT contain the sensitive headers. Instead, a Supports variant of the sip-secure attachment MUST be created for the ultimate destination (usually the To: address). When the ultimate destination of the Supports variant receieves the mes- sage, it creates a Requires variant which informs the UAC how to contstruct the sip-secure attachments. When the UAC receives the Requires variant, it may then safely create properly protected sip- secure attachments. _4._4. _C_a_c_h_e_d _C_r_e_d_e_n_t_i_a_l_s Normally, the assumption is that SIP proxies are session stateless. That is, no state is retained once the transaction state (if any) is cleared. Introduction of security, however, begs this assumption. Clearly, use of security protocols such as IPsec and TLS will gen- erally violate the spirit of transaction statelessness since the cryptographic context for the security associations they create will typically survive a single transaction. Indeed, the very use of a reliable transport layer such as TCP causes state to typically be retained beyond a single transaction. While statelessness is a nice property it comes at a price. Even with a reliable transport, it is extremely useful to cache transport connections even transaction are complete as the experience with HTTP 1.0 and 1.1 amply demonstrate. Given the need to protect against replay attacks, security protocols generally require freshness checks, which typically require some sort of keyed hash over the message with replay protection. While most security protocols can run in a stateless mode, in practice this usu- ally produces unsatisfactory results because the credentials required are typically rather large causing MTU considerations, and the CPU complexity can be considerable if the messages require expensive pub- lic key cryptography. For this reason, the SIP security framework introduces the concept of a Credential Cache to SIP. The credential cache provides a means for a given crypto-system to both omit the initial credentials that were presented for that crypto system, as well allow the use of symmetric keys if the crypto system uses public key cryptography. The creden- tial cache itself is keyed off of the X-SIP-SECURE-FROM, X-SIP- SECURE-TO, and X-SIP-SECURE-METHOD tuple. Thomas draft-thomas-sip-sec-framework-00.txt [Page 21] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 While the exact details are outside of the scope of the framework itself, the following guidelines MUST be followed. o All crypto systems MUST provide a means to initially authenti- cate, possibly installing a cached entry. Subsequent requests using credential cache semantics MUST differentiate whether a cached credential should be used or whether a fresh credential is present. o It MUST NOT be assumed that the recipient of a sip-secure attachment will be able to cache that particular credential, or that the credentials will be valid for any particular duration. o The particular crypto system SHOULD provide a means of notifying the initiator whether the credentials were cached. o If public key cryptography is required, the crypto system SHOULD provide a means of exchanging symmetric keys to be used for encryption and message integrity. o If the size of the credentials can generally be expected to be greater than 128 octets, the crypto system SHOULD provide a means of exchanging symmetric keys for encryption and message integrity. o If the crypto system cannot provide for cached credentials, it MUST be explicit any security weaknesses that its use may expose users to, such as replay weakness, etc. _4._5. _A _W_o_r_d _A_b_o_u_t _V_e_r_i_f_y_i_n_g _I_d_e_n_t_i_t_i_e_s When a sip-secure message is received, the credentials and crypto- graphic context which authenticate the message MUST be used to cross verify any identities contained in the body of the attachment. Specifically, the verifier MUST NOT allow an attachment or transport protected message to verify but allow the inner identies to be forged. For example, suppose that the outer cryptographic credentials in the attachment were verified to be mat@cisco.com in, say, a Ker- beros realm. If an inner header, such as the From: address contains gwb@whitehouse.gov, the verifier MUST insure that there is a valid mapping of mat@cisco.com in that Kerberos realm to gwb@whitehouse.gov. In this particular case, the result ought to result in a 4xx message since no such mapping will be found. Thomas draft-thomas-sip-sec-framework-00.txt [Page 22] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 _4._6. _U_s_e _o_f _I_N_F_O _f_o_r _t_o _I_n_i_t_i_a_t_e _T_r_a_n_s_p_o_r_t _S_e_c_u_r_i_t_y [XXX/mat: I can already hear the groans, so please help me out here. The issue is that INVITE's shouldn't be sent in the clear before the basic transport layer security is set up. I'm essentially using INFO as a SIP ping so that if you don't know what the other side supports you can get clued in using the support/require mechanism. I know this is bogus on proxies, but I'm not exactly sure what to do... a new method??] In order to instantiate hopwise transport layer security associations when the capabilities of the respondent are not known, a SIP entity SHOULD NOT expose potentially sensitive information in the clear. Instead it SHOULD use the INFO method to the next hop using X-SIP- SECURE-SUPPORTS to find a common crypto system. The INFO method MUST be directed at the next hop, not the end UAS in original method triggering the need for a security association. _5. _E_x_a_m_p_l_e _F_l_o_w_s _5._1. _G_r_o_u_n_d _S_t_a_t_e _E_x_a_m_p_l_e _F_l_o_w Clearly, an example is in order here. Let's assume that there exists a UAC which is trying to call a UAS which sits behind a SIP proxy functioning at the edge of a corporate network, and thus needs to authenticate incoming calls. The UAC uses the services of its own first hop proxy. Furthermore, the UA's would like to keep the keys to encrypt the media stream private, thus they would like to sign and seal their SDP announcements using public key cryptography. UAC ini- tiates this by sending a sip-secure Supports type attachment directed at the TO: address. Initially, UAC, P1, P2, and UAS know nothing about each other. UAC P1 P2 UAS --------------------------------------------------------------- Thomas draft-thomas-sip-sec-framework-00.txt [Page 23] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 1 INFO-----------------> 2 <------------------401 3 IKE------------------> 4 <------------------IKE 5 INVITE--------------> 6 INFO---------------> 7 <----------------4xx 8 TLS----------------> 9 <----------------TLS 10 INVITE-------------> 11 <----------------4xx 12 <-----------------4xx 13 INVITE--------------> 14 --------------------> 15 INFO----------------> 16 <-----------------200 17 INVITE--------------> 18 <-----------------200 19 <-----------------200 20 <-----------------200 21 INVITE--------------> 22 INVITE--------------> 23 INVITE-------------> 24 <----------------200 25 <-----------------200 26 <-----------------200 (1) The UAC notices that doesn't have a security association with P1, therefore sends an INFO to determine how to secure the SIP messages. It sends a lone IPsec in the realm mtcc.com as its method of choice. INFO P1@mtcc.com SIP/2.0 From: UAC@mtcc.com X-SIP-SECURE-TO: P1@mtcc.com X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-SUPPORTS: ipsec.sec.sip.iana=(r:mtcc.com, k:IKE) (2) The Proxy finds the IPsec crypto system acceptible and repeats that requires it. SIP/2.0 401 X-SIP-SECURE-REQUIRES: ipsec.sec.sip.iana=(r:mtcc.com, k:IKE) (3,4)The IKE exchange to set up the security association Thomas draft-thomas-sip-sec-framework-00.txt [Page 24] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 [XXX/mat: in general it would be better to allow the responder to initiate the IPsec/TLS connection itself in parallel with step 2. That means we'd need some signaling saying "got your Support, I chose X, but am initiating it myself, thanks."] (5) The INVITE to UAS is sent. Note that we send a sip-secure attachment with the crypto systems we support. INVITE UAS@mtcc.com SIP/2.0 From: UAC@mtcc.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__FooTheFunLovingBar__" __FooTheFunLovingBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-TO: UAS@mtcc.com X-SIP-SECURE-SUPPORTS: SMIME.sec.sip.iana=(r:mtcc.com) X-SIP-SECURE-METHOD: preshared.sec.sip.iana Authentication: NULL Encryption: NULL (6) Since the proxy P1 doesn't have a security association with P2, it sends an INFO to create one. Note that TLS uses the default realm and keying. INFO P2@mtcc.com SIP/2.0 From: P1@mtcc.com X-SIP-SECURE-TO: P2@mtcc.com X-SIP-SECURE-FROM: P1@mtcc.com X-SIP-SECURE-SUPPORTS: TLS.sec.sip.iana=(r:mtcc.com) (7) The Proxy P2 finds the TLSc crypto system acceptible and repeats that requires it. SIP/2.0 401 X-SIP-SECURE-REQUIRES: TLS.sec.sip.iana=(r:mtcc.com) (8,9)The TLS exchange to set up the security association between P1 and P2 Thomas draft-thomas-sip-sec-framework-00.txt [Page 25] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 (10) The original INVITE is forwarded to P2 (11) P2 determines that it wants application layer credentials from UAC to let it behind the wall of the sprawling mtcc.com cor- porate complex using the CHAP authentication method. Note that the realm is implicitly the realm of the X-SIP-SECURE-FROM address. SIP/2.0 401 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__BarTheFunLovingFoo__" __BarTheFunLovingFoo__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: P2@mtcc.com X-SIP-SECURE-TO: UAC@mtcc.com X-SIP-SECURE-REQUIRES: CHAP.sec.sip.iana X-SIP-SECURE-METHOD: preshared.sec.sip.iana Authentication: NULL Encryption: NULL # CHAP specific headers here... (12) P1 forwards the 401 message back to UAC (13) UAC now knows that it needs to supply credentials, thus is creates a new INVITE which contains the original message as well as the CHAP challenge: INVITE UAS@mtcc.com SIP/2.0 From: UAC@mtcc.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__FooTheFunLovingBar__" __FooTheFunLovingBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-TO: P2@mtcc.com X-SIP-SECURE-METHOD: CHAP.sec.sip.iana # CHAP specific goodies here. Thomas draft-thomas-sip-sec-framework-00.txt [Page 26] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 __FooTheFunLovingBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-TO: UAS@mtcc.com X-SIP-SECURE-SUPPORTS: SMIME.sec.sip.iana=(r:mtcc.com) X-SIP-SECURE-METHOD: preshared.sec.sip.iana Authentication: NULL Encryption: NULL (14) Proxy P1 forwards the message to P2 (15) Proxy P2 verifies the INVITE against the challenge it issued to UAC. P2 discovers that it doesn't have a security association with UAS and informs UAS what crypto systems it supports: INFO UAS@mtcc.com SIP/2.0 From: P2@mtcc.com X-SIP-SECURE-TO: UAS@mtcc.com X-SIP-SECURE-FROM: P2@mtcc.com X-SIP-SECURE-SUPPORTS: tls.sec.sip.iana; preshared.sec.sip.iana (16) The UAS doesn't think it needs hopwise crypto at all since it's behind its corporate firewall and sends the preshared crypto system with a null transform. SIP/2.0 401 X-SIP-SECURE-REQUIRES: preshared.sec.sip.iana (17) Proxy P2 evaluates its policy and determines that null hopwise encryption is acceptible and forwards the INVITE. Note that Proxy P2 MAY strip its challenge out from the INVITE. (18) The INVITE finally makes it to UAS with the Sip-Secure attach- ment. UAS examines it, and determines that it can support SMIME attachments. In turn, it encapsulates any sensitive data into its own SMIME attachment. Note that including the Requires into the SMIME attachment has the added benefit that it protected. SIP/2.0 200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__FunTheFooBarLoving__" Thomas draft-thomas-sip-sec-framework-00.txt [Page 27] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 __FunTheFooBarLoving__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAS@mtcc.com X-SIP-SECURE-TO: UAC@mtcc.com X-SIP-SECURE-METHOD: SMIME.sec.sip.iana X-SIP-SECURE-REQUIRES: SMIME.sec.sip.iana # SMIME specific goodies here, as well as any SDP etc. (19) Proxy P2 forwards to Proxy P1 (20) Proxy P1 forwards to UAC. (21) UAC receives the 200 and decides that it needs to send its SDP in a re-INVITE protected by the SMIME encapsulation. INVITE UAC@mtcc.com SIP/2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=" __LovingThe- FooBar__" __LovingTheFooBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-TO: P2@mtcc.com X-SIP-SECURE-METHOD: CHAP.sec.sip.iana # CHAP specific goodies here. __LovingTheFooBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAC@mtcc.com X-SIP-SECURE-TO: UAS@mtcc.com X-SIP-SECURE-METHOD: SMIME.sec.sip.iana # rest of the SMIME and other goodies (22) P1 forwards to P2 (23) P2 checks the credentials that were supplied by UAC. Since the nonce challenge timer hasn't expired, it allows passage, and P2 forwards the re-INVITE to UAS. Thomas draft-thomas-sip-sec-framework-00.txt [Page 28] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 (24) UAS receives the message and formats a response, part of which needs to be protected in a SMIME enclosure. SIP/2.0 200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__TheBarLovingFunFoo__" __TheBarLovingFunFoo__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: UAS@mtcc.com X-SIP-SECURE-TO: UAC@mtcc.com X-SIP-SECURE-METHOD: SMIME.sec.sip.iana (25) P2 forwards to P1 (26) P1 forwards to UAC and the session should be established (modulo PRACK's, 183's and other sources of joy). At first blush, this looks like a horrendous number of messages. How- ever, caching security state along the way will generally produce a much more streamlined process. In particular, the hopwise security associations between UAC and P1, P1 and P2, and P2 and UAS may very well be long lived. While the security association between UAC and UAS in high fan out situations may be transient, this is the general cost of desiring security between the two UA's. If relying on hopwise security and the inherent issues revolving around transitive trust is acceptible, it should be noted that routing all messages through proxies will provide the same level of protection as the original command sent, at the burden of potentially unnecessary proxy routed traffic. Considerations about proxy routed traffic or transport layer security associations, etc, etc are left as system design issues, and are outside of the scope of this memo. Thus, assuming that all parties are willing to cache credentials and common crypto systems, subsequent sessions will be reduced to: UAC P1 P2 UAS --------------------------------------------------------------- 1 INVITE---------------> 2 INVITE-------------> 3 INVITE--------------> 4 <-----------------200 5 <-----------------200 6 <------------------200 Thomas draft-thomas-sip-sec-framework-00.txt [Page 29] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 Note that any entity in the proxy routed path may experience a cache miss which will require that the cached state be recreated between those two entities. _5._2. _E_x_a_m_p_l_e _F_l_o_w _w_i_t_h _a_n _I_n_n_e_r _C_h_a_l_l_e_n_g_e In some cases, a proxy may need to challenge another proxy for specific pieces of information. This presents no additional problems since the inner proxies can challenge each other using the same sip- secure attachment. Suppose that Proxy P2 was at the border of another service provider for whom it wants to get authenticated caller ID information. Proxy P1 doesn't realize this initially, so it is chal- lenged by Proxy P2 to produce an attachment containing a digital sig- nature over the Caller-ID header. [XXX/mat: what is lacking here, and perhaps above, is more specificity within the attachment as to which headers are desired. Perhaps Accept or something like that can be enlisted here...] UAC P1 P2 UAS --------------------------------------------------------------- 1 INVITE----------------> 2 INVITE-------------> 3 <----------------401 4 INVITE-------------> 5 INVITE--------------> 6 <-----------------200 7 <-----------------200 8 <-0-----------------200 (1) UAC INVITE's UAS INVITE UAS@mtcc.com SIP/2.0 From: UAC@homer.com Caller-ID: "Krusty The Clown" (2) P1 forwards the INVITE to P2 (3) P2 rejects the request requiring that somebody in the previous Thomas draft-thomas-sip-sec-framework-00.txt [Page 30] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 realm supply a signature for Caller-ID. Note that the "*@homer.com" indicates that the proxy just wants anybody in that realm to vouch for the caller with an SMIME attachment. If the proxy doesn't intercept this, it could go back to UAC, in which case UAC could potentially produce a signed attachment. This is actually a feature as it may be desirable to catch the request at a boundary proxy, or let it go back clear to the UAC who must then prove that they are in possession of Krusty's signing key. 401 SIP/2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__FooTheFunLovingBar__" __FooTheFunLovingBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: P2@mtcc.com X-SIP-SECURE-TO: *@homer.com X-SIP-SECURE-SUPPORTS: SMIME.sec.sip.iana X-SIP-SECURE-METHOD: preshared.sec.sip.iana Authentication: NULL Encryption: NULL Accept: Caller-ID (4) P1 receives the rejection and adds a sip-secure attachment with a signature for the Caller-ID INVITE UAS@mtcc.com SIP/2.0 From: UAC@homer.com Caller-ID: "Krusty The Clown" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="__FooTheFunLovingBar__" __FooTheFunLovingBar__ Content-Type: message/sip-secure Content-Length: nnn X-SIP-SECURE-FROM: P1@homer.com X-SIP-SECURE-TO: P2@mtcc.com X-SIP-SECURE-METHOD: SMIME.sec.sip.iana # SMIME stuff Caller-ID: Bart Simpson Thomas draft-thomas-sip-sec-framework-00.txt [Page 31] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 (5) [XXX/mat: there's an interesting question as to how UAS knows which version to trust. I'm _assuming_ this has been addressed in the privacy draft. I'll take a shot at it here which is probably wrong...] Upon verification, P2 fixes up the real Caller-ID and forwards the request to UAS. INVITE UAS@mtcc.com SIP/2.0 From: UAC@homer.com Caller-ID: "Bart Simpson" X-Unverified-and-probably-bogus-Caller-ID: "Krusty the Clown" (6) UAS accepts the request and forwards the reply to P2. (7) P2 forwards the reply to P1 (8) P1 forwards the reply to UAC and the call completes. _6. _T_h_e _P_r_e-_s_h_a_r_e_d _K_e_y _C_r_y_p_t_o-_s_y_s_t_e_m [XXX/mat: this section should probably be moved to a different draft. I've left it here for the time being since it's a little bit easier to grok the concepts.] The pre-shared key crypto-system for SIP defines a means of using preshared keys between two SIP entites to exchange private and integrity checked attachments. A special case of the pre-shared key crypto-system allows a NULL transform to be used for either the encryption or authentication headers, or both. Absense of the Authen- tication and Encryption headers is equivalent to NULL transforms for both. The attachment is an extension of the sip-secure attachment and its general form is: Thomas draft-thomas-sip-sec-framework-00.txt [Page 32] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 +----------+ | | ~ ~ <--- Unencrypted, but integrity checked headers | | +----------+ | | | | ~ ~ <--- Optionally encrypted headers and body | | (also integrity checked) +----------+ Where there are a number of required headers which are sent in the clear, followed by an optionally encrypted area. The relevant headers for the SIP Pre-shared attachment crypto-system are: X-SIP-SECURE-TO X-SIP-SECURE-FROM These are standard headers for the sip-secure attachment. The pre-shared crypto-system places no additional require- ments on the format or content of these headers. X-SIP-SECURE-SUPPORTS X-SIP-SECURE-REQUIRES X-SIP-SECURE-METHOD With these headers, the method MUST be set to PRESHARED.sec.sip.iana to indicate that the preshared crypto-system is being used in this attachment. The realm tag refers to the key context and MAY be used to locate the proper key if the SIP realm specified in the X-SIP-SECURE- TO is ambiguous. The keying tag is not used, and MUST NOT be included. Content-Length If the Encyption or Authentication headers are present, the Content-Length header MUST be present. Otherwise, the Content-Length header SHOULD be present to facilitate fas- ter scanning of attachments. Authorization If the Authorization header is present, a keyed message integrity check will be generated using the authentication Thomas draft-thomas-sip-sec-framework-00.txt [Page 33] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 algorithm specified in the header. The area of the attach- ment that is integrity checked begins at the begining of the attachment (normally the character following the MIME boundary's linefeed) for Content-Length octets. TThe Pre-shared crypto-system provides replay protection by use of an absolute timestamp with a replay cache similar in nature to [KERBEROS]. The use of the replay protection is optional, though it SHOULD be implemented. Format: Authorization: algorithm; [time=timestamp:nonce;] checksum Where: Algorithm Algorithm is the IANA registered message integrity transform Time [XXX/mat: dig this out of 1510, or just reference it directly.] Time provides replay protection by providing an absolute timestamp of the current time in seconds from January 1st, 1970. Since clock skew should be assumed, a random nonce MUST be attached to the timestamp to facilitate lookup in the receivers replay cache. Generally, the replay cache is keyed off of the tuple (X-SIP-SECURE-TO, X-SIP-SECURE-FROM, nonce) where entries should be deleted after some amount of time, usu- ally several seconds. [...] Checksum Checksum is the base64 representation of the keyed hash producted by the above algorithm. Encryption If encryption is desired, this field will specify the encryption algorithm and mode that is used with the pre-shared key. The start of the encrypted area is the character following the linefeed at the end of the Encryption header, and continues until Content- Length minus the character position of that linefeed. Format: Encryption: algorithm Where: algorithm: the IANA registered [xxx where] encryption transform Thomas draft-thomas-sip-sec-framework-00.txt [Page 34] INTERNET-DRAFT SIP Security Framework 27 Jun 2001 to be used to encrypt/decrypt the rest of the attach- ment References [SIP] The SIP Working Group, M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999 [Kerberos]The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Net- work Authentication Service (V5)", RFC 1510, September 1993 [IPSEC] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [IKE] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998 Author's Address Michael Thomas Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA Tel: +1 408-525-5386 email: mat@cisco.com Thomas draft-thomas-sip-sec-framework-00.txt [Page 35]