TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Intended status: Proposed Standard                            A. Mankin
Expires: January 2008                                      July 7, 2007



                   The TCP Simple Authentication Option
                  draft-touch-tcpm-tcp-simple-auth-03.txt


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 January 7, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies a TCP Simple Authentication Option (TCP-SA)
   which is intended to replace the TCP MD5 Signature option of RFC-2385
   (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and
   provides more details on the association of security associations
   with TCP connections. TCP-SA assumes an external, out-of-band



Touch                  Expires January 7, 2008                 [Page 1]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   mechanism (manual or via a separate protocol) for session key
   establishment, parameter negotiation, and rekeying, replicating the
   separation of key management and key use as in the IPsec suite. The
   result is intended to be a simple modification to support current
   infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to
   support a larger set of hashes with minimal other system and
   operational changes. TCP-SA requires no new option identifier, though
   it is intended to be mutually exclusive with TCP/MD5 on a given TCP
   connection. It can be used in the presence of NATs/NAPTs, and
   supports IPv6, and is fully compatible with requirements under
   development for an update to TCP/MD5.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents


   1. Introduction...................................................3
      1.1. Executive Summary.........................................3
      1.2. Changes from Previous Versions............................5
         1.2.1. New in draft-touch-tcp-simple-auth-03................5
         1.2.2. New in draft-touch-tcp-simple-auth-02................5
         1.2.3. New in draft-touch-tcp-simple-auth-01................6
      1.3. Summary of RFC-2119 Requirements..........................6
   2. The TCP Simple Authentication Option...........................6
      2.1. Review of TCP/MD5 Option..................................6
      2.2. TCP-SA Option.............................................7
   3. Security Association Management...............................11
   4. TCP-SA Interaction with TCP...................................13
      4.1. User Interface...........................................13
      4.2. TCP States and Transitions...............................14
      4.3. TCP Segments.............................................15
      4.4. Sending TCP Segments.....................................15
      4.5. Receiving TCP Segments...................................16
      4.6. Impact on TCP Header Size................................17
   5. Key Establishment and Duration Issues.........................17
      5.1. Implementing the TSAD as an External Database............18
   6. Interactions with TCP/MD5.....................................20
   7. Interactions with NAT/NAPT Devices............................20
   8. Evaluation of Requirements Satisfaction.......................20
   9. Security Considerations.......................................23
   10. IANA Considerations..........................................25
   11. Acknowledgments..............................................25


Touch                  Expires January 7, 2008                 [Page 2]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   12. References...................................................25
      12.1. Normative References....................................25
      12.2. Informative References..................................26
   Author's Addresses...............................................27
   Intellectual Property Statement..................................28
   Disclaimer of Validity...........................................28

1. Introduction

   The TCP MD5 Signature (TCP/MD5) is a TCP option that authenticates
   TCP segments, including the TCP IPv4 pseudoheader, TCP header, and
   TCP data. It was developed to protect BGP sessions from spoofed TCP
   segments which could affect BGP data or the robustness of the TCP
   connection itself [RFC2385][To07].

   There have been many recently-documented concerns about TCP/MD5. Its
   use of a simple keyed hash for authentication is problematic because
   there have been escalating attacks on the algorithm itself [Be05]
   [Bu06].  TCP/MD5 also lacks both key management and algorithm
   agility, and cannot be used when either party is behind NATs/NAPTs.
   This document proposes to add the latter, but suggests that TCP
   should not be the framework for cryptographic key management. This
   document updates the TCP/MD5 option to become a more general TCP
   Simple Authentication Option (TCP-SA), to support the use of other,
   stronger hash functions and to provide a more structured
   recommendation on external key management. The result also supports
   operation behind NAT/NAPT devices, is compatible with IPv6, and is
   fully compatible with requirements under development for an update to
   TCP/MD5 [Be06].

   This document is not intended to replace the use of the IPsec suite
   (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
   fact, we recommend the use of IPsec and IKE, especially where IKE's
   level of existing support for parameter negotiation, session key
   negotiation, or rekeying are desired. TCP-SA is intended for use only
   where the IPsec suite would not be feasible, e.g., as has been
   suggested is the case for some routing protocols, or in cases where
   keys need to be tightly coordinated with individual transport
   sessions [Be06].

1.1. Executive Summary

   This document updates TCP/MD5 as follows [RFC2385]:

   o  Reuses TCP/MD5's option Kind (=19), but allows TCP/MD5 to continue
      to be used for other connections.



Touch                  Expires January 7, 2008                 [Page 3]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   o  Replaces signed MD5 with HMAC-MD5-96, and allows other MACs at the
      implementer's discretion.

   o  Allows rekeying during a TCP connection, assuming that an out-of-
      band protocol or manual mechanism coordinates the change of key
      and that incorrectly keyed segments are ignored. In such cases, a
      key ID may be used to make key selection more efficient.

   o  Provides more detail in how this option interacts with TCP's
      states, event processing, and user interface.

   o  Proposed option is 4 bytes shorter (14 bytes overall, rather than
      18) in the default case (HMAC-MD5-96).

   o  Proposed option supports NAT/NAPTs, and protects the resulting TCP
      segment as received behind the NAT/NAPT.

   This document differs from currently competing proposals to update
   TCP/MD5 as follows [Bo07][We05][We07]:

   o  Fully compatible with requirements currently under development.

   o  Does not require a new TCP option Kind value.

   o  Does not support dynamic parameter negotiation.

   o  Does not support in-band session key negotiation.

   o  Does not support in-band session rekeying.

   o  Does not require additional timers.

   o  Always authenticates the TCP options as well as the segment
      pseudoheader, header, and data.

   o  Provides more detail in how this option interacts with TCP's
      states, event processing, and user interface.

   o  Proposed option is 2 bytes shorter (14 bytes overall, rather than
      16) in the default case (HMAC-MD5-96)

   o  Does not expose the MAC algorithm in the header.

   o  Does not require a key ID; it allows for one where key overlap is
      desired to support efficient rekeying.

   o  Supports NAT/NAPT while still protecting the segment as received.


Touch                  Expires January 7, 2008                 [Page 4]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   o  Supports TCP over either IPv4 or IPv6.

   This document differs from an IPsec/IKE solution as follows
   [RFC4301][RFC4306]

   o  Does not support dynamic parameter negotiation.

   o  Does not require a key ID (SPI), but does allow one.

   o  Does not protect from replay attacks.

   o  Forces a change of connection key when a connection restarts, even
      when reusing a TCP socket pair (IP addresses and port numbers)
      [Be06].

   o  Does not support encryption.

   o  Does not authenticate ICMP messages (some may be authenticated in
      IPsec, depending on the configuration).

1.2. Changes from Previous Versions

   [NOTE: to be omitted upon final publication as RFC]

1.2.1. New in draft-touch-tcp-simple-auth-03

   o  Added support for NAT/NAPT.

   o  Added support for IPv6.

   o  Added discussion of how this proposal satisfies requirements under
      development, including those indicated in [Be06].

   o  Clarified the byte order of all data used in the MAC.

   o  Changed the TCP option exclusion bit from a bit to a list.

1.2.2. New in draft-touch-tcp-simple-auth-02

   o  Add reference to Bellovin's need-for-TCP-auth doc [Be06].

   o  Add reference to SP4 [SDNS88].

   o  Added notes that TSAD to be externally implemented; this was
      compatible with the TSAD described in the previous version.




Touch                  Expires January 7, 2008                 [Page 5]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   o  Augmented the protocol to allow a KeyID, required to support
      efficient overlapping keys during rekeying, and potentially useful
      during connection establishment. Accommodated by redesigning the
      TSAD.

   o  Added the odd/even indicator for the KeyID.

   o  Allow for the exclusion of all TCP options in the MAC calculation.

1.2.3. New in draft-touch-tcp-simple-auth-01

   o  Allows intra-session rekeying, assuming out-of-band coordination.

   o  MUST allow TSAD entries to change, enabling rekeying within a TCP
      connection.

   o  Omits discussion of the impact of connection reestablishment on
      BGP, because added support for rekeying renders this point moot.

   o  Adds further discussion on the need for rekeying.

1.3. Summary of RFC-2119 Requirements

   [NOTE: a summary will be placed here prior to last call]

2. The TCP Simple Authentication Option

   The TCP Simple Authentication Option (TCP-SA) re-uses the Kind value
   currently assigned to TCP/MD5.

2.1. Review of TCP/MD5 Option

   For review, the TCP/MD5 option is shown in Figure 1.

                +---------+---------+-------------------+
                | Kind=19 |Length=18|   MD5 digest...   |
                +---------+---------+-------------------+
                |                                       |
                +---------------------------------------+
                |                                       |
                +---------------------------------------+
                |                                       |
                +-------------------+-------------------+
                |                   |
                +-------------------+

                 Figure 1 Current TCP MD5 Option [RFC2385]


Touch                  Expires January 7, 2008                 [Page 6]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   In the current TCP/MD5 option, the length is fixed, and the MD5
   digest occupies 16 bytes following the Kind and Length fields, using
   the full MD5 digest of 128 bits [RFC1321].

   The current TCP/MD5 option specifies the use of the MD5 digest
   calculation over the following values in the following order:

   1. the TCP pseudoheader (IP source and destination addresses,
      protocol number, and segment length)

   2. TCP header excluding options and checksum

   3. TCP data

   4. connection key

2.2. TCP-SA Option

   The new TCP-SA option is intended to be a superset of the TCP/MD5
   option, and minimal in the spirit of SP4 [SDNS88]. TCP-SA reuses the
   same Kind and Length fields, and is shown in Figure 2.

                +---------+---------+-----------------...
                | Kind=19 | Len=var |      MAF...     ...
                +---------+---------+-----------------...

                      Figure 2 Proposed TCP-SA Option

   The TCP-SA defines the following fields:

   o  Kind: An unsigned field indicating the TCP-SA Option. TCP-SA
      reuses the Kind value=19. Because of how keys are managed (see
      Section 3), an endpoint will not use TCP-SA for the same
      connection where TCP/MD5 is used, and so there would be no
      confusion as to how to interpret incoming Kind=19 segments.

   o  Length: An unsigned 8-bit field indicating the length of the TCP-
      SA option in bytes, including the Kind and Length fields.

      >> The Length MUST be greater than or equal to 2.

      >> The Length value MUST be consistent with the TCP header length.

      Values of 2 and other small values are of dubious utility but not
      specifically prohibited. See the MAF description for implications
      of odd/even lengths.



Touch                  Expires January 7, 2008                 [Page 7]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   o  MAF: The MAF is a Message Authentication Field. Its contents are
      determined by the particulars of the security association, where
      there are two possible variants. When the Length is even, the
      option appears as in Figure 3. When the Length is odd, the option
      appears as in Figure 4.

                +---------+---------+-------------------+
                | Kind=19 | Len=var |      MAC          |
                +---------+---------+-------------------+
                |              MAC (con't)...         ...
                +-------------------------------------...

                Figure 3 TCP-SA MAF without key identifier


                +---------+---------+-------------------+
                | Kind=19 | Len=var |      MAC          |
                +---------+---------+-------------------+
                |              MAC (con't)...         ...
                +-------------------+---------+-------...

                ...-----------------+---------+
                ...  MAC (con't)    |  KeyID  |
                ...-----------------+---------+

                  Figure 4 TCP-SA MAF with key identifier

      Typical MACs are 96-128 bits (12-16 bytes), but any length that
      fits in the header of the segment being authenticated is allowed.
      Because typical MACs are even-length, TCP-SA assumes so [RFC4306].
      If a particular MAC is odd-length, it is padded.

      >> An odd-length MAC MUST be padded with a single 0x00 byte on
      transmit. Setting this pad byte is considered part of the
      authentication algorithm.

      >> An odd-length MAC MUST have a trailing 0x00 pad byte on
      receipt. Checking this pad byte is considered part of the
      authentication algorithm.










Touch                  Expires January 7, 2008                 [Page 8]


Internet-Draft   The TCP Simple Authentication Option         July 2007


      When the Length is odd, a key identifier (KeyID) is included in
      the last byte of the option. The KeyID is used to support
      efficient key rollover during a connection and/or to help with key
      coordination during connection establishment, and will be
      discussed further in Sections 3.

      >> TCP-SA MUST support HMAC-MD5-96; other MACs MAY be supported
      [RFC2403].

      >> A single TCP segment MUST NOT have more than one TCP-SA option.

   The MAC is computed over the following fields in the following order;
   segment fields are as present in segments at the receiver (this
   impacts operation of this option in the presence of NATs, as
   discussed in detail in Section 7):

   1. the TCP pseudoheader: IP source and destination addresses,
      protocol number and segment length, all in network byte order,
      prepended to the TCP header below. The pseudoheader is exactly as
      used for the TCP checksum in either IPv4 or IPv6
      [RFC793][RFC2460]:

                   +--------+--------+--------+--------+
                   |           Source Address          |
                   +--------+--------+--------+--------+
                   |         Destination Address       |
                   +--------+--------+--------+--------+
                   |  zero  | Proto  |    TCP Length   |
                   +--------+--------+--------+--------+

                  Figure 5 TCP IPv4 pseudoheader [RFC793]


















Touch                  Expires January 7, 2008                 [Page 9]


Internet-Draft   The TCP Simple Authentication Option         July 2007


                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +           Source Address          +
                   |                                   |
                   +                                   +
                   |                                   |
                   +                                   +
                   +--------+--------+--------+--------+
                   |                                   |
                   +                                   +
                   |                                   |
                   +         Destination Address       +
                   |                                   |
                   +                                   +
                   |                                   |
                   +--------+--------+--------+--------+
                   |      Upper-Layer Packet Length    |
                   +--------+--------+--------+--------+
                   |      zero       |   Next Header   |
                   +--------+--------+--------+--------+

                 Figure 6 TCP IPv6 pseudoheader [RFC2460]







   2. TCP header, by default including options, and where the TCP
      checksum and TCP-SA MAC fields are set to zero, all in network
      byte order

   3. TCP data, in network byte order

   Note that the connection key is not included here; we expect that the
   MAC algorithm will indicate how to use the key, e.g., as HMACs do in
   general, and HMAC-MD5-96 does in particular [RFC2104][RFC2403].

   TCP-SA by default includes the TCP options because these options are
   intended to be end-to-end and some are required for proper TCP
   operation (e.g., SACK, timestamp, large windows). Middleboxes that
   alter TCP options en-route are a kind of attack and would be
   successfully detected by TCP-SA in its default configuration. In
   cases where the configuration of the connection's security


Touch                  Expires January 7, 2008                [Page 10]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   association state indicates otherwise, the TCP options can be
   excluded from the MAC calculation.

   The TCP-SA option does not indicate the MAC algorithm either
   implicitly (as with TCP/MD5) or explicitly (as with some proposed
   alternatives) [RFC2385][Bo07][We05][We07]. The particular algorithm
   used is considered part of the configuration state of the
   connection's security association and is managed separately (see
   Section 3).

3. Security Association Management

   TCP-SA relies on a TCP Security Association Database (TSAD). TSAD
   entries are assumed to exist at the endpoints where TCP-SA is used,
   in advance of the connection:

   1. TCP connection identifier (ID), i.e., socket pair - IP source
      address, IP destination address, TCP source port, and TCP
      destination address [RFC793]. TSAD entries are uniquely determined
      by their TCP connection ID, which is used to index those entries.

      >> There MUST be no more than one matching TSAD entry for TCP
     connection ID.

   2. For each of inbound (for received TCP segments) and outbound (for
      sent TCP segments) for this connection (except as noted):

       a. TCP Option exclusion list. A list of indicators that, when
          set, indicates that TCP options are excluded from all MAC
          calculations. When the empty, all TCP options are included.
          The special value 0x00, normally indicating the end of the TCP
          options list, indicates that all options are excluded (rather
          than indicating them all).

          >> The TCP Option list MUST default to empty.

          >> The TCP Option list MUST NOT change during a TCP
          connection.

          >> The TCP Option list MUST ignore settings for the TCP-SA
          option, i.e., the TCP-SA option MUST NOT be excluded from MAC
          calculation.







Touch                  Expires January 7, 2008                [Page 11]


Internet-Draft   The TCP Simple Authentication Option         July 2007


       b. Receiver TCP connection ID (RID) (outbound only). Normally,
          the RID would match the ID above (#1 above). Devices behind
          NAT/NAPTs would have nonmatching RIDs. This value is used for
          calculating the MAC at the sender.

          >> RIDs MUST NOT change during a TCP connection.

       c. An ordered list of zero or more connection key tuples. Each
          tuple consists of a set <KeyID, MAC type, key length,
          connection key> as follows:

          >> TSAD key tuple components MUST NOT change during a
          connection.

          >> The set of TSAD key tuples MAY change during a connection,
          but KeyIDs of those tuples MUST NOT overlap. I.e., tuple
          parameter changes MUST be accompanied by key changes.

           i. KeyID (optional). A single byte used to differentiate
               overlapping Connection keys. The KeyID value can be 0x00
               or not stored when not included.

               >> When an KeyID not used, the sender MUST use the key
               from the first key tuple returned, and the receiver MUST
               try all key tuples in order until one succeeds.

          ii. MAC type. Indicates the MAC used for this connection, as
               per IKEv2 Transform Type 3 [RFC4306]. This includes the
               MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and
               the length of the MAC as truncated to (e.g., 96, 128,
               etc.). Also, a setting of NONE must be supported, to
               indicate that authentication is not used in this
               direction; this allows asymmetric use of TCP-SA. At least
               one direction (inbound/outbound) SHOULD have a non-NONE
               MAC in practice, but this is not strictly required.

               >> When the outbound MAC is set to values other than
               NONE, TCP-SA MUST occur in every outbound TCP segment for
               that connection; when set to NONE or when no tuple
               exists, TCP-SA MUST NOT occur in those segments.

               >> When the inbound MAC is set to values other than NONE,
               TCP-SA MUST occur in every inbound TCP segment for that
               connection; when set to NONE or when no tuple exists,
               TCP-SA MUST NOT occur in those segments.




Touch                  Expires January 7, 2008                [Page 12]


Internet-Draft   The TCP Simple Authentication Option         July 2007


         iii. Key length. A byte indicating the length of the
               connection key in bytes.

          iv. Connection key. A byte sequence used for connection
               keying, this may be derived from a separate shared key by
               an external protocol over a separate channel. This
               sequence is used in network standard byte order in MAC
               calculations.

   It is anticipated that TSAD entries for active or opening TCP
   connections can be stored in the TCP Control Block (TCB) or in a
   separate database (see Section 5.1 for notes on the latter); TSAD
   entries for pending connections (in passive or active OPEN) may be
   stored in a separate database. This means that in a single host there
   should be only a single database which is consulted by all pending
   connections, the same way that there is only one set of TCBs.
   Multiple databases could be used to support virtual hosts, i.e.,
   groups of interfaces.

   Note that TSAD and the TCP-SA fields may omit the KeyID; the TCP
   connection ID already uniquely specifies the TSAD entry, so a
   separate field is not needed to specify a key unless key overlay
   during rekeying is supported or is needed for key coordination during
   connection establishment (see Section 5). The TCP-SA fields omit an
   explicit algorithm ID; that algorithm is already specified by the TCP
   connection ID and stored in the TSAD.

   Also note that this document does not address how TSAD entries are
   created or destroyed. It is presumed that a TSAD entry affecting a
   particular connection cannot be destroyed during an active connection
   - or, equivalently, that its parameters are copied local to the
   connection and so changes would affect only new connections. The TSAD
   could be managed by a separate application protocol, and can be
   stored in a separate database if desired.

4. TCP-SA Interaction with TCP

   The following is a description of how TCP-SA affects various TCP
   states, segments, events, and interfaces. This description is
   intended to augment the description of TCP as provided in RFC793
   [RFC793].

4.1. User Interface

   The TCP user interface supports active and passive OPEN, SEND,
   RECEIVE, CLOSE, STATUS and ABORT.



Touch                  Expires January 7, 2008                [Page 13]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   >> TCP OPEN, or the sequence of commands that configure a connection
   to be in the active or passive OPEN state, MUST be augmented so that
   a TSAD entry can be configured.

   >> New TSAD entries MUST be checked against a cache of previously
   used TSAD entries, and key reuse MUST be prohibited.

   Users are advised to not inappropriately reuse keys [RFC3562].

   >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a
   current or pending connection to be read (for confirmation).

   >> TCP STATUS MUST allow TSAD entries for ongoing TCP connections
   (i.e., not in the CLOSED state) to be modified. Parameters not used
   to index a connection MAY be modified; parameters used to index a
   connection MUST NOT be modified.

   TSAD entries for TCP connections not in the CLOSED state are deleted
   indirectly using the CLOSE or ABORT commands.

   >> Use of CLOSE or ABORT MUST retain the TSAD entry in a cache to
   assist with checking for key reuse.

   This entry may correspond to one of the wait states of TCP (FIN-WAIT-
   1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT), or may
   be stored separately (for connections proceeding rapidly to CLOSED).
   The size of this cache and duration of retained entries is up to the
   user, where we again advise the application of known key management
   principles [RFC3562].

   TCP SEND and RECEIVE are not affected by TCP-SA.

4.2. TCP States and Transitions

   TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
   FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
   CLOSED.

   >> A TSAD entry MAY be associated with any TCP state.

   >> A TSAD entry MAY underspecify the TCP connection for the LISTEN
   state. Such an entry MUST NOT be used for more than one connection
   progressing out of the LISTEN state.






Touch                  Expires January 7, 2008                [Page 14]


Internet-Draft   The TCP Simple Authentication Option         July 2007


4.3. TCP Segments

   TCP includes control (at least one of SYN, FIN, RST flags set) and
   data (none of SYN, FIN, or RST flags set) segments.

   >> All TCP segments MUST be checked against the TSAD for matching TCP
   connection IDs.

   >> TCP segments matching TSAD entries with non-NULL MACs without TCP-
   SA, or with TCP-SA and whose MACs and/or KeyIDs (the latter when in
   use) do not validate MUST be silently discarded.

   >> TCP segments with TCP-SA but not matching TSAD entries MUST be
   silently accepted.

   >> Silent discard events SHOULD be signaled to the user as a warning,
   and silent accept events MAY be signaled to the user as a warning.
   Both warnings, if available, MUST be accessible via the STATUS
   interface. Either signal MAY be asynchronous, but if so they MUST be
   rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
   limiting as well.

   All TCP-SA processing occurs between the interface of TCP and IP; for
   incoming segments, this occurs after validation of the TCP checksum.
   For outgoing segments, this occurs before computation of the TCP
   checksum.

   Note that the TCP-SA option is not negotiated. It is the
   responsibility of the receiver to determine when TCP-SA is required
   and to enforce that requirement.

   >> Receivers MAY silently accept TCP segments with the TCP-SA option.

4.4. Sending TCP Segments

   The following procedure describes the modifications to TCP to support
   TCP-SA when a segment departs.

   1. Check the segment's TCP connection ID against the TSAD

   2. If there is NO TSAD entry, omit the TCP-SA option. Proceed with
      computing the TCP checksum and transmit the segment.

   3. If there is a TSAD entry with zero key tuples, omit the TCP-SA
      option. Proceed with computing the TCP checksum and transmit the
      segment.



Touch                  Expires January 7, 2008                [Page 15]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   4. If there is a TSAD entry and a key tuple and the outgoing MAC is
      NONE, omit the TCP-SA option. Proceed with computing the TCP
      checksum and transmit the segment.

   5. If there is a TSAD entry and a key tuple and the outgoing MAC is
      not NONE:

       a. Augment the TCP header with the TCP-SA, inserting the
          appropriate Length and KeyID (the latter only if Length is
          odd) based on the indexed TSAD entry. Update the TCP header
          length accordingly.

       b. Compute the MAC using the indexed TSAD entry and data from the
          segment as specified in Section 2.2. Use the TCP pseudoheader
          and TCP header as it would be received, i.e., use the RID
          values rather than the actual outgoing pseudoheader and header
          (see Section 7 for more information).

          Note that excluded options are zeroed when used as input to
          the MAC calculation.

       c. Insert the MAC in the TCP-SA field.

       d. Proceed with computing the TCP checksum on the outgoing packet
          and transmit the segment.

4.5. Receiving TCP Segments

   The following procedure describes the modifications to TCP to support
   TCP-SA when a segment arrives.

   1. Check the segments TCP connection ID against the TSAD

   2. If there is NO TSAD entry, proceed with TCP processing.

   3. If there is a TSAD entry with zero key tuples, proceed with TCP
      processing.

   4. If there is a TSAD entry with a key tuple and the incoming MAC is
      NONE, proceed with TCP processing.

   5. If there is a TSAD entry with a key tuple and the incoming MAC is
      not NONE:

       a. Check that the segment's TCP-SA Length matches the length
          indicated by the indexed TSAD.



Touch                  Expires January 7, 2008                [Page 16]


Internet-Draft   The TCP Simple Authentication Option         July 2007


           i. If Lengths differ, silently discard the segment. Log
               and/or signal the event as indicated in Section 4.3.

       b. If the Length is odd, use the KeyID value to index the
          appropriate key for this connection

           i. If the TSAD has no entry corresponding to the segment's
               KeyID, silently discard the segment.

       c. Compute the segment's MAC using the indexed TSAD entry and
          portions of the segment as indicated in Section 2.2.

          Again, note that excluded options are zeroed when used as
          input to the MAC calculation.

           i. If the computed MAC differs from the TCP-SA MAC field
               value, silently discard the segment. Log and/or signal
               the event as indicated in Section 4.3.

       d. Proceed with TCP processing of the segment.

   It is suggested that TCP-SA implementations validate a segment's
   Length field before computing a MAC, to reduce the overhead incurred
   by spoofed segments with invalid TCP-SA fields.

4.6. Impact on TCP Header Size

   The TCP-SA option typically uses a total of 16-18 bytes of TCP header
   space. TCP-SA is no larger than and typically 2 bytes smaller than
   the TCP/MD5 option. Although TCP option space is limited, we believe
   TCP-SA is consistent with the desire to authenticate TCP at the
   connection level for similar uses as were intended by TCP/MD5.

5. Key Establishment and Duration Issues

   The TCP-SA option does not provide a mechanism for connection key
   negotiation or parameter negotiation (MAC algorithm, length, use of
   the TCP-SA option, or RID) or rekeying during a connection. We assume
   out-of-band mechanisms for key establishment, parameter negotiation,
   and rekeying. This separation of key use from key management is
   similar to that in the IPsec security suite [RFC4301][RFC4306].

   We encourage users of TCP-SA to apply known techniques for generating
   appropriate keys, including the use of reasonable connection key
   lengths, limited connection key sharing, and limiting the duration of
   connection key use [RFC3562].



Touch                  Expires January 7, 2008                [Page 17]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   TCP-SA supports rekeying in which new keys are negotiated out-of-
   band, either via a protocol or a manual procedure [RFC4808]. New keys
   use is coordinated using the out-of-band mechanism to update the TSAD
   at both TCP endpoints. In the default case, where only a single key
   is used at a time, the temporary use of invalid keys would result in
   packets being dropped; TCP is already robust to such drops. Such
   drops may affect TCP's throughput temporarily, as a result TCP-SA
   benefits from the use of congestion control support for temporary
   path outages.

   >> TCP-SA SHOULD be deployed in conjunction with support for
   selective acknowledgement (SACK), including support for multiple lost
   segments in the same round trip [RFC2018][RFC3517].

   Note that TCP-SA's support for rekeying is designed to be minimal in
   the default case. Segments carry only enough context to identify the
   security association [RFC4301][RFC4306]. In TCP-SA, this context is
   provided by the socket pair (IP addresses and ports for source and
   destination). In the default case, the key is identified only in the
   TSAD, and coordinated by a separate mechanism not specified in TCP-
   SA. In cases where such coordination is difficult, or where loss
   during rekeying is inappropriate, the TSAD can contain multiple
   concurrent keys. Where multiple keys are used, the KeyID field is
   used to identify the key that corresponds to a segment, to avoid the
   need for expensive trial-and-error testing of keys in sequence.

   The KeyID field may also be useful in coordinating keys for new
   connections. A TSAD may be configured that matches the unbound source
   port, which would return a set of possible keys. The KeyID would then
   indicate which key, allowing more efficient connection establishment;
   otherwise, the keys could be tried in sequence. See also Section 5.1.

   Implementations are encouraged to keep keys in a suitably private
   area. Users of TCP-SA are encouraged to use different keys for
   inbound and outbound MACs on a given TCP connection.

5.1. Implementing the TSAD as an External Database

   The TSAD implementation is considered external to TCP-SA. When an
   external database is used, it would be useful to consider the
   interface between TCP-SA and the TSAD. The following is largely a
   restatement of information in Section 3.

   TSAD entries are indexed during a connection as follows:





Touch                  Expires January 7, 2008                [Page 18]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   o  TCP connection identifier (ID) (The socket pair, sent as 4 byte IP
      source address, 4 byte IP destination address, 2 byte TCP source
      port, 2 byte TCP destination port)

   o  Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 =
      outbound)

   o  Number of bytes to be sent/received (two bytes)

   o  KeyID (single byte, optional, 0x00 when not present)

   The call passes the number of bytes sent/received, and an indication
   of the direction (send/receive), to enable traffic-based key
   rollover.

   The source port can be 'unbound', indicated by the value 0x0000. In
   this case, the source port is considered a wildcard, and all
   corresponding TSAD entries (typically also indexed by the KeyID in
   that case) are returned as a list. This feature is used during
   connection establishment.

   TSAD calls return the following parameters:

   o  TCP Option exclusion indicator bit (one bit, passed as a byte with
      value 0x00 or 0x01).

   o  Receiver TCP connection ID (RID), i.e., the socket pair expected
      on received segments. This differs from the ID above when one
      party is behind a NAT/NAPT device; otherwise, it matches the ID.

   o  An ordered list of zero or more connection key tuples:
      <KeyID, MAC type, MAC length, connection key>

       o  KeyID (one byte, ignored if the KeyID is not present or 0x00)

       o  MAC type (two bytes)

       o  Key length (one byte)

       o  Connection key (byte sequence, indicating the key value)

   When the TSAD returns zero keys, it is indicating that there are no
   currently valid keys for the connection.






Touch                  Expires January 7, 2008                [Page 19]


Internet-Draft   The TCP Simple Authentication Option         July 2007


6. Interactions with TCP/MD5

   TCP-SA is intended to be deployed without regard for existing TCP/MD5
   option support.

   >> A TCP implementation MUST NOT use both TCP-SA and TCP/MD5 for a
   particular TCP connection, but MAY support TCP-SA and TCP/MD5
   simultaneously for different connections.

   There is no need to explicitly indicate which of TCP-SA or TCP/MD5 is
   used for a particular connection in the TCP segments. Even where the
   two used the same hash (e.g., if TCP-SA were to use MD5 rather than
   HMAC-MD5) and the same length (128 bits), TCP-SA computes its MAC
   over different data (including the TCP-SA option, notably, with the
   MAC zeroed) than TCP/MD5. The probability of a TCP-SA segment being
   validated by TCP/MD5 or the converse is roughly equivalent to that of
   a random party guessing a valid MAC.

7. Interactions with NAT/NAPT Devices

   TCP-SA can work in the presence of one or more NAT/NAPT devices on
   the path between endpoints [RFC2766]. This solution assumes that the
   key configuration - either in an automated protocol, or via manual
   discovery - knows the mapping between TCP connection IDs as sent from
   the source host and TCP connection IDs as received at the destination
   host. A key management protocol could determine the RID by including
   a copy of their view of the ID in the key exchange; this serves as an
   automatic NAT/NAPT discovery mechanism.

   TCP-SA requires the source compute the MAC based on TCP connection ID
   as received (received ID, or RID). The MAC is consistent with the
   packet as received, rather than assuming a translation step at the
   receiver. We note that this translation could occur at the receiver,
   but want to reduce the complexity and potential additional effort
   there.

8. Evaluation of Requirements Satisfaction

   TCP-SA satisfies all the current requirements for a revision to
   TCP/MD5, as indicated in [Be06] and under current developemt. This
   should not be a surprise, as the majority of the evolving
   requirements are derived from its design. The following is a summary
   of those requirements and notes where relevant.

   1. Protected Elements - see Section 2.2.




Touch                  Expires January 7, 2008                [Page 20]


Internet-Draft   The TCP Simple Authentication Option         July 2007


       a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that
          we do not allow optional coverage because we present a
          solution that does not require such to interoperate with
          NAT/NAPT devices.

       b. TCP header. Note that we do not allow port coverage to be
          optional because we present a solution that does not require
          this to interoperate with NAT/NAPT devices.

       c. TCP options. Allows exclusion of any option desired except
          TCP-SA, as required.

       d. TCP data. Done.

   2. Option structure requirements

       a. Privacy. TCP-SA exposes only the key index, MAC, and overall
          option length. Note that short MACs could be obscured by using
          longer option lengths but specifying a longer option (this is
          equivalent to a different MAC algorithm, and is specified in
          the TSAD entry). See Section 2.2.

       b. Allow optional per connection. Done - see Sections 4.3, 4.4,
          and 4.5.

       c. Require non-optional. Done - see Sections 4.3, 4.4, and 4.5.

       d. Standard parsing. Done - see Section 2.2.

       e. Compatible with Large Windows. Done - see Section 2.2. The
          size of the option is intended to allow use with Large Windows
          and SACK. See also Section 1.1, which indicates that TCP-SA is
          4 bytes shorter than TCP/MD5 in the default case.

       f. Compatible with SACK. Done - see Section 2.2. The size of the
          option is intended to allow use with Large Windows and SACK.
          See also Section 5 regarding key management. See also Section
          1.1, which indicates that TCP-SA is 4 bytes shorter than
          TCP/MD5 in the default case.

   3. Cryptography requirements

       a. Baseline defaults. TCP-SA uses HMAC-MD5-96 as the default, as
          noted in Section 2.2.





Touch                  Expires January 7, 2008                [Page 21]


Internet-Draft   The TCP Simple Authentication Option         July 2007


       b. Good algorithms. TCP-SA uses HMAC-MD5-96 as the default, but
          does not otherwise specify the algorithms used. That would be
          specified in the key management protocol, and should be
          limited there.

       c. Algorithm agility. TCP-SA allows any desired algorithm,
          subject to TCP option space limitations, as noted in Section
          2.2. The TSAD allows separate connections to use different
          algorithms.

       d. Pre-TCP processing. Done - see Sections 4.3, 4.4, and 4.5.
          Note that pre-TCP processing is required, because TCP segments
          cannot be discarded solely based on a combination of
          connection state and out-of-window checks; many such segments,
          although discarded, cause a host to respond with a replay of
          the last valid ACK, e.g. [RFC793].

       e. Parameter changes require key changes. TSAD parameters that
          should not change during a connection (TCP connection ID,
          receiver TCP connection ID, TCP option exclusion list) cannot
          change. Other parameters change only when a key is changed,
          using the key tuple mechanism in the TSAD. See Section 3.

   4. Keying requirements. TCP-SA does not specify a key management
      system, but does indicate a proposed interface to the TSAD,
      allowing a completely separate key system.

       a. Intraconnection rekeying. Supported by the KeyID and multiple
          key tuples in a TSAD entry; see Section 3.

       b. Efficient rekeying. Supported by the KeyID. See Section 5.

       c. Automated and manual keying. Supported by the TSAD interface.
          See Section 5.

       d. Key management agnostic. Supported by the TSAD interface. See
          Section 5.1.

   5. Expected constraints

       a. Silent failure. Done - see Sections 4.3, 4.4, and 4.5.

       b. At most one such option per segment. Done - see Section 2.2.

       c. Outgoing all or none. Done - see Section 4.4.

       d. Incoming all checked. Done - see Section 4.5.


Touch                  Expires January 7, 2008                [Page 22]


Internet-Draft   The TCP Simple Authentication Option         July 2007


       e. Non-interaction with TCP/MD5. Done - see Section 6.

       f. Optional ICMP discard. Done - see Section 9.

       g. Allows use of NAT/NAPT devices. Done - see Section 7.

       h. Maintain TCP connection semantics, in which only the socket
          pair defines a TCP association and all its security
          parameters. Done - see Sections 3 and 7.

       i. Try to avoid creating a CPU DOS attack opportunity. Done - see
          Section 9.

9. Security Considerations

   Use of TCP-SA, like use of TCP/MD5 or IPsec, will impact host
   performance. Connections that are known to use TCP-SA can be attacked
   by transmitting segments with invalid MACs. Attackers would need to
   know only the TCP connection ID and TCP-SA Length value to
   substantially impact the host's processing capacity. This is similar
   to the susceptibility of IPsec to on-path attacks, where the IP
   addresses and SPI would be visible. For IPsec, the entire SPI space
   (32 bits) is arbitrary, whereas for routing protocols typically only
   the source port (16 bits) is arbitrary. As a result, it would be
   easier for an off-path attacker to spoof a TCP-SA segment that could
   cause receiver validation effort. However, we note that between
   Internet routers both ports could be arbitrary (i.e., determined a-
   priori out of band), which would constitute roughly the same off-path
   antispoofing protection of an arbitrary SPI.

   TCP-SA, like TCP/MD5, may inhibit connectionless resets. Such resets
   typically occur after peer crashes, either in response to new
   connection attempts or when data is sent on stale connections; in
   either case, the recovering endpoint may lack the connection key
   required (e.g., if lost during the crash). This may result in time-
   outs, rather than more responsive recovery after such a crash.

   TCP-SA does not expose the MAC algorithm used to authenticate a
   particular connection; that information is kept in the TSAD at the
   endpoints, and is not indicated in the header.

   TCP-SA is intended to provide similar protections to IPsec, but is
   not intended to replace the use of IPsec or IKE either for more
   robust security or more sophisticated security management.

   TCP-SA does not address the issue of ICMP attacks on TCP. IPsec makes
   recommendations regarding dropping ICMPs in certain contexts, or


Touch                  Expires January 7, 2008                [Page 23]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   requiring that they are endpoint authenticated in others [RFC4301].
   There are other mechanisms proposed to reduce the impact of ICMP
   attacks by further validating ICMP contents and changing the effect
   of some messages based on TCP state, but these do not provide the
   level of authentication for ICMP that TCP-SA provides for TCP [Go07].

   >> A TCP-SA implementation MUST allow the system administrator to
   configure whether TCP will ignore incoming ICMP messages of Type 3
   Codes 2-4 intended for connections that match TSAD entries with non-
   NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be
   logged.

   This control affects only ICMPs that currently require 'hard errors'
   which would abort the TCP connection. This recommendation is intended
   to be similar to how IPsec would handle those messages [RFC4301].

   TCP-SA includes the TCP connection ID as received (i.e., the socket
   pair in the headers of the received segment) in the MAC calculation,
   to enable interoperability in the presence of NAT/NAPT devices. This
   prevents connections using the same key (for whatever reason) from
   potentially enabling a traffic-crossing attack, in which segments to
   one socket pair are diverted to attack a different socket pair. When
   multiple connections use the same key, it would be useful to know
   that packets intended for one ID could not be (maliciously or
   otherwise) modified in transit and end up being authenticated for the
   other ID. The ID cannot be zeroed, because to do so would require
   that the TSAD index was unique in both directions (ID->key and key-
   >ID). That requirement would place an additional burden of uniqueness
   on keys within endsystems, and potentially across endsystems.
   Although the resulting attack is low probability, the protection
   afforded by including the received ID warrants its inclusion in the
   MAC, and does not unduly increase the MAC calculation or key
   management system.

   The use of any security algorithm can present an opportunity for a
   CPU DOS attack, where the attacker sends false, random segments that
   the receiver under attack expends substantial CPU effort to reject.
   In IPsec, such attacks are reduced by the use of a large Security
   Parameter Index (SPI) and Sequence Number fields to partly validate
   segments before CPU cycles are invested validated the Integrity Check
   Value (ICV). In TCP-SA, the socket pair performs most of the function
   of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay
   attacks, isn't needed due to TCP's Sequence Number, which is used to
   reorder received segments. Unfortunately, it is not useful to
   validate TCP's Sequence Number before performing a TCP-SA
   authentication calculation, because many out-of-window segments still
   cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is


Touch                  Expires January 7, 2008                [Page 24]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   similarly not useful to add a separate Sequence Number field to the
   TCP-SA option, because doing so could cause a change in TCP's
   behavior even when segments are valid.

10. IANA Considerations

   The TCP-SA option reuses the TCP MD5 Signature option (TCP/MD5),
   where Kind=19. This document augments that use of this Kind value,
   but there is no need to deprecate or override the use of TCP/MD5.
   This document suggests that only one key algorithm would be
   applicable in either case, and so there would be no confusion for a
   given Length and key value as used for authenticating segments of a
   given TCP connection.

   If this document is approved as an IETF Standard, IANA is requested
   to add a registration for TCP-SA to Kind=19, along with the existing
   registration for TCP/MD5, and add a pointer to this document.

11. Acknowledgments

   This document was inspired by the revisions to TCP/MD5 suggested by
   Brian Weis and Ron Bonica [Bo07][We05]. Russ Housley suggested
   L4/application layer management of the TSAD. The KeyID field was
   motivated by Steve Bellovin. Alfred Hoenes provided substantial
   feedback on this document.

   This document was prepared using 2-Word-v2.0.template.dot.

12. References

12.1. Normative References

   [RFC793]  Postel, J., "Transmission Control Protocol," STD 007, RFC
             793, Standard, Sept. 1981.

   [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
             Selective Acknowledgement Options", RFC 2018, Proposed
             Standard, April 1996.

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

   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
             Signature Option," RFC 2385, Proposed Standard, Aug. 1998.




Touch                  Expires January 7, 2008                [Page 25]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
             (IPv6) Specification," RFC 2460, Proposed Standard, Dec.
             1998.

   [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
             Conservative Selective Acknowledgment (SACK)-based Loss
             Recovery Algorithm for TCP", RFC 3517, Proposed Standard,
             April 2003.

   [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
             and AH," RFC 2403, Proposed Standard, Nov. 1998.

12.2. Informative References

   [Be05]    Bellovin, S., E. Rescorla, "Deploying a New Hash
             Algorithm," presented at the First NIST Cryptographic Hash
             Workshop, Oct. 2005.
             http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm

   [Be06]    Bellovin, S. "Towards a TCP Security Option," draft-
             bellovin-tcpsec-00, (work in progress), Oct. 2006.

   [Bu06]    Burr, B., "NIST Cryptographic Standards Status Report,"
             Invited talk at Internet 2 5th Annual PKI R&D Workshop,
             April 2006.
             http://middleware.internet2.edu/pki06/proceedings/

   [Bo07]    Bonica, R., et. al, "Authentication for TCP-based Routing
             and Management Protocols,"   draft-bonica-tcp-auth-06,
             (work in progress), Feb. 2007.

   [Go07]    Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
             attacks-02, (work in progress), May 2007.

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

   [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
             Hashing for Message Authentication," RFC 2104,
             Informational, Feb. 1997.

   [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation -
             Protocol Translation (NAT-PT)," RFC 2766, Proposed
             Standard, Feb. 2000.

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


Touch                  Expires January 7, 2008                [Page 26]


Internet-Draft   The TCP Simple Authentication Option         July 2007


   [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
             Protocol," RFC 4301, Proposed Standard, Dec. 2005.

   [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC
             4306, Proposed Standard, Dec. 2005.

   [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," RFC
             4808, Informational, Mar. 2007.

   [SDNS88]  Secure Data Network Systems, "Security Protocol 4 (SP4),"
             Specification SDN.401, Revision 1.2, July 12, 1988.

   [To07]    Touch, J., "Defending TCP Against Spoofing Attacks," draft-
             ietf-tcpm-tcp-antispoof-06, (work in progress), Feb. 2007.

   [We05]    Weis, B., "TCP Message Authentication Code Option," draft-
             weis-tcp-mac-option-00, (expired work in progress), Dec.
             2005.

   [We07]    Weis, B., "Automated key selection extension for the TCP
             Authentication Option," draft-weis-tcp-auth-auto-ks-02,
             (work in progress), Mar. 2007.

Author's Addresses

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu
   URL:   http://www.isi.edu/touch


   Allison Mankin
   Washington, DC
   U.S.A.

   Phone: 1 301 728 7199
   Email: mankin@psg.com
   URL:   http://www.psg.com/~mankin/






Touch                  Expires January 7, 2008                [Page 27]


Internet-Draft   The TCP Simple Authentication Option         July 2007


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

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.

Acknowledgment

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



Touch                  Expires January 7, 2008                [Page 28]


Internet-Draft   The TCP Simple Authentication Option         July 2007



















































Touch                  Expires January 7, 2008                [Page 29]