Network Working Group                                            B. Weis
Internet-Draft                                                C. Appanna
Intended status: Standards Track                               D. McGrew
Expires: April 20, 2008                                       A. Ramaiah
                                                           Cisco Systems
                                                        October 18, 2007


 Automated key selection extension for the TCP Enhanced Authentication
                                 Option
                     draft-weis-tcp-auth-auto-ks-03

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.

   This Internet-Draft will expire on April 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Weis, et al.             Expires April 20, 2008                 [Page 1]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


Abstract

   This memo describes an automated key selection extension for the TCP
   [RFC0793] authentication option [I-D.bonica-tcp-auth].  This key
   selection extension allows two TCP endpoints to authenticate TCP
   segments using a Message Authentication Code (MAC) key chosen
   dynamically by an endpoint, rather than using a pre-configured MAC
   key.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Automatic Key Selection Process  . . . . . . . . . . . . . . .  6
     2.1.  KEK Requirements . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  MAC Key Generation . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Sender Operations  . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Receiver Operations  . . . . . . . . . . . . . . . . . . .  7
     2.5.  Authentication Data Format . . . . . . . . . . . . . . . .  8
       2.5.1.  KEK Algorithm ID Types . . . . . . . . . . . . . . . .  9

   3.  MAC Algorithms using Nonces  . . . . . . . . . . . . . . . . . 10
     3.1.  Authentication Data Format . . . . . . . . . . . . . . . . 10
     3.2.  MAC Algorithm ID Types . . . . . . . . . . . . . . . . . . 11

   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  MAC Option Size  . . . . . . . . . . . . . . . . . . . . . 12
       4.1.1.  Authentication Data Only . . . . . . . . . . . . . . . 12
       4.1.2.  Adding an Encrypted Key  . . . . . . . . . . . . . . . 12
     4.2.  Use of the TCP Sequence Number as a MAC Algorithm Nonce  . 13
     4.3.  Retention of automatically generated keys  . . . . . . . . 14
     4.4.  TCP sequence number wrapping . . . . . . . . . . . . . . . 14

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 17

   Appendix A.  Rejected Alternatives . . . . . . . . . . . . . . . . 19
     A.1.  Deriving session keys from a master key  . . . . . . . . . 19
     A.2.  Deriving session keys using the Diffie-Hellman
           algorithm  . . . . . . . . . . . . . . . . . . . . . . . . 19



Weis, et al.             Expires April 20, 2008                 [Page 2]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

















































Weis, et al.             Expires April 20, 2008                 [Page 3]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


1.  Introduction

   The TCP Enhanced Authentication Option [I-D.bonica-tcp-auth]
   specifies a means of providing integrity protection to BGP and other
   TCP-based routing protocols.  It does this by applying a Message
   Authentication Code (MAC) to the TCP pseudo-header, TCP header, and
   TCP segment data (if any).  Several allowed MAC algorithms are
   defined.

   MAC algorithms take as input a secret key known to the two TCP
   endpoints, called a MAC key.  The TCP Enhanced Authentication Option
   describes a means of organizing MAC keys in a "key set" associated
   with a peer TCP endpoint.  These keys are chosen out of band, and
   manually entered into the configuration of the TCP endpoints.

   This memo describes a means by which TCP endpoints choose MAC keys
   using an automated process, and is a more secure and operationally
   simpler method of key selection.  The automatically generated keys
   are protected during transmission by a long-lived key encryption key
   (KEK) shared between the TCP endpoints.

   This memo also specifies additional strong MAC algorithms that use
   unique nonces for each TCP segment.  This is important because at
   present the best-performing MACs all have this requirement.  MAC
   algorithms using nonces are only safe to use with an automatic key
   selection process.  This is because an automatic key selection
   process can quickly and securely react to the condition that a non-
   unique nonce is about to be used.

   Several alternative methods for automatically providing keys for the
   TCP Enhanced Authentication Option were considered and rejected.
   These methods and the rejection rationale are described in Appendix A
   of this document.

1.1.  Requirements notation

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

