Return-Path: rja@inet.org Received: from ha1.rdc1.sfba.home.net (ha1.rdc1.sfba.home.net [24.0.0.33]) by toad.com (8.7.5/8.7.3) with ESMTP id UAA04272 for ; Sun, 22 Sep 1996 20:44:04 -0700 (PDT) Received: from c8-a.snvl1.sfba.home.net ([24.1.16.12]) by ha1.rdc1.sfba.home.net (Netscape Mail Server v1.1) with SMTP id AAA27452 for ; Sun, 22 Sep 1996 20:44:03 -0700 Message-ID: <3245F9D4.1A10@inet.org> Date: Mon, 23 Sep 1996 03:45:40 +0100 From: Ran Atkinson Reply-To: rja1@home.net Organization: The Internet Guild X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: gnu@toad.com Subject: draft-ietf-sip-esp-00.txt Content-Type: text/plain; charset=us-ascii; name="sip-esp-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sip-esp-00.txt" Network Working Group Randall Atkinson Internet Draft Naval Research Laboratory draft-ietf-sip-esp-00.txt 20 December 1993 SIPP Encapsulating Security Payload (ESP) STATUS OF THIS MEMO This document is an Internet Draft. 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 6 months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". This particular Internet Draft is a product of the IETF's SIP Plus working group. It is intended that a future version of this draft be submitted to the IPng Area Directors and the IESG for possible publication as a standards-track protocol (as a part of the SIP Plus proposal for IPng). The author of this draft is keen on receiving feedback on this draft, particularly in places where the protocol specification might be unclear or incorrect. This syntax specified here is likely to change as prototype implementations progress. Discussion of this draft takes place on the SIPP Working Group mailing list: sipp@sunroof.eng.sun.com 1.0 INTRODUCTION This memo describes the SIPP Encapsulating Security Payload (ESP). ESP seeks to provide integrity, authentication, and confidentiality to SIPP datagrams. Non-repudiation and protection from traffic analysis are not provided by ESP. The SIPP Authentication Payload (AP) might provide non-repdiation if used with certain authentication algorithms. AP may be used in conjunction with ESP if desired. Users desiring integrity and authentication without confidentiality should use the SIP Plus Authentication Payload (AP) instead of ESP. This document assumes that the reader is familiar with the related Atkinson [Page 1] Internet Draft 20 December 1993 document "SIP Plus Security Architecture", which defines the overall security architecture for SIP Plus and provides important background for this specification. 1.1 OVERVIEW The SIPP Encapsulating Security Payload (ESP) seeks to provide security by encapsulating a SIPP datagram in a security payload and then encrypting most of that security payload, with all of the original SIPP datagram being included in the encrypted part of the security payload. This encapsulating approach is necessary to provide confidentiality for the entire original datagram, but can be very expensive to implement. Use of this specification will increase the SIPP protocol processing costs in participating end systems and will also increase the communications latency. The increased latency is primarily due to the encryption and decryption required for each SIPP datagram containing an Encapsulating Security Payload. In order for ESP to work properly without changing the entire Internet infrastructure (e.g. routers and non-participating systems), the original SIP Plus datagram is placed in the encrypted portion of the Encapsulating Security Payload and that ESP is placed within an datagram having unencrypted SIPP headers. The information in the unencrypted SIPP headers is used to route the secure datagram from origin to destination. An unencrypted SIPP Routing Header might be included between the SIPP Header and the Encapsulating Security Payload. The encapsulating security payload is structured a bit differently than other SIP Plus payloads. The first component of the ESP payload consist of the unencrypted field(s) of the payload. The second component consists of encrypted data. The field(s) of the unencrypted ESP header inform the intended receiver how to properly decrypt and process the encrypted data. The encrypted data component includes protected fields for the security protocol and also the encrypted encapsulated SIPP datagram. 2.0 KEY MANAGEMENT Key management is an important part of the SIP Plus security architecture. However, it is not included in this specification because of a long history in the public literature of subtle flaws in key management algorithms and protocols. SIP Plus tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security protocol is with the Security Association Identifier (SAID), which is described in more detail below. This decoupling permits several different key management mechanisms to be used. More Atkinson [Page 2] Internet Draft 20 December 1993 importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations. Thus, SIPP key management is specified in a separate (TBD) draft. [NB: It might be possible to reuse the Internet Key Management Protocol (IKMP) being developed in the IETF's IPv4 Security Working Group. However, that group has not been moving very rapidly.] The key management mechanism is used to negotiate a number of parameters for each security association, including not only the keys but other information (e.g. the cryptographic algorithms and modes) used by the communicating parties. The key management protocol implementation usually creates and maintains a table containing the several parameters for each current security association. An ESP implementation normally needs to read that security parameter table to determine how to process each datagram containing an ESP (e.g. which algorithm/mode and key to use). 3.0 ESP SYNTAX The Encapsulating Security Payload (ESP) may appear anywhere after the SIP Plus header. It consists of an unencrypted ESP header followed by encrypted data. The encrypted data includes both the protected ESP fields and the protected user data, which is either an entire SIP Plus datagram or an upper-layer protocol frame. A high- level diagram of a secure SIP Plus datagram follows. |<-- Unencrypted -->|<---------- Encrypted ------------------>| +-------------+----------+---------------------+------------------------+ | SIPP Header | Encapsulating Security Payload | encrypted payload | +-------------+----------+---------------------+------------------------+ 3.1 CLEARTEXT FIELDS The SIPP Header is the conventional SIPP Header defined by others in a separate Internet Draft. The ESP unencrypted field(s) are as follows: _S_E_C_U_R_I_T_Y _A_S_S_O_C_I_A_T_I_O_N _I_D_E_N_T_I_F_I_E_R (_S_A_I_D) A 32-bit value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x0000. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The receiving host uses the combination of SAID value and originating address to distinguish the correct association. Multicast groups may share a common SAID for all communications Atkinson [Page 3] Internet Draft 20 December 1993 if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, etc.). In this case, the receiver only knows that the message came from a member of the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each originating system in the multicast group. In this case, the originating system is fully authenticatable because each originating system is using a different security configuration. Each SAID value implies the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). _P_A_D_D_I_N_G _F_I_E_L_D This field is optional and its value is arbitrary. It might or might not be encrypted, depending on the cryptographic algorithm in use. Its presence and size or its absence is constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. The field can contain cryptographic synchronisation data and/or padding data for a block oriented encryption algorithm. [2] This also can be used to ensure word- alignment or double-word alignment of the payload. An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and the field's size and use if present. 3.2 ENCRYPTED FIELDS The ESP encrypted fields are as follows: _N_E_X_T _P_A_Y_L_O_A_D A single octet field indicating the next payload. The next payload is normally either an entire SIPP Datagram or an upper-layer (e.g. TCP or UDP) frame containing user data. _S_E_Q_U_E_N_C_E _N_U_M_B_E_R An optional 32-bit field used as an unsigned integer containing the packet sequence number of this packet for this Security Association Atkinson [Page 4] Internet Draft 20 December 1993 Identifier value. This field primarily exists to provide protection against replay attacks. [4] Some cryptographic algorithms intrinsically provide such protection and some users are not concerned about replay attacks, so this field is not mandatory. Its presence or absence is determined via the key management mechanism when the security association is created. The recipient(s) can use the Security Association Identifier (SAID) and originating address of a datagram to determine whether this field is present. _E_N_C_R_Y_P_T_E_D _S_I_P_P _D_A_T_A_G_R_A_M This is an encapsulated SIPP datagram, including the SIPP header, any other headers and payloads, and a payload containing upper-layer protocol data. The encapsulated SIPP datagram is encrypted along with the encrypted fields of the ESP rather than being encrypted separately. It is important that all routing headers and other data be included within the encrypted SIPP datagram, even if the same data is in the unencrypted part of the SIPP datagram. The receiving system shall ignore all routing information in the unencrypted portion of the received datagram and shall strictly rely on the routing information from the protected payload instead. If this rule is not strictly adhered to, then the system will be vulnerable to various kinds of attacks, including source routing attacks. The encrypted SIPP datagram may contain a SIPP Sensitivity Label (which is not yet defined) but the encrypted SIPP datagram need not include the SIPP Sensitivity Label because the SAID indicates the sensitivity label for the encrypted SIPP datagram. 4.0 PROTOCOL PROCESSING This section describes the steps taken when ESP is in use between two communicating parties. Multicast is different from unicast only in area of key management (see the definition of the SAID, above, for more detail on this). The sender takes the original SIPP datagram, encapsulates it into the ESP and then applies the encryption algorithm using the appropriate key for the receiving party. If no key has been established, then the key management mechanism is used to establish a encryption key for this communications session prior to the encryption. The (now encrypted) ESP is then encapsulated in a cleartext SIPP datagram as the last payload. If strict red/black separation is being enforced, then the addressing and other information in the cleartext SIPP headers and optional payloads might be different from the values contained in the (now encrypted and encapsulated) original datagram. The receiver strips off the cleartext SIPP header and cleartext Atkinson [Page 5] Internet Draft 20 December 1993 optional SIPP payloads (if any) and discards them. It then decrypts the ESP using the session key that has been established for this traffic. If no encryption key exists for this session, the encrypted ESP is discarded and the failure is audited, including the cleartext values for the SAID, date/time, Sending Address, Destination Address, and the Flow ID. The original SIPP datagram is then removed from the (now decrypted) ESP. This original SIPP datagram is then processed as per the normal SIPP protocol specification. 5.0 TYPICAL USE The ESP supports security between two or more hosts implementing ESP, between two or more gateways implementing ESP, and between a host or gateway implementing ESP and a set of hosts and/or gateways. A security gateway is a system which acts as the communications gateway between external untrusted systems and trusted hosts on their own subnetwork and provides security services for the trusted hosts when they communicate with external untrusted systems. A trusted subnetwork contains hosts and routers that trust each other not to engage in active or passive attacks and trust that the underlying communications channel (e.g. an Ethernet) isn't being attacked. In the case where a security gateway is providing services on behalf of a host on the trusted subnet, the security gateway is responsible for establishing the security association on behalf of its trusted host and for providing security services between the security gateway and the external system(s). In this case, only the gateway need implement ESP, while all of the systems behind the gateway on the trusted subnet may take advantage of ESP services between the gateway and external systems. A gateway which receives a datagram containing a recognised sensitivity label from a trusted host, it should take that label's value into account when creating/selecting an SAID for use with ESP between the gateway and the external destination. A gateway which receives a SIPP packet containing the ESP should appropriately label the decrypted packet that it forwards to the trusted host that is the ultimate destination. If there are no security gateways present in the connection, then two end systems that implement ESP can use it to only encrypt the user data (e.g. TCP or UDP) being carried between the two systems. ESP is designed to provide all this flexibility so that users may select and use only the security that they desire and need. Atkinson [Page 6] Internet Draft 20 December 1993 6.0 SECURITY CONSIDERATIONS This entire draft discusses a security mechanism for use with SIPP. This mechanism is not a panacea, but it does provide an important component useful in creating a secure internetwork. Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, upon the security of the key management mechanism and its implementation, and upon the correctness of the ESP and SIPP implementations in all of the participating systems. If any of these assumptions do not hold, then little or no real security will be provided to the user. Users seeking protection from traffic analysis might consider the use of appropriate link encryption. Description and specification of link encryption is outside the scope of this note. ACKNOWLEDGEMENTS Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol. [1, 2, 3, 4, 5] The use of DES for confidentiality is closely modeled on the work done for the SNMPv2. [6,7] Steve Bellovin, Steve Deering, and Dave Mihelcic provided useful critiques of earlier versions of this draft. REFERENCES [1] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, as published in NIST Publication NIST-IR-90-4250, February 1990. [2] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992. [3] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP Security Protocol", unpublished draft, 14 April 1993. [4] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio. [5] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992. Atkinson [Page 7] Internet Draft 20 December 1993 [6] Data Encryption Standard, ...FULL CITATION TBD... [7] James Galvin & Keith McCloghrie, Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC-1446, DDN Network Information Center, April 1993. [7] Randall Atkinson, SIPP Security Architecture, Internet Draft, draft-ietf-sip-sa-00.txt, 20 December 1993. [8] Randall Atkinson, SIPP Authentication Payload, Internet Draft, draft-ietf-sip-ap-00.txt, 20 December 1993. [9] SIP Plus, various Internet-Drafts of the SIPP Working Group of the Internet Engineering Task Force (work in progress). DISCLAIMER The views and specification here are those of the author and are not necessarily those of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work. The author and his employer specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification. AUTHOR INFORATION Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Atkinson [Page 8] Internet Draft 20 December 1993 APPENDIX A: Use of CBC-Mode DES with SIPP ESP This appendix describes the application of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm to the SIPP Encapsulating Security Payload. The secret key shared between the communicating parties is 16 octets, the first 8 of which are the DES key and the last 8 of which are the DES Initialisation Vector. The 8 octet (64 bit) DES key consists of a 56-bit quantity used by the DES algorithm and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. The length of the octet sequence to be encrypted by the DES algorithm must be an integral multiple of 8. When encrypting, the data should be padded at the end as necessary. The value of this trailing padding is arbitrary. When decrypting, the padding shall be ignored. If the length of the octet sequence to be decrypted is not an integral multiple of 8 octets, then processing shall be halted, the packet shall be discarded, and the event shall be audited. Atkinson [Page 9] Internet Draft 20 December 1993 APPENDIX B: Combining SIPP ESP using DES-CBC with SIPP AP using MD5 This appendix describes how to combine both the SIPP Encapsulating Security Protocol using CBC-mode DES with SIPP Authentication Payload using MD5. [ remainder TBD] Atkinson [Page 10]