new SIPP ESP draft

[Ran Atkinson <[e-mail]>]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 11

Here is the new draft.  I'll hold off putting it in the online I-D
directory until after the SIPP WG Mbone meeting in case of further
comments.  It will be submitted as an I-D soon after that.

There are several small changes, though the principles remain the same
as before.  In particular I'm reusing the Hop-by-Hop Option's padding
mechanism rather than inventing a new one (at the cost of limiting
the ESP to algorithms which have block sizes that are 8-bit aligned).

Ran
[e-mail]
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: sipp-esp.txt
X-Sun-Content-Lines: 563







Network Working Group                                   Randall Atkinson
Internet Draft                                  Naval Research Laboratory
draft-ietf-sipp-esp-01.txt                              24 February 1994




               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:
   [e-mail]

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 Header
   (AH) 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 SIPP Authentication Header (AH) instead of ESP.  This
   document assumes  that  the  reader  is  familiar  with  the  related



Atkinson                                                        [Page 1]

Internet Draft                                          24 February 1994


   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
   confidentiality  and integrity by encrypting data to be protected and
   placing  the  encrypted  data  in  the  data  portion  of  the   SIPP
   Encapsulating  Security  Payload.  Either a transport-layer (e.g. UDP
   or TCP) frame may be encrypted or an  entire  SIPP  datagram  may  be
   encrypted,  depending  on  the  user's  security  requirements.  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



Atkinson                                                        [Page 2]

Internet Draft                                          24 February 1994


   (SAID),  which  is  described  in more detail below.  This decoupling
   permits several different key management mechanisms to be used.  More
   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.



Atkinson                                                        [Page 3]

Internet Draft                                          24 February 1994


        Multicast groups may share a common SAID for all  communications
      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,
      if asymmetric algorithms are used, 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).

   _S_Y_N_C_H_R_O_N_I_S_A_T_I_O_N _F_I_E_L_D
        This field is optional  and  its  value  is  arbitrary.   It  is
      considered  to be plaintext, though most users will not be able to
      make sense of its contents.  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
      contains  cryptographic  synchronisation data for a block oriented
      encryption algorithm. [2] 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:

_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
   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



Atkinson                                                        [Page 4]

Internet Draft                                          24 February 1994


   the Security Association Identifier (SAID) and originating address of
   a  datagram  to  determine whether this field is present.  This field
   might be necessary to protect against replay attacks on  the  network
   infrastructure  (e.g.  ICMP  attacks)  or because of the algorithm in
   use.

_H_O_P-_B_Y-_H_O_P _H_E_A_D_E_R
     The normal SIPP Hop-by-Hop Option is always placed here to  provide
   a  clear  indication  of  what kind of data follows.  This header may
   also be used to provide the variable  length  padding  necessary  for
   some  encryption algorithms.  If the algorithm in use permits it, 64-
   bit alignment of this header is recommended. [9]

_E_N_C_R_Y_P_T_E_D _D_A_T_A
     This field  may  contain  an  entire  encapsulated  SIPP  datagram,
   including  the  SIPP header, a sequence of zero or more SIPP options,
   and a transport-layer payload, OR it may just be a sequence  of  zero
   or more SIPP options followed by a transport-layer payload.

     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 an explicit 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



Atkinson                                                        [Page 5]

Internet Draft                                          24 February 1994


   encapsulated) original datagram.

     The receiver strips off the cleartext  SIPP  header  and  cleartext
   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.  Note
   that trusted systems should be, but are not always, trustworthy.

     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.  The SIPP Authentication Header should always be used on
   packets  containing  explicit sensitivity labels to ensure end-to-end
   label integrity.

     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



Atkinson                                                        [Page 6]

Internet Draft                                          24 February 1994


   select and use only the security that they desire and need.

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.  Use of high assurance
   development techniques for the SIPP Encapsulating Security Payload is
   recommended.

     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.



Atkinson                                                        [Page 7]

Internet Draft                                          24 February 1994


   [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.

   [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-01.txt, 24 February 1994.

   [8]     Randall Atkinson, SIPP Authentication Header, Internet Draft,
           draft-ietf-sip-ap-01.txt, 24 February 1994.

   [9]     Steve Deering, SIPP Specification, Internet Draft,
           draft-ietf-sipp-spec-00.txt, 21 February 1994.

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 <[e-mail]>
   Information Technology Division
   Naval Research Laboratory
   Washington, DC 20375-5320
   USA
















Atkinson                                                        [Page 8]

Internet Draft                                          24 February 1994


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                                          24 February 1994


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]