1.2.  Terminology

   Key Encrypting Key (KEK).   A key used with a cryptographic algorithm
      to encrypt another key.







Weis, et al.             Expires April 20, 2008                 [Page 4]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   Message Authentication Code (MAC).   A keyed cryptographic integrity
      function computed on data using a secret key to detect
      modifications of the data (e.g., a TCP segment).  An attacker who
      does not know the secret key is unable to generate the MAC
      corresponding to a particular message, or to modify the message in
      an undetectable fashion, with very high probability.  This is true
      even if the attacker can perform a chosen-message attack, and
      cause a legitimate user of the system to authenticate messages of
      its choice.

   Message Authentication Code Key (MAC Key).   A key used to
      authenticate a TCP segment.







































Weis, et al.             Expires April 20, 2008                 [Page 5]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


2.  Automatic Key Selection Process

   This memo specifies a method for a TCP endpoint to automatically
   generate a TCP Enhanced Authentication Option MAC key and pass it to
   a peer in-band.  The MAC key is passed in the TCP Enhanced
   Authentication Option encrypted under a Key Encrypting Key (KEK)
   known to both TCP end-points.  When an encrypted key is included in
   this TCP option, it is used to authenticate the current segment, and
   all subsequent segments in the TCP exchange until a new key is chosen
   by either of the TCP end-points.  Key encryption algorithms and modes
   used with the KEK MUST be strong enough so that in-line transmission
   of the key does not degrade the security offered by the MAC
   algorithm.  One strong KEK algorithm is described below.

   Two TCP end-points configure one or more KEKs before the in-band key
   selection method is used.  A KEK is never used directly as a MAC key
   because using a cryptographic key for multiple purposes (such as a
   KEK and a MAC key) may cause a cryptographic vulnerability and weaken
   the key.  A KEK typically has a long lifetime.

   When the automated key selection method is used, MAC keys are
   generated as needed using a strong random number generator.  The KEK
   is used to encrypt the MAC key, and the resulting ciphertext is then
   included in the Encrypted Key portion of the TCP Enhanced
   Authentication Option.  This approach allows for a scheduled
   automatic generation of keys that can be periodically replaced based
   on the policy of either TCP.  Generating and distributing a MAC key
   requires no operator intervention on either TCP endpoint.

2.1.  KEK Requirements

   Before the extension in this memo can be used, both TCP endpoints
   must have obtained a KEK.  The KEK is exchanged using an out-of-band
   process (e.g., manual configuration or using a separate protocol),
   which is not discussed in this memo.  A TCP endpoint MAY exchange
   more than one KEK with a particular peer TCP endpoint for the purpose
   of automatic KEK rollover.  However, any such rollover process is
   outside the scope of this memo.  One possible method is described in
   [I-D.viswanathan-keyrollover].

   The use of pair-wise automatically generated MAC Keys is especially
   powerful, because each side can choose independently when to begin
   using a new MAC Key for its outbound segments without requiring the
   peer to coordinate the MAC key rollover event.







Weis, et al.             Expires April 20, 2008                 [Page 6]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


2.2.  MAC Key Generation

   The TCP Enhanced Authentication Option defines a set of attributes
   for each MAC key.  When this extension is used, the attributes are
   set as follows:

   o  key identifier i, chosen according to local policy

   o  Authentication algorithm L[i], chosen according to local policy

   o  Shared secret S[i] generated using a strong random number
      generator

   o  A[i], set according to whether the key is the active key

   o  E[i], set according to whether the key is an eligible key

2.3.  Sender Operations

   A TCP Endpoint choosing a new MAC Key uses the following step:

   o  Generates a MAC Key of the appropriate length using a strong
      random number generator.  A random number generator approved for
      NIST PUB 140-2 [FIPS.140-2.AnnexC] SHOULD be used.

   o  Places the MAC Key into the key set as described above.  The Key
      ID i is set to a Key Id value currently unused in the key set.
      L[i] is set to a chosen authentication algorithm.

   o  Creates a TCP Enhanced Authentication Option with the K bit set to
      1, the Alg ID set to A[i], and the Key ID set to i.

   o  Adds an Authentication Data formed as described below.

   When a TCP end-point sends a new key, it SHOULD leave the previous
   key in the key set and marked as Eligible until the peer also begins
   to encrypt using the new key.  Doing so allows a continued receipt of
   TCP segments from the peer, including acknowledgment messages
   indicating that the segment with the new MAC key was not received.

