MMUSIC Working Group Internet Draft M. Saito draft-saito-mmusic-sdes-ipsec-00 NTT Communications Expires: December 2006 June 2006 Security Descriptions Extension for IPsec Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 In this document, a method of exchanging IPsec key information based on security descriptions [sdesc] framework is defined. By making use of this method, it is possible to negotiate IPsec with the offer- answer model with SDP [RFC3264] in order to protect a media session. Necessary extensions to security descriptions are also defined. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction..................................................2 2. Applicability.................................................3 Saito Expires - December 2006 [Page 1] Security Descriptions Extension for IPsec June 2006 3. Definition of Extension.......................................3 3.1. Extension to Media Type..................................3 3.2. Extension to Crypto-suite................................4 3.3. Definition of Key-method.................................4 3.4. Extension to Key-info....................................4 4. Negotiation of IPsec SA.......................................6 4.1. Basic Mechanism..........................................6 4.2. Key Generation...........................................7 4.3. Security Policy for IPsec................................8 4.4. Rekeying.................................................8 4.5. About NAT Environment....................................8 5. Examples......................................................9 6. Grammar......................................................11 6.1. Generic "Crypto" Attribute Grammar......................11 6.2. IPsec Crypto Attribute Grammar..........................11 7. Comparison with IKE..........................................13 7.1. Comparison in Negotiation Phase.........................13 7.2. Comparison with IKE Quick Mode..........................13 8. Security Considerations......................................16 9. IANA Considerations..........................................16 9.1. IPsec Media Stream Transport............................16 9.2. IPsec Crypto Suite......................................17 10. References.................................................17 10.1. Normative References..................................17 10.2. Informative References................................18 1. Introduction When a SIP-based application uses general or dedicated media protocols, it is effective to apply IPsec as a security protocol for them. TLS [RFC2246] and DTLS [DTLS] are the other candidates for this use, but IPsec has the advantages that it can easily protect the several media transports in a lump and in addition the applications can omit the implementation of security protocol stacks. However described in the requirement document [ipsec-req], it is necessary to set up a lot of option parameters properly in order to establish IPsec Security Association (SA). And it requires technical knowledge even if using IKE, which does it automatically. On the other hand, there are several key exchange frameworks for SIP- based applications to protect their media sessions by SRTP, such as MIKEY/key-mgmt [RFC3830] [keymgt] and security descriptions. And then applications will be able to use IPsec easily by extending these frameworks so as to support the exchange of IPsec key information. As one of approaches for that, this document describes the extension for IPsec key exchange in the security descriptions framework. Saito Expires - December 2006 [Page 2] Security Descriptions Extension for IPsec June 2006 2. Applicability Similar to security descriptions, this specification that defines the extension to support IPsec, assumes cryptographic key distribution within the SDP message through the signaling which is protected by some methods. Key-mgmt provides similar cryptographic key distribution capabilities, but is intended for use when the signaling is to be confidential and/or integrity-protected separated from the keying material. 3. Definition of Extension It is necessary to extend the format and semantics of security descriptions framework in order to exchange IPsec key. This section defines the method to negotiate the parameters related to IPsec (i.e. IPsec SA) using "crypto" attribute. 3.1. Extension to Media Type In the spec of security descriptions, crypto-suite is defined depending on media stream transport. For example, AES_CM_128_HMAC_SHA1_80 is defined as a crypto-suite for SRTP. Media stream transport depends on the value of transport sub-field in "m=" field (ex. RTP/SAVP) defined in SDP [RFC2327]. In addition, when the initial offer includes one or more crypto attributes, the answer MUST accept one of them or reject the session. This means UA cannot fall-back to the non-secure session as a result of SRTP negotiation. Crypto attribute can be used only when the secure transport is offered in the "m=" field of SDP. As described above, crypto attribute and transport are closely related with each other so that it is necessary to define the new transports that indicate the binding with IPsec. As for the general UDP session or TCP connection, "UDP" [RFC2327] and "TCP" [RFC4145] are already defined as the values of media type field. Therefore in this document, the following media types are provided. ESP_TRANSPORT/UDP: UDP session encrypted by ESP transport mode AH_TRANSPORT/UDP: UDP session encrypted by AH transport mode ESP_TRANSPORT/TCP: TCP connection encrypted by ESP transport mode AH_TRANSPORT/TCP: TCP connection encrypted by AH transport mode ESP_TRANSPORT: Host-to-Host encryption by ESP transport mode AH_TRANSPORT: Host-to-Host encryption by AH transport mode When the above media type is specified in the offer/answer SDP, IPsec SAs that protect the corresponding UDP or TCP or Host-to-Host sessions MUST be also negotiated at the same time. If the negotiation Saito Expires - December 2006 [Page 3] Security Descriptions Extension for IPsec June 2006 of IPsec SAs is failed, also the negotiation of media sessions MUST be failed. When "ESP_TRANSPORT" or "AH_TRANSPORT" is specified as a media type, the port field in "m=" cannot have the meaningful value because IPsec does not protect only a specific port but all the traffic between nodes. In such a case, both offer SDP and answer SDP specify the value 9 (discard port) in the port field and each application MUST ignore this value. 3.2. Extension to Crypto-suite The above new media types substantially need the definition of two media stream transports, that is, transport mode ESP and transport mode AH. Therefore crypto-suite needs to be extended in order to support these two media stream transports. In this document, the following crypto-suites are defined. Crypto-suite | Encryption | Authentication for Transport Mode ESP | Algorithm | Algorithm ---------------------------------------------------------------- ESP_AES_CBC_128_HMAC_SHA1_96 | AES-CBC | HMAC-SHA-1-96 | (128 bits key) | [RFC2404] ESP_AES_CBC_128_HMAC_MD5_96 | AES-CBC | HMAC-MD5-96 | (128 bits key) | [RFC2403] ESP_3DES_CBC_HMAC_SHA1_96 | 3DES-CBC | HMAC-SHA-1-96 ESP_3DES_CBC_HMAC_MD5_96 | 3DES-CBC | HMAC-MD5-96 ESP_NULL_HMAC_SHA1_96 | NULL Encryption | HMAC-SHA1-96 ESP_NULL_HMAC_MD5_96 | NULL Encryption | HMAC-MD5-96 AH_HMAC_SHA1_96 | N/A | HMAC-SHA-1-96 AH_HMAC_MD5_96 | N/A | HMAC-MD5-96 3.3. Definition of Key-method In this specification, pre-existing key-method "inline" is used. When "inline" is used, actual keying material is included in the key-info field. 3.4. Extension to Key-info When the media types defined in 3.1 are used and key-method is "inline", key-info includes the following parameters. nonce: Parameter of keying material. The random number whose length is 128bits is generated and then base64 encoded. Saito Expires - December 2006 [Page 4] Security Descriptions Extension for IPsec June 2006 protocol: Protocol that will be protected by IPsec SA. As the value, "udp", "tcp", "icmp" and "any" are defined. offerer-address: Offerer's IP address used in IPsec SA. But it MUST be reachable from answerer. answerer-address: Answerer's IP address used in IPsec SA. But it MUST be reachable from offerer. offerer-spi: SPI (Security Parameter Index) of offerer's inbound IPsec SA. The value is in decimal. Offerer-spi MUST be decided by the offerer. answerer-spi: SPI of answerer's inbound IPsec SA. The value is in decimal. Answerer-spi MUST be decided by the answerer. offerer-life-type: The unit of life duration for offerer's inbound IPsec SA. The value is "sec" that represents second, or "kb" that represents kilobyte. offerer-life: Life duration of offerer's inbound IPsec SA. The value is in decimal. answerer-life-type: The unit of life duration for answerer's inbound IPsec SA. The value is "sec" that represents second, or "kb" that represents kilobyte. answerer-life: Life duration of answerer's inbound IPsec SA. The value is in decimal. offerer-port: In the case that "protocol" is "tcp" or "udp", offerer's local port number that should be separately protected by IPsec SA can be specified. The value is between 0 and 65535 in decimal, or "any". The value "0" and "any" have the same meaning. By the way, the media from the answerer MUST be able to reach the pair of offerer-address and offerer-port. answerer-port: In the case that "protocol" is "tcp" or "udp", answerer's local port number that should be separately protected by IPsec SA can be specified. The value is between 0 and 65535 in decimal, or "any". The value "0" and "any" have the same meaning. By the way, the Saito Expires - December 2006 [Page 5] Security Descriptions Extension for IPsec June 2006 media from the offerer MUST be able to reach the pair of answerer-address and answerer- port. These parameters appear in key-info in the following format. The details are defined in the chapter 5. "inline:" "|" "|" [offerer-address] ":" [answerer-address] "|" [offerer-spi] ":" ":" [":" [offerer-port] ":" [answerer-port] ] ":" [answerer-spi] ":" ":" [":" [offerer-port] ":" [answerer-port] ] The whole key-info includes all the parameters necessary for a pair of IPsec SAs (inbound IPsec SA and outbound IPsec SA). The parameters of the first, second and third fields separated by "|" are used in common to both inbound IPsec SA and outbound IPsec SA. On the other hand, the parameters of the fourth field are used for offerer's inbound IPsec SA, and those of the fifth field are used for offerer's outbound IPsec SA. 4. Negotiation of IPsec SA 4.1. Basic Mechanism The offer/answer example of IPsec SA negotiation using security descriptions is as follows. v=0 o=sam 2890844526 2890842807 IN IP4 192.168.0.1 s=sample c=IN IP4 192.168.0.1 t=2873397496 2873404696 m=application 49170 ESP_TRANSPORT/UDP sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1: |4321:sec:3600:49170:|:sec:3600:49170: a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1: |4321:sec:3600:49170:|:sec:3600:49170: In reply to the above offer SDP, the following answer SDP can be sent. v=0 o=jill 25690844 8070842634 IN IP4 172.16.0.1 s=sample c=IN IP4 172.16.0.1 t=2873397526 2873405696 Saito Expires - December 2006 [Page 6] Security Descriptions Extension for IPsec June 2006 m=application 32640 ESP_TRANSPORT/UDP sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:MTIzNDU2Nzg5MGFiY2RlZg==|udp|192.168.0.1:172.16.0.1 |4321:sec:3600:49170:32640|1234:sec:3600:49170:32640 In this example, the offerer sends two crypto attributes (two candidates of SA proposal) and the answerer accepts the first one. SA proposals of offer SDP are incomplete because the answerer's local IP address and port number are not decided at the time of generating offer SDP. Therefore the answerer MUST complete these SA proposals when generating answer SDP. When key-method is "inline", offer SDP MUST include the values of nonce, protocol, offerer-address, offerer-spi, offerer-life and answer-life fields. And if "udp" or "tcp" is specified in the protocol field, offer SDP MAY specify the values of the first and second offerer-port fields (If they are omitted, it means the same as "any" is specified). If the offerer knows the IP address and service port of the answerer by some means or other in advance, offer SDP MAY include the values of answerer-address and the first and second answerer-port fields. However, offer SDP MUST NOT include the value of answerer-spi field. In the answer SDP, all the values of all the fields except for the nonce field MUST NOT be changed from those of the offer SDP. But the field whose value is omitted in the offer SDP MUST be filled up in the answer SDP. In nonce field, the answerer MUST specify the random value the answerer newly generates. On the other hand, when the offerer omits the offerer-port field itself, the answerer MUST NOT add the offerer-port and answerer-port fields. 4.2. Key Generation As a result of offer/answer SDP exchange, both offerer and answerer can generate the shared secret for IPsec SA. The method to generate the secret key is defined in this section, but the following notation is used throughout this section. | indicates concatenation of information. For example, X|Y means the concatenation of X with Y. [x] indicates that x is optional. prf(key,msg) indicates the keyed pseudo-random function. When key-method is "inline", the keying material KMAT is generated for each IPsec SA as follows. KMAT = K1|K2|K3|... K1 = prf(offer-nonce|answer-nonce, crypto-suite|spi|offer-nonce|answer-nonce) K2 = prf(offer-nonce|answer-nonce, Saito Expires - December 2006 [Page 7] Security Descriptions Extension for IPsec June 2006 K1|crypto-suite|spi|offer-nonce|answer-nonce) K3 = prf(offer-nonce|answer-nonce, K2|crypto-suite|spi|offer-nonce|answer-nonce) ... If the authentication algorithm specified in the crypto-suite is HMAC-SHA1-96, HMAC-SHA1 (output is 160 bits) is used for prf. If it is HMAC-MD5-96, HMAC-MD5 (output is 128 bits) is used for prf. Offer- nonce means the value of nonce field included in offer SDP. Answer- nonce means the value of nonce field included in answer SDP. Spi means the SPI value (32 bits binary data) of the IPsec SA. And crypto-suite means the value (in ASCII code) of crypto-suite field defined in crypto attribute. The encryption key for IPsec SA is cut out from the head of KMAT for the necessary length for its encryption algorithm. The authentication key for IPsec SA is cut out from the next bit of that for the necessary length for its authentication algorithm. For example, if the crypto-suite is ESP_AES_CBC_128_HMAC_SHA1_96, the first 128 bits of KMAT is used for the encryption key of ESP and the following 160 bits is used for the authentication key of HMAC-SHA1. In the case of NULL encryption or AH, only the authentication key is cut out from the head of KMAT. 4.3. Security Policy for IPsec IPsec SAs can be generated by using offer/answer negotiation in this document, but at the same time both the offerer and the answerer MUST install the proper security policy for IPsec dynamically in themselves. The method to install security policy is outside the scope of this document. 4.4. Rekeying Because IPsec SA has its life time, it MUST be refreshed sufficiently before it expires. The simplest way is negotiating IPsec SA again by generating re-INVITE. A user agent that supports session timers [RFC4028] MAY set the life duration of IPsec SA equal to the session timer, and refresh the IPsec SA synchronously with the session refresh. 4.5. About NAT Environment As defined in 3.4, IP address and port information exchanged in key- info MUST be reachable from the other peer. Even in NAT environment, such information can be acquired by making use of the framework such as ICE [ICE]. Of course, it is also necessary to implement UDP encapsulation [RFC3948] and so on, in order to traverse NAT. However the solution for IPsec NAT traversal itself depends on the method of Saito Expires - December 2006 [Page 8] Security Descriptions Extension for IPsec June 2006 NAT traversal of media (for example, the method using L2TP [RFC3931] can also be thought), therefore the solution in NAT environment is outside the scope of this document. 5. Examples In this chapter, several examples of offer/answer SDP based on this specification are illustrated. The simplest example is protecting all the IP packets between two hosts, that is, Host-to-Host encryption. The example of negotiating IPsec SAs that cover all the IP packets between the offerer and the answerer is as follows. offer SDP v=0 o=sam 2890844526 2890842807 IN IP4 192.168.0.1 s=sample c=IN IP4 192.168.0.1 t=2873397496 2873404696 m=application 9 ESP_TRANSPORT sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|any|192.168.0.1: |4321:sec:3600|:sec:3600 a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|any|192.168.0.1: |4321:sec:3600|:sec:3600 answer SDP v=0 o=jill 25690844 8070842634 IN IP4 172.16.0.1 s=sample c=IN IP4 172.16.0.1 t=2873397526 2873405696 m=application 9 ESP_TRANSPORT sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:MTIzNDU2Nzg5MGFiY2RlZg==|any|192.168.0.1:172.16.0.1 |4321:sec:3600|1234:sec:3600 In this case, both offer SDP and answer SDP specify the value 9 (discard port) in the port field in "m=", but it is ignored at the application layer. The following example shows the situation that the offerer accepts UDP datagram from the answerer at the UDP port 7000, and the answerer accepts UDP datagram from the offerer at the UDP port 8000. In order to protect these media stream, two IPsec SAs are negotiated. The former has the selector that the source port of the answerer is "any" and the destination port of the offerer is 7000. The latter has the Saito Expires - December 2006 [Page 9] Security Descriptions Extension for IPsec June 2006 selector that the source port of the offerer is "any" and the destination port of the answerer is 8000. offer SDP v=0 o=sam 2890844526 2890842807 IN IP4 192.168.0.1 s=sample c=IN IP4 192.168.0.1 t=2873397496 2873404696 m=application 7000 ESP_TRANSPORT/UDP sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1: |4321:sec:3600:7000:|:sec:3600:any: a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|udp|192.168.0.1: |4321:sec:3600:7000:|:sec:3600:any: answer SDP v=0 o=jill 25690844 8070842634 IN IP4 172.16.0.1 s=sample c=IN IP4 172.16.0.1 t=2873397526 2873405696 m=application 8000 ESP_TRANSPORT/UDP sample-appl a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:MTIzNDU2Nzg5MGFiY2RlZg==|udp|192.168.0.1:172.16.0.1 |4321:sec:3600:7000:any|1234:sec:3600:any:8000 And the following example shows the case that the offerer is a TCP client and the answerer is a TCP server that accepts the TCP connection at the port 8000. In order to protect this TCP connection, two IPsec SAs are negotiated. The former has the selector that the source port of the answerer is 8000 and the destination port of the offerer is "any". The latter has the selector that the source port of the offerer is "any" and the destination port of the answerer is 8000. offer SDP v=0 o=sam 2890844526 2890842807 IN IP4 192.168.0.1 s=sample c=IN IP4 192.168.0.1 t=2873397496 2873404696 m=application 9 ESP_TRANSPORT/TCP sample-appl a=setup:active a=connection:new a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|tcp|192.168.0.1: |4321:sec:3600:any:|:sec:3600:any: Saito Expires - December 2006 [Page 10] Security Descriptions Extension for IPsec June 2006 a=crypto:2 ESP_AES_CBC_128_HMAC_MD5_96 inline:ZmRrZWxzO3c5bHN1Zm9wZQ==|tcp|192.168.0.1: |4321:sec:3600:any:|:sec:3600:any: answer SDP v=0 o=jill 25690844 8070842634 IN IP4 172.16.0.1 s=sample c=IN IP4 172.16.0.1 t=2873397526 2873405696 m=application 8000 ESP_TRANSPORT/TCP sample-appl a=setup:passive a=connection:new a=crypto:1 ESP_AES_CBC_128_HMAC_SHA1_96 inline:MTIzNDU2Nzg5MGFiY2RlZg==|tcp|192.168.0.1:172.16.0.1 |4321:sec:3600:any:8000|1234:sec:3600:any:8000 6. Grammar In this chapter the ABNF grammar for this specification is defined. 6.1. Generic "Crypto" Attribute Grammar In the section 9.1 of [sdes], the following definition is provided as the generic "crypto" attribute grammar. "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params *(1*WSP session-param) tag = 1*9DIGIT crypto-suite = 1*(ALPHA / DIGIT / "_") key-params = key-param *(";" key-param) key-param = key-method ":" key-info key-method = "inline" / key-method-ext key-method-ext = 1*(ALPHA / DIGIT / "_") key-info = %x21-3A / %x3C-7E ; visible (printing) characters ; except semi-colon session-param = 1*(VCHAR) ; visible (printing) characters where WSP, ALPHA, DIGIT and VCHAR are defined in [RFC2234]. 6.2. IPsec Crypto Attribute Grammar The definition of ABNF grammar for the IPsec specific crypto attribute is provided as follows. crypto-suite = ipsec-crypto-suite key-method = ipsec-key-method Saito Expires - December 2006 [Page 11] Security Descriptions Extension for IPsec June 2006 key-info = ipsec-key-info session-param = ipsec-session-param ipsec-crypto-suite = "ESP_AES_CBC_128_HMAC_SHA1_96" / "ESP_AES_CBC_128_HMAC_MD5_96" / "ESP_3DES_CBC_HMAC_SHA1_96" / "ESP_3DES_CBC_HMAC_MD5_96" / "ESP_NULL_HMAC_SHA1_96" / "ESP_NULL_HMAC_MD5_96" / "AH_HMAC_SHA1_96" / "AH_HMAC_MD5_96" ipsec-crypto-suite-ext ipsec-key-method = "inline" ipsec-key-info = nonce "|" protocol "|" [offerer-address] ":" [answerer-address] "|" [offerer-spi] ":" offerer-life-type ":" offerer-life [":" [offerer-port] ":" [answerer-port] ] "|" [answerer-spi] ":" answerer-life-type ":" answerer-life [":" [offerer-port] ":" [answerer-port] ] nonce = 1*(base64) ; base64 encoded binary nonce ; value [RFC3548] protocol = "tcp" / "udp" / "icmp" / "any" / protocol-ext offerer-address = IP-address answerer-address = IP-address offerer-spi = spi-value answerer-spi = spi-value offerer-life-type = life-type-value answerer-life-type = life-type-value offerer-life = life-value answerer-life = life-value offerer-port = port-value answerer-port = port-value IP-address = IP4-address | IP6-address IP4-address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IP6-address = hexpart [ ":" IP4-address] Saito Expires - December 2006 [Page 12] Security Descriptions Extension for IPsec June 2006 hexpart = hexseq / hexseq "::" [hexseq] / "::" [hexseq] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG spi-value = 1*10DIGIT life-type-value = "sec" / "kb" / life-type-value-ext life-value = 1*DIGIT port-value = 1*5DIGIT / "any" ipsec-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") protocol-ext = 1*(ALPHA / DIGIT / "_") life-type-value-ext = 1*(ALPHA / DIGIT / "_") base64 = ALPHA / DIGIT / "+" / "/" / "=" ipsec-session-param = ipsec-session-ext ipsec-session-ext = ["-"] 1*(VCHAR) ; visible chars[RFC2234] ; first character must ; not be dash ("-") 7. Comparison with IKE For reference, this section describes the comparison with IKE [RFC2409] which is widespread as the key-exchange protocol for IPsec. 7.1. Comparison in Negotiation Phase In the specification of ISAKMP [RFC2408], two negotiation phases to establish SA are defined. In the first phase, ISAKMP SA which protects the following negotiation traffic is established, and in the second phase, SA for the security protocol is established. However, it is allowed to skip the initial ISAKMP exchange and establish an SA directly if a basic set of security attributes is already in place between the negotiating nodes. The specification in this document assumes the SDP messages are protected (by S/MIME and so on), therefore it can be compared to just the SA negotiation in IKE phase 2 skipping the first ISAKMP exchange. 7.2. Comparison with IKE Quick Mode The message flow of IKE phase 2 quick mode is as follows. Saito Expires - December 2006 [Page 13] Security Descriptions Extension for IPsec June 2006 Initiator Responder HDR, HASH(1), SA, Ni, [, KE] [, IDci, IDcr] --> HDR, HASH(2), SA, Nr, <-- [, KE] [, IDci, IDcr] HDR, HASH(3) --> HDR: ISAKMP header. Only this header in the above parameters is exchanged in plain text. HASH: Hash payload. SA: SA negotiation payload with one or more proposals. Ni, Nr: Initiator nonce payload and responder nonce payload. KE: Key exchange payload. IDci, IDcr: Initiator identification payload and responder identification payload. In the case of IKE, a single ISAKMP SA can include several different quick modes (they are distinguished by Message ID), but in the case of security descriptions, a key exchange process cannot have multiple sessions because that process is bound to an offer/answer model with SDP [RFC3264], which prescribes a single SDP cannot have multiple sessions. Hash payload in the IKE quick mode is used for message integrity and anti-replay attack based on the authentication key generated in the phase 1. But in security descriptions, it is assumed that AKE is provided at least to SDP, therefore a mechanism corresponding to hash payload is not necessary. SA proposal part in the IKE quick mode negotiates the following parameters. o DOI, Situation (SA payload) o protocol ID of the security protocol, SPI (proposal payload) o SA attributes (transform payload) Parameters that can be negotiated in SA attributes are 9 classes defined in 4.5 of [RFC2407], and all ISAKMP implementations MUST be prepared to negotiate the following parameters among them to ensure basic interoperability. o SA Life Type (the unit of life duration for SA: seconds, kilobytes) o Auth Algorithm (the authentication algorithm attribute) Saito Expires - December 2006 [Page 14] Security Descriptions Extension for IPsec June 2006 DOI and Situation are not exchanged in the security descriptions. The parameters corresponding to protocol ID of the security protocol are provided in the media type field (3.1) and in the crypto-suite field (3.2). In addition, the value of crypto-suite includes Auth Algorithm because crypto-suite is defined as the set of encryption algorithm and authentication algorithm. In the case of IKE, it is possible to offer multiple SA attributes, which are listed in the priority order. And it is also possible in the case of security descriptions by listing "a=crypto" attributes in the priority order. By the way, there is a default value of 28800 seconds for SA Duration in IKE, but life-type and life must be negotiated in security descriptions. A parameter in the security descriptions corresponding to nonce payload in the IKE quick mode is "nonce" defined in 3.4. KE payload in the IKE quick mode is optional and used to provide PFS (Perfect Forward Secrecy). In order to provide PFS in security descriptions, there is a framework of Diffie-Hellman exchange [sdp- dh], therefore this document does not specify the parameter corresponding to KE payload. Identification payload in the IKE quick mode makes it possible to exchange ID information of each node (if omitted, IP address of the node is used). Security descriptions provide the similar function by inserting the information about IP address, transport protocol and port into the key-info field. However it does not support the information such as hostname, username, subnet, address range, and certificate supported by IKE. By the way, a method to calculate the keying material in the IKE quick mode that does not have KE payload is as follows. KEYMAT = prf(SKEYID_d, protocol | protocol | SPI | Ni_b | Nr_b) SKEYID_d: keying material generated in the IKE phase 1 protocol: protocol ID (1 byte) included in proposal payload SPI: SPI (4 bytes) included in proposal payload Ni_b: random value in initiator's nonce payload Nr_b: random value in responder's nonce payload And if the length of KEYMAT is not sufficiently long, it is extended by the following caluculation. KEYMAT = K1 | K2 | K3 | ... K1 = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b) K2 = prf(SKEYID_d, K1 | protocol | SPI | Ni_b | Nr_b) K3 = prf(SKEYID_d, K2 | protocol | SPI | Ni_b | Nr_b) Saito Expires - December 2006 [Page 15] Security Descriptions Extension for IPsec June 2006 As a result, the components of KEYMAT in IKE are the keying material generated in phase 1, protocol, SPI, initiator's nonce and responder's nonce, which are negotiated in phase 2. KEYMAT in the security descriptions is calculated as described in 4.2. Because there is no process corresponding to the IKE phase 1 in the security descriptions, the parameter corresponding to SKEYID_d does not exist, therefore the concatenation of offer-nonce and answer-nonce is used instead. In addition, crypto-suite is used instead of protocol ID parameter in IKE. The other components are the same as IKE. 8. Security Considerations When using security descriptions framework for IPsec keying, the following properties must be considered. o overlap of IPsec SAs belonging to multiple INVITE sessions Although it depends on the implementations, if there are multiple pairs of IPsec SA belonging to multiple INVITE sessions and their selectors overlap to each other, all the media sessions may be protected by only a pair of IPsec SA. Therefore, implementations are required to verify that any IPsec SAs that can be used do not use a vulnerable algorithm. o Security of SDP message Security descriptions framework itself does not provide a specific mechanism to protect SDP messages. Therefore, the security of SDP message relies on the security protocol that applications use (e.g., S/MIME, or a lower-layer security service such as TLS and IPsec). If using the keying mechanism defined in this document, SDP messages must be protected with regard to replay protection, message authentication, and message confidentiality. 9. IANA Considerations IANA is requested to register new parameters related to Security Descriptions extension for IPsec. The following sub-sections define all of them based on the SDP Security Descriptions registry. 9.1. IPsec Media Stream Transport IANA is requested to register new SDP Security Descriptions Media Stream Transports named "ESP_TRANSPORT/UDP", "AH_TRANSPORT/UDP", "ESP_TRANSPORT/TCP", "AH_TRANSPORT/TCP", "ESP_TRANSPORT" and "AH_TRANSPORT". All of them represent transport mode ESP/AH, and the key method supported is "inline". Saito Expires - December 2006 [Page 16] Security Descriptions Extension for IPsec June 2006 9.2. IPsec Crypto Suite IANA is requested to create a new sub-registry for IPsec crypto suites under the IPsec transport of the SDP Security Descriptions. IANA IPsec crypto suite registration MUST indicate the crypto suite name in accordance with the grammar for ipsec-crypto-suite-ext defined in 6.2. The following IPsec crypto suites are hereby registered: ESP_AES_CBC_128_HMAC_SHA1_96 ESP_AES_CBC_128_HMAC_MD5_96 ESP_3DES_CBC_HMAC_SHA1_96 ESP_3DES_CBC_HMAC_MD5_96 ESP_NULL_HMAC_SHA1_96 ESP_NULL_HMAC_MD5_96 AH_HMAC_SHA1_96 AH_HMAC_MD5_96 10. References 10.1. Normative References [sdesc] Andreasen, F., Baugher, M., and D. Wing, "SDP Security Descriptions for Media Streams", work in progress, September 2005. [RFC3264] Rosenberg, J., and Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] M. H andley, and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC4145] D. Yon, and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC2404] C. Madson, and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2403] C. Madson, and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. Saito Expires - December 2006 [Page 17] Security Descriptions Extension for IPsec June 2006 [RFC4028] S. Donovan, and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC2234] D. Crocker, Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3548] S. Josefsson, Ed., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. 10.2. Informative References [RFC2246] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999. [DTLS] E. Rescorla, and N. Modadugu, "Datagram Transport Layer Security", work in progress, June 2004. [ipsec-req] M. Saito, and S. Fujimoto, "Requirements for IPsec Negotiation in the SIP Framework", work in progress, March 2006. [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "Key Management Extensions for SDP and RTSP", work in progress, June 2005. [ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", work in progress, March 2006. [RFC3948] A. Huttunen, B. Swander, V. Volpe, L. DiBurro, and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC3931] J. Lau, Ed., M. Townsley, Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC2409] D. Harkins, and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2408] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. Saito Expires - December 2006 [Page 18] Security Descriptions Extension for IPsec June 2006 [RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [sdp-dh] M. Baugher, and D. McGrew, "Diffie-Hellman Exchanges for Multimedia Sessions", work in progress, February 2006. Saito Expires - December 2006 [Page 19] Security Descriptions Extension for IPsec June 2006 Acknowledgements The concepts of this document were discussed in the UOPF: Ubiquitous Open Platform Forum (http://www.uopf.org/en/), which is participated by many ISPs and information appliances makers and so on. The author would like to thank the UOPF members and those who contributed to this document. And the author would also like to thank Mark Baugher and Shingo Fujimoto for their suggestions and review. Author's Address Makoto Saito NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Phone: +81-3-6800-3262 Email: ma.saito@nttv6.jp Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Saito Expires - December 2006 [Page 20] Security Descriptions Extension for IPsec June 2006 Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Saito Expires - December 2006 [Page 21]