[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06

TCPM Working Group                                             R. Bonica
Internet-Draft                                          Juniper Networks
Expires: August 5, 2006                                          B. Weis
                                                          S. Viswanathan
                                                           Cisco Systems
                                                                A. Lange
                                                                 Alcatel
                                                              O. Wheeler
                                                                      BT
                                                           February 2006


     Authentication for TCP-based Routing and Management Protocols
                        draft-bonica-tcp-auth-04

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 August 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo describes a TCP extension that enhances security for BGP,
   LDP and other TCP-based protocols.  It is intended for applications



Bonica, et al.           Expires August 5, 2006                 [Page 1]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   where secure administrative access to both the end-points of the TCP
   connection is normally available.  TCP peers can use this extension
   to authenticate messages passed between one another.

   The strategy described herein improves upon current practice, which
   is described in RFC 2385.  Using this new strategy, TCP peers can
   update authentication keys during the lifetime of a TCP connection.
   TCP peers can also use stronger authentication algorithms to
   authenticate routing messages.


Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Key Chain Definition . . . . . . . . . . . . . . . . . . . . .  6
   6.  Active Key Selection . . . . . . . . . . . . . . . . . . . . .  7
   7.  MAC Calculation  . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Key Eligibility  . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  TCP Enhanced Authentication Option . . . . . . . . . . . . . . 10
   10. Authentication Algorithms  . . . . . . . . . . . . . . . . . . 11
   11. Future Enhancements  . . . . . . . . . . . . . . . . . . . . . 12
   12. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 12
     12.1.  Clock Synchronization . . . . . . . . . . . . . . . . . . 12
     12.2.  Connectionless Resets . . . . . . . . . . . . . . . . . . 12
     12.3.  Performance . . . . . . . . . . . . . . . . . . . . . . . 12
     12.4.  TCP Header Size . . . . . . . . . . . . . . . . . . . . . 13
     12.5.  Backwards Compatibility . . . . . . . . . . . . . . . . . 13
     12.6.  ICMP-based attacks  . . . . . . . . . . . . . . . . . . . 13
     12.7.  Relationship With TLS . . . . . . . . . . . . . . . . . . 14
   13. Operational Considerations . . . . . . . . . . . . . . . . . . 14
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   17. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     18.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
     18.2.  Informative References  . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19









Bonica, et al.           Expires August 5, 2006                 [Page 2]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


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


2.  Terminology

   The following terms are used in this document:

      key-chain - A data structure used by TCP.  The key-chain is a list
      of keys.

      key - A member of the key-chain.  Each key contains an identifier,
      information that can be used to authenticate a TCP segment,
      information that determines when the key can be used to
      authenticate an outbound segment, and information that determines
      when the key can be used to authenticate an inbound segment.

      active key - A key that TCP uses to generate authentication
      information for outbound segments.  At any given time, zero or one
      keys is active.

      eligible key - A key that TCP can use to authenticate inbound
      segments.  At any given time, zero, one or more keys can be
      eligible.


3.  Introduction

   RFC 2385 [7] proposes a mechanism that authenticates TCP [2] sessions
   by including a message authentication code (MAC) in each TCP header.
   Authentication coverage includes the following fields:

      - the TCP pseudo-header

      - the TCP header, excluding options, and assuming a checksum of
      zero

      - the TCP segment data (if any)

   To spoof a connection using the scheme described above, an attacker
   would not only have to guess TCP sequence numbers, but would also
   have to obtain the key that was used to calculate the MAC.  This key
   never appears in the connection stream.

   RFC 3562 [8] addresses key management considerations regarding the



Bonica, et al.           Expires August 5, 2006                 [Page 3]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   TCP MD5 Signature Option.  Based upon the strength of the MD5 [9]
   hashing algorithm, RFC 3562 recommends that keys be changed at least
   every 90 days.

   Unfortunately, the strategy described in RFC 2385 permits keys to be
   changed during the lifetime of a TCP connection only so long as the
   change is synchronized at both ends.  This limitation has proven to
   be a significant deterrent to the effective deployment of the TCP MD5
   Signature Option.  This memo addresses that limitation.

   Also, the MD5 algorithm does not now provide a sufficient level of
   security, and recently published attacks motivate its replacement.
   In addition, the keyed hash MAC construction used by RFC 2385 has
   serious cryptographic weaknesses.  An attacker who can find a
   collision in the underlying hash function can forge a MAC using a
   simple chosen-message attack [10].  This memo makes use of MAC
   algorithms that do not have these weaknesses.  It also provides a
   mechanism to add additional algorithms as the state-of-the-art in
   cryptography progresses.


4.  Proposal

   This memo proposes a TCP Enhanced Authentication Option that is used
   as follows:

   Network operators associate a key-chain with each protected TCP
   connection.  Each key-chain includes a list of keys.  Each key is
   associated with a unique identifier and several other data items that
   are described in Section 5 of this document.

   Whenever TCP generates a segment, it searches the key-chain for an
   active key.  Section 6 of this document describes TCPs active key
   selection criteria.

   If TCP does not find an active key, it discards the outbound segment.
   However, if TCP finds an active key, it executes the following
   sequence:

      - append the TCP Enhanced Authentication Option to the TCP header

      - update the TCP Enhanced Authentication Option to include
      information from the active key, including the key's unique
      identifier







Bonica, et al.           Expires August 5, 2006                 [Page 4]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


      - calculate a MAC using information from the active key.  (See
      Section 7 of this document for MAC calculation details.)

      - update the TCP Enhanced Authentication Option to include
      authentication information, including the MAC that was calculated
      above

      - calculate and update the TCP checksum

      - forward the segment to a TCP peer.

   The receiving TCP associates the inbound TCP segment with a local
   key-chain based upon source IP address, destination IP address,
   source port and destination port.  It then searches the associated
   key-chain for a key whose identifier matches that which was specified
   by the incoming segment option.  If TCP finds such a key and that key
   satisfies the eligibility criteria described in Section 8 of this
   document, TCP uses information from that key to calculate a MAC.  If
   no matching eligible key is found then TCP MUST declare an
   authentication failure and discard the segment.

   TCP will accept the segment if the calculated MAC matches the MAC
   specified by the inbound segment.  Otherwise, TCP MUST declare an
   authentication failure and discard the segment.

   TCP MUST also declare an authentication failure and discard a segment
   if the segment is received from a connection that is associated with
   a key-chain and the segment does not include the TCP Enhanced
   Authentication Option.

   To help protect against denial of service attacks it is RECOMMENDED
   that the inbound TCP segment is validated against the normal TCP
   criteria (e.g. that the segment sequence number is within the current
   receive window) prior to the MAC being calculated.  Inbound TCP
   segments on connections requiring the Enhanced Authentication Option
   MUST NOT cause the current TCP state variables for that connection to
   be updated unless the MAC has been verified as correct.

   An authentication failure MUST NOT produce any response back to the
   sender.  Routers SHOULD log authentication failures.

   Unlike other TCP extensions (e.g., the Window Scale option [11]), the
   absence of the option in the SYN,ACK segment must not cause the
   sender to disable its sending of authentication data.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.



Bonica, et al.           Expires August 5, 2006                 [Page 5]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of authentication
   data must be under the complete control of the application, not at
   the mercy of the remote host not understanding the option.


5.  Key Chain Definition

   This section describes information requirements for the key-chain.
   It does not mandate any specific implementation.

   A keychain is a set of up to 64 keys, where each key is {A[i], K[i],
   V[i], S[i], T[i], S'[i], T'[i]}:

    i     Key identifier, integer (0...63)
    A[i]  Authentication algorithm to use with key[i].
    K[i]  Shared secret to use with key[i].
    V[i]  A vector that determines whether key[i] is to be used to
          generate MACs for inbound segments, outbound segments, or both.
    S[i]  Start time from which key[i] can be used by sending TCPs.
    T[i]  End time after which key[i] cannot be used by sending TCPs.
    S'[i] Start time from which key[i] can be used by receiving TCPs.
    T'[i] End time after which key[i] cannot be used by receiving TCPs

   For the purpose of this document, key[i] is defined as the key whose
   identifer is equal to i.

   A list of values for A[i] is provided in Section 10 of this document.
   The format of K[i] depends upon A[i].  Also see Section 10 for
   details.

   A[i] and K[i] MUST be configured symmetrically on TCP peers.  That
   is, if key[i] is configured on two peer systems, A[i] and K[i] must
   be configured identically on each system.

   S[i], T[i], S'[i] and T'[i] are measured from a defined epoch that
   must have a known relationship to UTC.  For the purposes of
   discussion, times are assumed to be measured in seconds since that
   epoch, although this is not a requirement.

   The range of values that can be specified for S[i], T[i], S'[i] and
   T'[i] includes two special values.  The first special value is called
   NOW, and it represents the system time when the key is examined (as
   opposed to when the key is configured).  The second special value,
   called INFINITY, represents a time beyond the end of the epoch.

   S[i] and T[i] define a time-window during which a key can be used for
   sending.  S'[i] and T'[i] define a time-window during which a key can



Bonica, et al.           Expires August 5, 2006                 [Page 6]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   be used for receiving.  In most configurations, the time-window
   defined by S[i] and T[i] is narrower than the time-window defined by
   S'[i] and T'[i] on the remote system.  In some cases, defining a
   narrower sending time-window determines the connection's tolerance to
   clock-skew on either system.

   Within a key-chain, time-windows for sending can overlap.  Likewise,
   within a key-chain, time-windows for receiving can overlap.
   Typically, network operators will configure key-chains so that there
   are no gaps between time-windows for either sending or receiving.
   Implementations should issue a warning when network operators
   configure key-chains with gaps between time-windows.  A gap of
   sufficient length can cause the TCP session to fail due to timeout.

   In general, network operators should avoid reusing shared secrets.
   The degree to which an operator can reuse keys is defined by local
   security policy.

   During the lifetime of a TCP connection, network operators may add
   and delete keys from the keychain.  However, the network operator
   must ensure that an active key is always configured on both TCP
   endpoints.

   Implementations are free to implement key chains in any manner that
   satisfies the above stated information requirements.  For example,
   implementations can translate the above stated information
   requirements directly into a data structure.  Alternatively, they can
   implement one key-chain for sending and another for receiving.  In
   this case, the implementation may omit data items that do not apply
   to either the sending or receiving key chain.

   Likewise, implementations can implement S[i] and T[i] as a start-time
   and an end-time.  Alternatively, implementations can implement S[i]
   and T[i] as a start-time and a duration, or they can infer the T[i]
   from the S[i] of the next key.


6.  Active Key Selection

   The following paragraphs describe how the sending TCP selects the
   active key from its key chain.  Implementations SHOULD support this
   key selection process; implementations MAY also support other active
   key selection mechanisms as a configurable option.

   First, TCP identifies all candidate keys that meet the following
   requirements:





Bonica, et al.           Expires August 5, 2006                 [Page 7]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


      - V[i] specifies that the key can be used for either sending or
      sending and receiving

      - the system time >= S[i]

      - the system time < T[i]

   Because the time-windows specified by S[i] and T[i] can overlap, it
   is possible that multiple keys will satisfy the above stated
   criteria.  When this occurs, TCP chooses between the candidate keys
   by applying following rules in the order that they are listed below:

      - prefer the youngest key (i.e., the key whose value for S[i] is
      greatest)

      - When there is a tie based upon the above stated criterion,
      select the key whose identifier is numerically smallest.

      The selection process described above is guaranteed to return zero
      or one active keys.  If no active key is returned, TCP discards
      the outbound TCP segment.


7.  MAC Calculation

   The sending TCP calculates a MAC by applying the authentication
   algorithm from the active key to the following items in the order
   that they are listed:

      - the TCP pseudo-header

      - the TCP header, assuming a checksum of zero.  (See below for a
      discussion of TCP Options within the the TCP header.)

      - the TCP segment data (if any)

   For IPv4, the pseudo-header is described in RFC 793 [2].  It includes
   the 32-bit source IP address, the 32-bit destination IP address, the
   zero-extended protocol number (to form 16 bits), and the 16-bit
   segment length.  Note that this includes use of IPv4 via IPv4-mapped
   IPv6 addresses, in which case the source and destination IP addresses
   are from the IPv4 portions of the IPv6 source and destination
   addresses, respectively.

   For IPv6, the pseudo-header is described in RFC 2460 [3].  It
   includes the 128-bit source IPv6 address, the 128-bit destination
   IPv6 address, the zero-extended next header value (to form 32 bits),
   and the 32-bit segment length.



Bonica, et al.           Expires August 5, 2006                 [Page 8]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   The header and pseudo-header are in network byte order.

   By default, for the purpose of MAC calculation, the TCP header
   includes all TCP options, including the TCP Enhanced Authentication
   Option with its Authentication Data Field (i.e., MAC) set to zero.
   However, TCP implementations MAY omit TCP Options from the MAC
   calculation.  When implementation do so, they MUST set the T-bit in
   the TCP Enhanced Authentication Option.  See Section 9 of this
   document for details.

   The receiving TCP calculates the MAC in a manner identical to the
   sending TCP.  However, it must examine the T-bit from the incoming
   TCP Enhanced Authentication Option to determine whether incoming TCP
   Options should be included in the MAC calculation.  See Section 9 for
   details.


8.  Key Eligibility

   When TCP receives a segment that includes the TCP Enhanced
   Authentication Option, it searches that connection's keychain for a
   key whose identifier is identical to Key ID specified by the incoming
   TCP Enhanced Authentication Option.  TCP uses that key to
   authenticate the incoming segment providing that the key is eligible
   to be used.

   Implementations SHOULD support the following process for determining
   key eligibility; implementations MAY also support other eligible key
   selection mechanisms as a configurable option.

   A key is eligible if all of the following criteria are met:

      - V[i] specifies that the key can be used for either receiving or
      sending and receiving

      - A[i] is equal to the algorithm specified by the TCP Enhanced
      Authentication Option from the incoming segment

      - the system time >= S'[i]

      - the system time < T'[i]

   If TCP does not find a key whose identifier is identical to the Key
   ID specified by the incoming TCP Enhanced Authentication Option, it
   MUST declare an authentication failure and discard the segment.
   Likewise, TCP MUST declare an authentication failure if it finds the
   key but the key is not eligible.




Bonica, et al.           Expires August 5, 2006                 [Page 9]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


9.  TCP Enhanced Authentication Option

   Figure 1 depicts the TCP Enhanced Authentication Option format.

            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |     Kind      |     Length    |T|K|   Alg ID  |Res|  Key ID   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                    Authentication Data                        |
           |                            //                                 |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Option Syntax

   Kind: 8 bits

   The Kind field identifies the TCP Enhanced Authentication Option.
   This value will be assigned by IANA.

   Length: 8 bits

   The Length field specifies the length of the TCP Enhanced
   Authentication Option, in octets.  This count includes two octets
   representing the Kind and Length fields.

   The valid range for this field is from 4 to 40 octets, inclusive.
   For all algorithms specified in this memo the value will be 16
   octets.

   T-Bit: 1 bit

   The T-bit specifies whether TCP Options were omitted from the TCP
   header for the purpose of MAC calculation.  A value of 1 indicates
   that TCP options were omitted.  A value of 0 indicates that TCP
   options were included.  The default value is 0.

   K-Bit: 1 bit

   This bit is reserved for future enhancement.  Its value MUST be equal
   to zero.  See Section 11 for details.

   Alg ID: 6 bits

   The Alg ID field identifies the MAC algorithm.  See Section 10 for
   permissible values.

   Res: 2 bits



Bonica, et al.           Expires August 5, 2006                [Page 10]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   These bits are reserved.  They MUST be set to zero.

   Key ID: 6 bits

   The Key ID field identifies the key that was used to generate the
   message digest.

   Authentication Data: Variable length

   The Authentication Data field contains data that is used to
   authenticate the TCP segment.  This data includes, but need not be
   restricted to, a MAC.  The length and format of the Authentication
   Data Field can be derived from the Alg ID.  See Section 10 for
   details.


10.  Authentication Algorithms

   The following MAC Algorithms are suitable for use with this option.

      - AES-128-CMAC-96.  AES with a 128-bit key in the CMAC mode of
      operation [4].  When this algorithm is used, implementations MUST
      specify a value of 1 (in binary, 000001) in the TCP Enhanced
      Authentication Option Alg ID field.  Also, the Authentication Data
      field must contain exactly 96 bits representing the MAC, truncated
      to that length, with the high-order bit first.  The
      AES-128-CMAC-96 algorithm MUST be implemented for an
      implementation to conform to this specification.

      - HMAC-SHA-1-96.  SHA-1 with a 160-bit key in the HMAC mode of
      operation [5].  When this algorithm is used, implementations MUST
      specify a value of 2 (in binary, 000010) in the TCP Enhanced
      Authentication Option ALG ID field.  Also, the Authentication Data
      field must contain exactly 96 bits representing the MAC, truncated
      to that length, with the high-order bit first.  This algorithm MAY
      be implemented for an implementation to conform to this
      specification.

   Implementations MUST present a management interface through which the
   user can specify any member of the key space.  For example, if the
   key contains 128 bits, the command line interface might accept this
   value as a string of exactly 32 hexadecimal digits, with each
   hexadecimal digit representing 4 bits of the shared secret.

   Implementations MAY employ authentication algorithms not listed
   above.





Bonica, et al.           Expires August 5, 2006                [Page 11]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


11.  Future Enhancements

   In the future, the TCP Enhanced Authentication Option will be
   enhanced to support automated session key distribution.  The K-bit is
   reserved for the purpose of indicating that session key distribution
   extensions are present.  These extensions are beyond the scope of
   this memo.


12.  Implications

12.1.  Clock Synchronization

   Because the TCP Enhanced Authentication Option includes a key
   identifier, the strategy described herein is immune from most
   problems caused by poor clock synchronization.  Clocks do not need to
   be synchronized accurately between the sending and receiving systems.
   The only requirements are that the key used to generate the MAC on
   the sending system is also configured on the receiving system and
   that the time ovelap between sender's active key and the receiver's
   eligible key is great enough to compensate for clock skew.

   Receipt of a segment whose authentication data was generated using a
   key other than the one that is currently active on the receiving
   system does not constitute an error.  It may indicate only that
   clocks are not synchronized between the sending and receiving
   systems.

12.2.  Connectionless Resets

   A connectionless reset will be ignored by the receiver of the reset
   if the originator of that reset does not know the key and therefore
   cannot generate the proper authentication data for the segment.  This
   means, for example, that connection attempts by a TCP which is
   generating authentication data to a port with no listener will time
   out instead of being refused.  Similarly, resets generated by a TCP
   in response to segments sent on a stale connection will also be
   ignored.  Operationally this can be a problem since resets help some
   protocols recover quickly from peer crashes.

12.3.  Performance

   The performance hit in calculating digests may inhibit the use of
   this option.  Performance will vary depending upon processor type,
   authentication algorithm, packet size and number of MAC calculations
   per second.





Bonica, et al.           Expires August 5, 2006                [Page 12]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


12.4.  TCP Header Size

   As with other options that are added to every segment, the size of
   the TCP Enhanced Authentication Option must be factored into the MSS
   offered to the other side during connection negotiation.
   Specifically, the size of the header to subtract from the MTU
   (whether it is the MTU of the outgoing interface or IP's minimal MTU
   of 576 octets) is now increased by the size of the TCP Enhanced
   Authentication Option.

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-byte words.  This means
   that the total size of the header plus options must be less than or
   equal to 60 octets.  This leaves 40 octets for options.

   As a concrete example, assume that an implementation defaults to
   sending window-scaling and timestamp information for connections it
   initiates.  The most loaded segment will be the initial SYN packet to
   start the connection.  With the TCP Enhanced Authentication Option
   using AES-128-CMAC-96, the SYN packet will contain the following:

      -- 4 octets MSS option

      -- 4 octets window scale option (3 octets padded to 4 in many
      implementations)

      -- 12 bytes for timestamp

      -- 16 octets for the TCP Enhanced Authentication Option

   This sums to 36 octets, leaving only four octets for future
   expansion.

12.5.  Backwards Compatibility

   On any particular TCP connection, use of the TCP Enhanced
   Authentication Option precludes use of the TCP MD5 Signature Option.
   However, use of the TCP Enhanced Authentication Option on one
   connection does not preclude the use of the TCP MD5 Signature Option
   on another connection by the same system.

12.6.  ICMP-based attacks

   In some cases, the strategy described herein could be used to defend
   against ICMP-based attacks [12] against TCP.  If ICMP implementations
   were to include a sufficiently large portion of the original datagram
   in the ICMP message, TCP could verify the MAC specified in the TCP



Bonica, et al.           Expires August 5, 2006                [Page 13]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   Enhanced Authentication Option before processing the ICMP message.

   Unfortunately, most ICMP implementations include only the IP header
   plus first 64 bits of the IP payload in the ICMP message.  TCP
   Options never begin within that boundary.

12.7.  Relationship With TLS

   The Transport Layer Security protocol (TLS) [13] provides
   confidentiality and message authentication to TCP connections.
   However, TLS works above the TCP layer, and does not protect the TCP
   connection itself.  In contrast, the TCP Authentication Option
   provides protection against attacks on the TCP layer, such as
   connection reset attacks.


13.  Operational Considerations

   Network operators may experience an operational need to make a key
   become both active and eligible immediately.  In order to satisfy
   this need, the network operator should execute the following
   sequence:

   Configure the key on both TCP peers with i equal to the lowest free
   value.  On both systems, set S[i] and T[i] to INFINITY.  This will
   cause the key to be perpetually inactive (for sending).  Also set
   S'[i] to NOW and T'[i] to INFINITY.  This will cause the key to be
   perpetually eligible (for receiving).

   Once the above step has been completed, on both systems, set S[i] to
   NOW.  This will cause the key[i] to become active.  Now it is safe to
   remove or deactivate all other keys.


14.  Contributors

   The following individuals contributed to this document:

      Chandrashekhar Appanna (achandra@cisco.com)

      Andy Heffernan (ahh@juniper.net)

      Kapil Jain (kapil@juniper.net)

      David McGrew (mcgrew@cisco.com)






Bonica, et al.           Expires August 5, 2006                [Page 14]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


      Satish Mynam (mynam@cisco.com)

      Anantha Ramaiah (ananth@cisco.com)


15.  Acknowledgments

   Thanks to Steve Bellovin, Ted Faber, Ross Callon, Joe Touch and Ran
   Atkinson for their comments regarding this draft.


16.  Security Considerations

   This proposal describes a strong authentication method for
   authenticating TCP segments.  It defines the use of cryptographic MAC
   algorithms, which are considered state-of-the-art.  As such, their
   expected lifetime of usefulness extends for several years.  But
   cryptographic algorithms have an effective lifetime, depending on
   advancing processor speed and cryptographic research.  This proposal
   provides for the future addition of new MAC algorithms as they are
   needed.

   Management of RFC 2385 keys has been a significant operational
   problem, both in terms of key synchronization and key selection.
   Current guidance [8] warns against sharing RFC 2385 keys between
   systems, and recommends changing keys according to a schedule.  The
   same general operational issues are relevant for the management of
   MAC keys.

   Because the TCP Authentication Option relies on manual configuration,
   it is possible that misconfigurations will occur.  We review the
   scenarios and describe their impact on security.

   When multiple devices are configured with the same key, it is
   possible that one or more of the devices is configured to use the
   wrong MAC algorithm.  If the misconfigured device is using a MAC that
   is significantly weaker than that used by the correctly configured
   devices, where the weakness allows an attacker to recover the MAC
   key, the misconfiguration reduces the security of the properly
   configured devices.  An attacker who can recover the key through
   cryptanalysis of the weaker algorithm can use that information to
   attack the stronger algorithm.  For this reason, implementations
   SHOULD verify the length of the keys entered into the system, and
   reject keys that are too short.  Implementations can detect this
   misconfiguration when the MAC Algorithm ID field in the receiver's
   key is compared with that in the packet.  When this event is
   detected, it SHOULD provide that information to an administrator,
   e.g. through logging or a management interface.  This attack is not



Bonica, et al.           Expires August 5, 2006                [Page 15]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   applicable to AES-CMAC or HMAC, since neither of those MACs is
   vulnerable to a key recovery attack.

   When one or more devices are configured with a particular key, it is
   possible that another device is configured with a slightly different
   key, due to a typographical error.  For example, the two keys might
   differ only in a single hexadecimal digit.  Message authentication
   codes that are vulnerable whenever two related keys are used could be
   vulnerable in this scenario.  In order to protect against this
   potential vulnerability, it is RECOMMENDED that no MACs with such
   vulnerabilities be used.  Neither AES-CMAC nor HMAC have such a
   vulnerability.


17.  IANA Considerations

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

   A new TCP Option Kind value must be defined in the IANA TCP
   Parameters registry.

   The option header contains an 8-bit ALG ID, for which IANA is to
   create and maintain a registry entitled "MAC Algorithm IDs".  This
   document defines the following message authentication code types:

             MAC Algorithm ID     Value
             ----------------     -----
             RESERVED             0
             AES-128-CMAC-96      1
             HMAC-SHA-1-96        2
             Standards Action     3-47
             Private Use          48-63

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


18.  References

18.1.  Normative References

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

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




Bonica, et al.           Expires August 5, 2006                [Page 16]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [4]  National Institute of Standards and Technology, "Recommendation
        for Block Cipher Modes of Operation: The CMAC Mode for
        Authentication", FIPS PUB 800-38B, May 2005, <http://
        csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf>.

   [5]  National Institute of Standards and Technology, "The Keyed-Hash
        Message Authentication Code (HMAC)", FIPS PUB 198, March 2002,
        <http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf>.

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

18.2.  Informative References

   [7]   Heffernan, A., "Protection of BGP Sessions via the TCP MD5
         Signature Option", RFC 2385, August 1998.

   [8]   Leech, M., "Key Management Considerations for the TCP MD5
         Signature Option", RFC 3562, July 2003.

   [9]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
         April 1992.

   [10]  Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash
         Functions for Message Authentication", Proceedings of
         Crypto'96 , LNCS 1109, pp. 1-15., June 1996, <An extended
         version of this paper is available at
         http://www.research.ibm.com/security/bck2.ps>.

   [11]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for
         High Performance", RFC 1323, May 1992.

   [12]  Gont, F., "ICMP attacks against TCP",
         draft-gont-tcpm-icmp-attacks-05 (work in progress),
         October 2005.

   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.










Bonica, et al.           Expires August 5, 2006                [Page 17]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


Authors' Addresses

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Email: rbonica@juniper.net


   Brian Weis
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134-1706
   US

   Email: bew@cisco.com


   Sriram Viswanathan
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   US

   Email: sriram_v@cisco.com


   Andrew Lange
   Alcatel
   710 E. Middlefield Road
   Mountain View, CA  94043
   US

   Email: andrew.lange@alcatel.com


   Owen N. Wheeler
   British Telecommunications plc
   Adastral Park
   Martlesham Heath
   IPSWICH, Suffolk  IP5 3RE
   GB

   Email: owen.wheeler@bt.com





Bonica, et al.           Expires August 5, 2006                [Page 18]


Internet-Draft     TCP Enhanced Authentication Option      February 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Bonica, et al.           Expires August 5, 2006                [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/