2.4.  Receiver Operations

   A TCP Endpoint receiving a new MAC Key uses the following steps:

   o  Detects that the packet includes an encrypted MAC Key by observing
      that the K bit is set.





Weis, et al.             Expires April 20, 2008                 [Page 7]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   o  Extracts the new MAC Key by decrypting it with the KEK and
      verifying that the decrypted key is well formed (i.e., the KEK
      Algorithm ID is a known algorithm id, and the Reserved bits are
      set to zero).

   o  Verifies that the MAC Key was used to authenticate the packet.

   o  Places the MAC Key into its key set as described above.  A[i] is
      set to be the authentication algorithm defined in the In-line
      Encrypted Key Payload.  The Key ID i is set to the Key Id value
      defined in the In-line Encrypted Key Payload.

2.5.  Authentication Data Format

   The TCP Enhanced Authentication Option defines an Authentication Data
   field, which always contains at least a Message Authentication Code.
   When the automated key selection option is used, the Authentication
   Data field includes both the MAC and an In-line Encrypted Key
   Payload, as shown in the following figure.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Message Authentication Code                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 In-line Encrypted Key Payload                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Authentication Code field contains the output of the MAC
   algorithm.  Its size is deterministic based on MAC algorithm.  The
   In-line Encrypted Key Payload is constructed as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res|KEK Alg ID |Res|KEK Key ID |    Encrypted Key              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Res (2 bits) -- Reserved bits, set to zero.

   o  KEK Alg ID (6 bits) -- This field contains an algorithm identifier
      to be used with the key encrypting key.

   o  Res (2 bits) -- Reserved bits, set to zero.

   o  KEK Key ID (6 bits) -- This field contains an algorithm type to be
      used with the key encrypting key.




Weis, et al.             Expires April 20, 2008                 [Page 8]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   o  Encrypted Key (variable).  The size of the encrypted key field
      depends upon the size of the encrypted key (see below).

2.5.1.  KEK Algorithm ID Types

   The MAC algorithms described in [I-D.bonica-tcp-auth] and this memo
   all use a key of 128-bits or smaller.  The following algorithm is
   suitable to be used as a key encrypting key for these key sizes:

   o  AES-128-ECB.  The MAC key is encrypted using an AES 128-bit key
      encrypting key, resulting in a 128-bit encrypted key.  Use of ECB
      mode is acceptable because only one block is being encrypted.
      This algorithm MUST NOT be used to encrypt a MAC key larger than
      128 bits.

   If a MAC algorithm requiring a key of larger than 128 bits is defined
   for use with this automated key selection extension, then a different
   key encrypting key algorithm will be required.  Two possible methods
   are defined in [RFC3394] and [RFC3537].
































Weis, et al.             Expires April 20, 2008                 [Page 9]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


3.  MAC Algorithms using Nonces

   All MAC algorithms take two types of inputs: the data to be
   authenticated, and the key.  Many MAC algorithms (e.g.,
   AES-128-CMAC-96 and HMAC-SHA-1-96) take only these inputs, which
   results in an Authentication Data field of the size of the resulting
   MAC.  However, another class of MAC algorithms takes an additional
   input called a "nonce".  Algorithms requiring a nonce tend to be
   better performing MAC algorithms, and thus have value when used with
   the TCP Enhanced Authentication Option.

   A nonce permutes the output of a MAC algorithm such that it returns a
   unique value for each ICV value generated with a particular key and
   nonce pair.  However, a particular key and nonce pair MUST NOT be
   used to authenticate two different sets of data.  Doing so may weaken
   the MAC such that an attacker is able to generate properly formed
   MACs, which is a catastrophic cryptographic failure.  Note that this
   restriction results in the requirement that a single MAC key MUST NOT
   be used to protect more than one TCP session.  In order to guarantee
   that nonces used with a particular MAC key are unique, a
   monotonically increasing sequence number is included in the nonce.

3.1.  Authentication Data Format

   If the MAC algorithm requires a nonce for its operation, the sequence
   number part of the nonce MUST be included at the beginning of the
   Authentication data, as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Message Authentication Code                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Sequence Number (32 bits).  A monotonically increasing value used
      as a base for a nonce for algorithms requiring a unique value for
      each ICV value generated with a particular key.  The first
      sequence number used with a particular MAC key is typically 1,
      although it MAY start a higher value.  When a sequence number
      reaches 2**32-1, the key MUST NOT be used to authenticate any
      further packets.

   o  Message Authentication Code (variable).  The size of the MAC
      varies according to the MAC algorithm definition (see table in a
      later section).  There are no restrictions on the size of the
      Message Authentication Code field.  In all cases, the MAC



Weis, et al.             Expires April 20, 2008                [Page 10]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


      algorithm definition must produce a result that is a multiple of 8
      bits.

   When a MAC algorithm requiring a nonce is used with a TCP Extended
   Authentication Option where K is 1, the Authentication Data field is
   as follows, with each field defined as described above:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Message Authentication Code                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                 In-line Encrypted Key Payload                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.  MAC Algorithm ID Types

   All Algorithm IDs described in the TCP Enhanced Authentication Option
   document are suitable for use with this option.  Additionally, the
   following nonce based MAC algorithms are defined.

   o  AES-128-GMAC-96.  AES [FIPS.197.2001] with a 128-bit key in the
      GMAC [GMAC] mode of operation, with the result truncated to 96
      bits.  This algorithm requires a 96-bit unique nonce.  The nonce
      is formed as follows.  The leftmost 56 bits are all set to zero.
      The next eight bits contain a direction byte.  The binary value of
      the direction byte is 00000000 for the TCP endpoint sending the
      segment containing the encrypted key, and 00000001 for the TCP
      endpoint receiving the segment containing the encrypted key.  The
      rightmost 32 bits are copied from the Sequence Number field.  The
      AES-128-GMAC-96 algorithm MUST be implemented for an
      implementation to conform to this specification.

   o  AES-128-UMAC-96.  The UMAC-96 message authentication code [UMAC]
      with the result truncated to 96 bits.  This algorithm also
      requires a nonce.  For the purposes of this document the nonce
      will be a 40 bit nonce.  The nonce is formed as follows.  The
      first eight bits contain a direction byte.  The binary value of
      the direction byte is 00000000 for the TCP endpoint sending the
      segment containing the encrypted key, and 00000001 for the TCP
      endpoint receiving the segment containing the encrypted key.  The
      rightmost 32 bits are copied from the Sequence Number field.







Weis, et al.             Expires April 20, 2008                [Page 11]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


4.  Discussion

4.1.  MAC Option Size

   The cumulative number of TCP option bytes is currently limited to 40
   bytes.  The TCP MAC Option can consume a variable number of bytes,
   depending on a number of factors.  The following sections describe
   several scenarios.

   The size of the authentication data field varies depending on the
   output of the MAC algorithm and whether or not the MAC algorithm
   requires a sequence number field.  The following table lists the MAC
   algorithms identified in this proposal and the resulting size of the
   authentication data field.

           +-----------------+---------------------------------+
           |  MAC Algorithm  | Authentication Data Size (bits) |
           +-----------------+---------------------------------+
           | HMAC-SHA-1-96   |               96                |
           | AES-128-CMAC-96 |               96                |
           | AES-128-GMAC-96 |              128                |
           | AES-128-UMAC-96 |              128                |
           +-----------------+---------------------------------+

4.1.1.  Authentication Data Only

   The TCP Enhanced Authentication Option consumes four bytes for the
   option header.  If K is not set to one, then the total size of the
   TCP MAC option is only the additional number of bytes needed by the
   MAC algorithm.  All MAC algorithms described in the TCP Enhanced
   Authentication Option and this memo require 12 bytes.  This gives a
   total of 16 bytes for the TCP MAC option.

   MAC algorithms requiring a nonce need an additional four bytes to
   carry a sequence number in the authentication data portion of the
   option.  This results in a total of 20 bytes.  However, MAC
   algorithms requiring a nonce tend to consume fewer software and/or
   hardware resources than other MAC algorithms.  Using a MAC algorithm
   requiring a nonce trades off an additional four bytes in the segment
   for a faster cryptographic algorithm.

4.1.2.  Adding an Encrypted Key

   If K is set to one, then the encrypted key field is added to the MAC
   option.  This adds the ability to do in-band keying, and simplify key
   management operations, but with a cost of additional TCP option
   bytes.  When an encrypted key is included, two bytes are always
   needed to describe the KEK algorithm and KEK Key Identifier used to



Weis, et al.             Expires April 20, 2008                [Page 12]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   encrypt the MAC key.  The KEK algorithm also determines the number of
   bytes needed for the encrypted MAC key.  The one KEK algorithm
   defined in this proposal requires 16 bytes, which results in a total
   of 18 bytes for the encrypted key.

   Thus, 34 bytes total bytes are required when paired with a MAC
   algorithm not needing a nonce (although 36 bytes may be used if
   padding is added).  A total of 38 bytes are required when paired with
   a MAC algorithm needing a nonce (or 40 bytes if padding is added).
   However, the encrypted key is only required when one of the TCP end-
   points requires a new key (i.e., at the start of a TCP session, or
   when the security policy mandates a change later on in the session.)
   All other segments in the TCP session contain only the Authentication
   Data portion, which remains a modest size.

   Additional KEK methods that require fewer bytes passed in the In-line
   Encrypted Key Payload may be defined at a later time, which would
   reduce the use of TCP Option bytes.

4.2.  Use of the TCP Sequence Number as a MAC Algorithm Nonce

   Using an additional four TCP option bytes for a sequence number
   dedicated to the MAC option is required in order to satisfy the
   cryptographic requirement of unique nonces.  No other value in a TCP
   packet is guaranteed to be unique.  At first glance, the TCP Sequence
   Number would appear to be suitable.  However, the TCP Sequence Number
   can wrap, after which it increments back through the same sequence
   number space.

   A security system should not depend on an external value when it can
   be manipulated such that the security constraint of the system is
   violated.  This sort of dependency greatly increases the size of the
   security boundary (that is, the logical boundary containing all of
   the security functionality), which makes the validation of the
   correctness of the security system much more difficult.

   In this case, the TCP Sequence Number is a value that can be
   manipulated elsewhere by the TCP module such that it is not actually
   unique enough for the security constraint.  For example, some TCP
   redundancy solutions may resend TCP segments starting with the same
   TCP sequence number but with a different length.  This violates the
   security requirement that a key and nonce are never used on TCP
   segments with different data.

   In summary, the TCP Sequence Number is not suitable for use a MAC
   algorithm nonce value.





Weis, et al.             Expires April 20, 2008                [Page 13]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


4.3.  Retention of automatically generated keys

   Automatically generated keys MUST NOT be set as Active (i.e., used
   for sending) after their lifetime has expired.  The expired keys MAY
   be retained and marked as Eligible for a period of time, as defined
   by local policy.  This is useful for continued receipt of TCP
   segments from the peer while the new key is being propagated.  For
   example, the TCP endpoint may need to receive acknowledgment messages
   indicating that the segment with the new MAC key was not received.

   Automatically generated keys SHOULD NOT be saved over a reboot.  If
   this advice is ignored, a nonce containing a sequence number greater
   than the most recently used sequence number MUST be stored with the
   key.  However, a more reliable system would simply generate a new MAC
   key (and associated nonce, if required) when the system resumes
   operation.

4.4.  TCP sequence number wrapping

   When a TCP sequence number wraps around (i.e., from a high number to
   a low number), an automatically generated key MUST be expired
   irrespective of lifetime policy and replaced with a new key.  If the
   old key were not expired, there is a slight possibility that the TCP
   sequence numbers in the segment will both wrap, and both appear to be
   current in the TCP window.  In this case, the segment may be accepted
   by the receiver as a new segment.  Should the replayed segment
   contain an encrypted MAC key, and if the KEK has not changed, then
   the receiver will install the old key and no longer communicate
   properly with the authentic sender of the TCP segments.






















Weis, et al.             Expires April 20, 2008                [Page 14]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


5.  IANA Considerations

   The terms "Standards Action" and "Private Use" in this section
   indicate the polices described for these terms in [RFC2434].

   The TCP Enhanced Authentication Code header includes an Algorithm ID
   field.  The following two new Algorithm ID types are defined in this
   document, which require values be assigned to them: AES-128-GMAC-96,
   AES-128-UMAC-96.

   The In-line Encrypted Key Payload contains an Algorithm ID, for which
   IANA is to create and maintain a registry entitled "Key Encrypting
   Key Algorithm IDs".  This document defines the following initial set
   of IDs:

             KEK Algorithm ID     Value
             ----------------     -----
             RESERVED             0
             AES-128-ECB          1
             Standards Action     2-47
             Private Use          48-63






























Weis, et al.             Expires April 20, 2008                [Page 15]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


6.  Security Considerations

   This proposal allows for automatic re-keying for the TCP Enhanced
   Authentication Option, which provides the following key management
   benefits:

   o  Automated key lifetime management.  A system can rollover keys
      triggered by any means chosen by the system (e.g., volume
      lifetime, time lifetime).  However, the effective lifetime of a
      MAC key is more likely to be terminated by the event of a TCP
      sequence number wrapping, as described in Section 4.4.

   o  Automated key selection.  Keys chosen with a good random number
      generator are generally superior in quality to keys chosen by a
      human operator.

   o  Keys are chosen for use of a particular TCP session, and cannot be
      shared between TCP session to different peers.

   Use of automatic key selection requires a static KEK with a long
   lifetime.  Whereas the KEK needs to be changed periodically, the
   length of the period should be very long compared to the lifetime of
   the MAC keys.  Because of the long lifetime, human interaction with
   the key is unnecessary after initial configuration, other than to
   verify that the key is entered correctly.  This KEK SHOULD be
   protected in non-volatile storage such that it is not subsequently
   available except to the TCP Enhanced Authentication Option.  Doing so
   also reduces the likelihood that it requires changing (e.g., due to
   operator staff turnover).

   MAC algorithms requiring a unique nonce per segment (e.g., AES-128-
   GMAC-96) SHOULD NOT be used be used with manually configured MAC
   keys.  If the sequence number used as an input to the nonce wraps (or
   is re-initialized after a system reboot), a single nonce would be
   used multiple times with a single key.  This would cause a
   catastrophic cryptographic failure, with the amount of damage
   dependant upon the actual algorithm.














Weis, et al.             Expires April 20, 2008                [Page 16]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


7.  References

7.1.  Normative References

   [FIPS.197.2001]
              National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", FIPS PUB 197, November 2001, <
              http://csrc.nist.gov/publications/fips/fips197/
              fips-197.pdf>.

   [GMAC]     McGrew, D. and J. Viega, "Galois/Counter Mode of Operation
              (GCM)", Submission to NIST modes of operation, May 2005,
              <http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
              gcm/gcm-revised-spec.pdf>.

   [I-D.bonica-tcp-auth]
              Bonica, R., "Authentication for TCP-based Routing and
              Management Protocols", draft-bonica-tcp-auth-06 (work in
              progress), February 2007.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [UMAC]     Black, J., Halevi, S., Krawczyk, H., Krovetz, T., and P.
              Rogaway, "UMAC: Fast and Secure Message Authentication",
              Advances in Cryptography -- CRYPTO '99 , September 1999,
              <http://www.cs.ucdavis.edu/~rogaway/umac/umac_full.pdf>.

7.2.  Informative References

   [FIPS.140-2.AnnexC]
              National Institute of Standards and Technology, "Annex C:
              Approved Random Number Generators for FIPS PUB 140-2,
              Security Requirements for Cryptographic Modules", FIPS PUB
              140-2 Annex C, January 2005, <http://csrc.nist.gov/
              publications/fips/fips140-2/fips1402annexc.pdf>.

   [I-D.viswanathan-keyrollover]
              Viswanathan, S., "Authentication-Key Rollover mechanism
              for Routing and Management Protocols",
              draft-viswanathan-keyrollover-00 (work in progress),



Weis, et al.             Expires April 20, 2008                [Page 17]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


              October 2006.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC3537]  Schaad, J. and R. Housley, "Wrapping a Hashed Message
              Authentication Code (HMAC) key with a Triple-Data
              Encryption Standard (DES) Key or an Advanced Encryption
              Standard (AES) Key", RFC 3537, May 2003.

   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
              RFC 3766, April 2004.






































Weis, et al.             Expires April 20, 2008                [Page 18]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


Appendix A.  Rejected Alternatives

   This draft discusses a means to exchange encrypted keys between TCP
   endpoints.  Several alternatives have been suggested.  This section
   describes those alternatives as well as the rationale by which they
   were rejected.

   Any method of generating keys for use by the TCP Enhanced
   Authentication option must be implementable within a TCP stack
   without depending on external management protocols.  Therefore, the
   approach must be relatively simple, yet provide good quality
   encryption keys in a secure manner.  The following methods partially
   meet this criteria but have flaws that result in their rejection.

A.1.  Deriving session keys from a master key

   A TCP endpoint could store a long-term master key used to derive
   session keys.  Session keys would be derived heuristically (e.g.,
   using a one-way hash chain) to create a set of ordered keys.  This
   would have the advantage of not needing to pass the session key in a
   packet between routers.

   However, in order to support his method a router would be required to
   store the position in a sequence to identify previously used keys.
   This is necessary in order to avoid re-using keys.  While that
   requirement may not initially seem onerous, it should be noted that
   router configurations are generally stored on media that is not
   intended to be written frequently (e.g., NVRAM, flash memory).
   Therefore, reliable storage of ephemeral information (such as the
   position in a sequence) is problematic.  A failure to store the most
   recently used key would result in a catastrophic security failure,
   and thus this method is rejected.

A.2.  Deriving session keys using the Diffie-Hellman algorithm

   It would be possible for a pair of TCP endpoints to use a Diffie-
   Hellman based protocol to derive session keys.  However, since the
   Diffie-Hellman public numbers would be passed in the first two
   segments of an exchange, some other security mechanism (e.g., a long-
   term shared secret) would be necessary to protect the first two
   segments in the stream.

   Diffie-Hellman public numbers with adequate security to derive a 128-
   bit AES key have been estimated at 3200 bits (400 bytes) [RFC3766].
   Numbers this large can consume too many bytes to be effectively
   transferred in a TCP option.  Also, computing the Diffie-Hellman
   algorithm shared secret during the initial handshake of every BGP
   session is too much overhead for the control plane of the router.  It



Weis, et al.             Expires April 20, 2008                [Page 19]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


   is clear that any in-band method based on passing Diffie-Hellman
   numbers is not feasible.

















































Weis, et al.             Expires April 20, 2008                [Page 20]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


Authors' Addresses

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-526-4796
   Email: bew@cisco.com


   Chandrashekhar Appanna
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-526-6198
   Email: achandra@cisco.com


   David McGrew
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-301-349-5815
   Email: mcgrew@cisco.com


   Anantha Ramaiah
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-525-6486
   Email: ananth@cisco.com











Weis, et al.             Expires April 20, 2008                [Page 21]


Internet-Draft      Automated TCP Auth Key Selection        October 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Weis, et al.             Expires April 20, 2008                [Page 22]