[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                        E. Rescorla
Internet-Draft                                                RTFM, Inc.
Intended status:  Informational                           March 09, 2008
Expires:  September 10, 2008


               Notes on TCP Authentication Architectures
                  draft-rescorla-tcp-auth-arch-00.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 September 10, 2008.

Abstract

   This document provides an architectural survey of a variety of
   approaches to key management for TCP-level authentication.













Rescorla               Expires September 10, 2008               [Page 1]


Internet-Draft               TCP Auth. Arch                   March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   3.  Keys and Associations  . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Different Keying Material Per Connection . . . . . . . . .  4
     3.2.  Rekeying for Key Compromise  . . . . . . . . . . . . . . .  5
     3.3.  Limiting Plaintext/MAC Pairs . . . . . . . . . . . . . . .  5
   4.  Credentials Interface  . . . . . . . . . . . . . . . . . . . .  6
   5.  Handshake and Capabilities Discovery . . . . . . . . . . . . .  6
   6.  Potential Architectures  . . . . . . . . . . . . . . . . . . .  7
     6.1.  Architectures Without Handshakes . . . . . . . . . . . . .  7
       6.1.1.  Single Static Key  . . . . . . . . . . . . . . . . . .  7
       6.1.2.  Implicit Diversification . . . . . . . . . . . . . . .  8
     6.2.  Architectures with Handshakes  . . . . . . . . . . . . . .  9
       6.2.1.  Internal Key Management Protocol . . . . . . . . . . .  9
       6.2.2.  External KMP . . . . . . . . . . . . . . . . . . . . . 10
       6.2.3.  Layered KMP  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15




























Rescorla               Expires September 10, 2008               [Page 2]


Internet-Draft               TCP Auth. Arch                   March 2008


1.  Introduction

   The TCP MD5 Authentication option [RFC2385] describes an mechanism
   for authenticating TCP segments using an MD5-based MAC (though the
   document does not use that term).  The MAC is keyed using a single
   static key shared between a pair of TCP endpoints.

   Recent work by Wang et al.  [WH05] has demonstrated significant
   weaknesses in MD5 which imply that TCP MD5 should be phased out in
   favor of a more modern MAC algorithm.  In addition, it seems worth
   addressing some of the more glaring protocol flaws in TCP MD5.  The
   consensus requirements are probably the following:

   Algorithm agility -  The ability to support multiple MAC algorithms.
   Strong MACs -  Mandatory support for some strong MAC algorithm.
   Key rollover -  Support for changing MAC keys during the duration of
      a TCP connection without breaking the connection.

   Note that there is currently two documents
   [I-D.ietf-tcpm-tcp-auth-opt] [I-D.bellovin-tcpsec] that discuss
   additional requirements, but it's not clear to me that these
   requirements have consensus or in fact are correct.

   The remainder of this document discusses some additional
   architectural issues and then describes a series of different design
   approaches formed by answering these architectural issues in
   different ways.


2.  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].


3.  Keys and Associations

   Probably the most important architectural question is the
   relationship of keys to associations.  As indicated above, TCP MD5
   uses a single static key for all associations.  This key is
   configured in a pairwise fashion.  By contrast, conventional channel
   security protocols such as TLS [RFC4346] or IPsec [RFC4301] establish
   a fresh set of keying material for each association.  The proposed
   TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt] also requires
   (though does not arrange for) a fresh key for each association.





Rescorla               Expires September 10, 2008               [Page 3]


Internet-Draft               TCP Auth. Arch                   March 2008


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

   There are two good (and one not so good) reasons why it's desirable
   to have mechanisms for changing keys:

   o  To arrange for different cryptographic keying material to be used
      for each connection, thus preventing cut-and-paste attacks between
      connections.  (Good)
   o  To allow rekeying in case of key compromise.  (Good)
   o  To limit the amount of plaintext/MAC pairs available to the
      attacker (Not-so-good)

   The following sections discuss each of these issues.

3.1.  Different Keying Material Per Connection

   It's standard cryptographic practice to try to use a cryptographic
   key for one purpose and by extension it's good key hygiene to use a
   separate key for each association.  The reason for per-association
   keying is to prevent cut-and-paste/replay attacks between
   associations To take a simple example, consider what would happen if
   TLS used the same key for any communication between two elements.  An
   attacker could record your connection and replay it, thus potentially
   causing you to (for instance) issue multiple orders.  Using a
   separate key for each association provides automatic cryptographic
   protection against this kind of attack--the replayed PDUs simply fail
   verification.

   Note that any TCP authentication solution where the authentication
   tag covers the TCP header has some built-in resistance to this sort
   of attack because each association has a different set of ports, so
   you can only substitute between pairs of connections with the same
   port.  Obviously, ports do get reused, so this is isn't perfect.
   It's quite a bit better of client-side port randomization is used,
   and much worse if systems use deterministic port numbers (e.g., using
   the same sequence of client-side port numbers after each reboot.)

      There's actually a general observation here:  when you're only
      providing integrity, there's a (mostly) isomorphism between
      incorporating diversifying information into the keying material
      and incorporating it into the integrity check.  I.e., if you have
      a per-connection identifier and a fixed key, you can do:
      * K_conn = HMAC(K_fixed, conn_id); Packet_MAC = HMAC(K_conn,
      packet)
      or





Rescorla               Expires September 10, 2008               [Page 4]


Internet-Draft               TCP Auth. Arch                   March 2008


      * Packet_MAC = HMAC(K_fixed, conn_id || packet)
      This doesn't work for encryption as well because of accidental
      plaintext collisions and/or two-time pad issues, but it's not a
      problem for MACs.

   In TCP, cut-and-paste attacks are also possible within a connection
   due to sequence number rollover.  This can be fixed, however, by
   extending the sequence numbers virtually, as done with ESP/AH.

3.2.  Rekeying for Key Compromise

   If the long-term key used to authenticate an endpoint becomes known
   to an attacker, then the attacker can impersonate that endpoint until
   the key is revoked (i.e., until the counterparties know that key is
   no longer valid).  If the endpoint wishes to continue communicating,
   then a new key will need to be established as well.  Note that this
   also applies to traffic keys:  in fact, since they are generally used
   with symmetric rather than asymmetric modes, the attacker can
   typically impersonate both A to B and B to A.

   In the BGP case that everyone is concerned about, this all needs to
   be done without breaking the connection, so this implies the need to
   impose entirely new cryptographic state on the connection without
   breaking it.

   Note that this is an orthogonal issue to the question of whether
   connections use the same key:  even if all your associations
   simultaneously used the same keys, you might still want to rekey them
   all to recover from a compromise.

3.3.  Limiting Plaintext/MAC Pairs

   A classical concern of COMSEC designers has been to limit the amount
   of plaintext/ciphertext material available to attackers for a single
   key:

   There are two primary rationales for this practice:

   o  Many older algorithms are weak if large numbers of plaintext/
      ciphertext pairs are available.  In some cases this means analytic
      attacks.  In others it means some form of table-driven dictionary
      attack such as CBC IV rollover.  The latter form of attack
      typically isn't that powerful, with the exception of counter-mode
      ciphers which have hard limits on counter use.
   o  To increase the attacker's workload:  if the attacker needs to
      break a new instance of the cipher for each association, then it
      doesn't pay off to capture six months work of traffic and break it
      at leisure.



Rescorla               Expires September 10, 2008               [Page 5]


Internet-Draft               TCP Auth. Arch                   March 2008


   The first concern is a lot less applicable with modern crypto
   algorithms such as AES or HMAC.  No known good analytic attacks are
   known on these systems no matter how many plaintext/ciphertext pairs
   you have, and collision limits due to blocksize are fairly far out:
   2^{64} blocks for AES, 2^{b/2} blocks for HMAC, where b is the size
   of the authentication tag used.  This isn't to say that they're
   totally irrelevant, but regular rekeying simply is not necessary.

   The second concern is rather less relevant for integrity checks,
   systems, since a successful attack on an integrity system doesn't
   compromise old traffic; you can just attack newer traffic.  This
   means the attacker has to break the system during the life of a
   single association, which is much more limiting.


4.  Credentials Interface

   As described at the beginning of this document, essentially all the
   currently deployed systems use a single pre-configured pairwise
   shared key.  This key is directly configured on the router interface.
   For instance, here's the example from Cisco's IOS manuals [REF:  http
   ://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/
   1cbgp.html#wp5978]

             router bgp 109 neighbor 145.2.2.2 password v61ne0qkel33&

   It's extremely desirable to be able to retain the existing
   interfaces.  Any solution which requires a significant change to
   those interfaces and especially to the interaction model creates a
   substantial additional burden on operators, which creates a major
   barrier to deployment.

   One important implication of this constraint is that a workable
   system must either allow a single key (or perhaps set of keys) to be
   used as traffic keys for multiple connections/association, or it must
   allow for some method of automatic key establishment based on a
   single small set of initial keys.  A system which requires a fresh
   key for each connection and does not provide any kind of automatic
   key establishment will break once the set of preconfigured keys is
   exhausted, which is unacceptable in a production system.


5.  Handshake and Capabilities Discovery

   The ability to automatically discover a peer's capabilitiies is a
   common feature of modern cryptographic protocols.  For instance, SSL/
   TLS, IPsec (IKE [RFC4306]), and SSH all offer some form of algorithm
   negotiation, in which the sides mutually determine some common set of



Rescorla               Expires September 10, 2008               [Page 6]


Internet-Draft               TCP Auth. Arch                   March 2008


   acceptable algorithms.

   This capability has obvious advantages in systems like SSL/TLS and
   IKE where endpoints may be communicating with other endpoints with
   which they share no preexisting state:  it allows the implementations
   to discover each others capabilities without having them
   preconfigured.  However, even in systems where the keying material is
   statically and manually configured, an automatic discovery system
   removes the need for a configuration knob (the algorithms for this
   remote system), which potentially reduces errors.  In addition, it
   allows for the possibility of automatic upgrade between algorithms
   (and other functionality) without reconfiguring each peer.  For
   instance, if peer A shares keys with 10 other peers and wants to roll
   out new algorithm X, it can simply upgrade its implementation and X
   will be used with the other peers automatically as they upgrade
   without requiring manual discovery.


6.  Potential Architectures

   This section describes a number of potential architectures for key
   management for TCP.  These descriptions are sketches and are
   certainly not complete, nor do we claim to describe all possible
   architectures.

6.1.  Architectures Without Handshakes

   We first consider architectures which do not involve any explicit
   handshake.  These systems have the advantage of being simple to
   design and implement but lack the flexibility benefits of a handshake
   scheme, as described in Section 5

6.1.1.  Single Static Key

   The simplest design is simply to use the same architecture as TCP
   MD5:  a single pairwise symmetric key used for all connections
   between two endpoints, but updating it to meet the requirements of
   Section 1.  This would imply the following changes:

   o  A description of how to add new MACs
   o  Support for a strong MAC (e.g., HMAC-SHA1)
   o  Some description of how to do key rollover (this can either be
      done with explicit identifiers or a trial verification hack like
      that described in [RFC4808].

   This mechanism would provide roughly similar architectural security
   properties to TCP MD5, except with stronger crypto, including an
   almost identical user interface and a very similar implementation.



Rescorla               Expires September 10, 2008               [Page 7]


Internet-Draft               TCP Auth. Arch                   March 2008


   As noted in Section 3, this still allows some measure of cut-and-
   paste attacks in between connections if they happen to have the same
   connection parameters (host/port quartet).

      The trial verification technique involves trying to verify
      segments with both key/algorithm pairs.  Once the newer key/
      algorithm pair verifies, that can be treated as the maximum
      sequence number at which the switchover occurred (it may have
      occurred earlier if packets were lost).  Note that in principle
      with this technique you could even use the same TCP MD5 option
      code point and bits on the wire with a stronger MAC.  Since TCP
      MD5 requires pairwise keys which must be manually configured, all
      that would be required would be to configure a pairwise algorithm.
      This is probably unwise because it reinterprets the meaning of the
      TCP MD5 option, but it shows how similar the two techniques are.

6.1.2.  Implicit Diversification

   A substantial amount of resistance to inter-connection cut-and-paste
   attacks can be achieved by exploiting connection information other
   than the host/port quartet.  For instance, one could start with a
   static key and use the TCP ISNs to produce a unique per-connection
   key:

   K_connection = HMAC(K_static, ISN_client || ISN_server)

   If we treat ISNs as random variates (note:  this does not require
   cryptographic randomness, just low probability of collisions) then
   there are 2^{64} equally probable ISN combinations between any pair
   of hosts, which implies 2^{64} potential keys (even if we ignore the
   host/port quartet), so the chance of two connection keys colliding
   becomes acceptably low:  on average there will be a collision after
   2^{32} connections.  If the host/port quartet is included, then
   collisions become even less probable.

      Note:  the ISNs are being used here serve the same role as nonces
      in standard cryptographic protocols (e.g., the ClientRandom and
      ServerRandom in TLS).  Therefore, the security model explicitly
      assumes that they are public information.  Thus, the sequence
      number predictability issues described on [RFC1948] do not impact
      the security of the system.  Only nonce uniqueness is required.

   This scheme has very similar security properties to the scheme
   described in Section 6.1.1, including having a compatible key
   management interface.  Unlike static keys, however, there is a
   significant amount of resistance to inter-connection cut-and-paste
   attacks because each connection with high probability uses a unique
   key.



Rescorla               Expires September 10, 2008               [Page 8]


Internet-Draft               TCP Auth. Arch                   March 2008


   As with any system that requires per-connection keys, this scheme
   would require some amount of per-connection state to store that key.
   This, and the hooks to feed the ISNs into the key computation, would
   presumably require some changes to implementations.

6.2.  Architectures with Handshakes

   We now consider architectures which involve explicit protocol
   handshakes between the two endpoints.  As noted in Section 5, this
   provides more flexibility and upgradeability but at significantly
   more protocol and implementation cost.  In addition, like all
   handshake methods, we would expect it to provide unique per-
   connection keys.  The difference between these architectures is in
   how the key management protocol messages are carried.

6.2.1.  Internal Key Management Protocol

   The traditional approach to this problem would be to build a KMP into
   TCP.  This would presumably entail designing a new crypto protocol
   (no small job) which is then carried in a TCP option.

   The primary advantage of this sort of design is that it allows for
   tight integration with TCP.  In general, tighter protocol integration
   allows for the provision of security services which are better tuned
   to the target protocol (cf. SRTP versus RTP over TLS).

   The primary disadvantage of this design is the large amount of effort
   involved, including:

      The cost of designing an entirely new protocol.
      The cost of integrating the crypto protocol into the TCP stack
      (which is more difficult than a normal crypto protocol because it
      is typically in the kernel.)

   In addition, this mechanism may be less flexible than other
   handshake-based systems.  First, many handshakes involve multiple
   round-trips between the client and server.  This is not a natural fit
   for the TCP handshake, which only involves three messages.  Other
   messages can potentially be piggybacked on empty TCP segments (bare
   ACKs), but their delivery properties would need careful study.
   [Note:  this also applies to the final handshake message, the ACK, so
   we may be reduced to a two message handshake.]

   Second, if the implementation is in the kernel, then this reduces
   one's ability to deploy public key-based mechanisms in the future
   (one of the major value propositions of a handshake mechanism),
   because the public key operations are too slow to run in the kernel
   while stalling all other operations.  This either requires a



Rescorla               Expires September 10, 2008               [Page 9]


Internet-Draft               TCP Auth. Arch                   March 2008


   multithreaded kernel or a piecewise/asynchronous public key
   computation (something that takes careful programming and that
   current crypto implementations don't do).

6.2.2.  External KMP

   The approach used by IPsec is to split the system into two pieces:

      A KMP establishes cryptographic associations (e.g., IKE).
      A standalone cryptographic transport protocol which relies on the
      associations created by the KMP (e.g., AH/ESP).

   This architecture has the advantage of decoupling (at least partly)
   the key management system from the protected transport protocol.  At
   least in principle this allows the KMP to be developed independently
   of the transport protocol, encouraging modular design and
   (potentially) mix-and-match between key management protocols and
   transport protocols.  The experience with IPsec suggests that both of
   these benefits may exist more in principle than in practice.  In
   particular, IKE has a fair amount of embedded knowledge about AH/ESP
   and as far as I know is not used to key any other transport protocol.
   That said, IKE is probably the only plausible candidate to be used in
   this fashion with TCP.

   A second advantage is that because the KMP is In separate, it is not
   tied to the dataflow of the transport protocol.  Thus, even though IP
   has no notion of reliable transport or even of associations, IKE is
   able to have reliable multi-message exchanges because it is
   transported separately.  In the case of TCP, this would mean that it
   would be straightforward to have an arbitrary number of key
   management messages without having to worry about TCP handshake
   dynamics.

   An additional advantage of having an external key management protocol
   is that it can be implemented separately from the transport protocol.
   For instance, conventional IPsec implementations have AH/ESP
   implemented in the kernel with IKE implemented in a userland daemon.
   This has obvious advantages in terms of the relative congeniality of
   the two environments, but also note that it allows the expensive PK
   operations to be done in the background without stalling the kernel.

   The major disadvantage of this design is the extremely loose coupling
   between the KMP and the transport protocol.  This manifests in at
   least three ways:

   o  The need for an association database to map keying material to the
      traffic it protects.




Rescorla               Expires September 10, 2008              [Page 10]


Internet-Draft               TCP Auth. Arch                   March 2008


   o  The difficulty of configuring settings and giving applications
      information about association properties.
   o  The need for interfaces to allow the transport protocol to request
      key establishment from the KMP and (potentially) to stall the
      transport protocol while keys are established.

   The last of these is probably more serious for TCP than for IPsec
   because an IPsec SA can be configured to connect a large number of
   different transport-level associations.  There may be a new key
   management protocol run for each TCP connection.  This may make
   stalling the transport protocol impractical, but then this
   exacerbates the problem of application visibility--how does the
   application know if the security association was set up or what its
   properties are?

   Another disadvantage is that if the transport of the key management
   protocol is decoupled from that of the transport protocol it is
   establishing keys for, then there may be ways for the key management
   protocol to fail (e.g., firewalls) but the transport protocol
   succeeds.

6.2.3.  Layered KMP

   Another way to provide a separate KMP is to bind it more tightly to
   the transport protocol by running it over (or next to, as in DTLS-
   SRTP [I-D.ietf-avt-dtls-srtp]) the transport protocol.  At the time
   that the association is created, the application initiating the
   association also initiates a KMP exchange over (next to) the
   transport protocol.  When the KMP terminates, it outputs keying and
   parameter information and imposes them on the association.  In the
   case of TLS over TCP, this would look something like:

               TCP Client                              TCP Server
               ----------                              ----------
               TCP SYN ------------------------------------->
                  <---------------------------------- TCP SYN/ACK
               TCP ACK ------------------------------------->
                  <--------- TLS Handshake (over TCP) ------>
        Keys to TCP                                         Keys to TCP
               App data (protected with TCP integrity) ----->
               <----- App data (protected with TCP integrity)

   The primary advantage of this type of system is that it has a tight
   binding to both the transport and to the application.  Because the
   KMP has the same transport parameters as the application layer
   protocol which will run over the transport and conceptually as the
   transport itself, they have a simple one-to-one relationship.




Rescorla               Expires September 10, 2008              [Page 11]


Internet-Draft               TCP Auth. Arch                   March 2008


      The application can control the cryptographic parameters directly.
      The application gets visibility into what parameters were
      established.
      The KMP fate-shares with the transport and application layer
      protocols.

   This architecture has two major disadvantages.  First, unlike all the
   other architectures discussed, it requires the cooperation of the
   application layer protocol and implementation.  This is the price
   that you pay for the tight application coordination.  Second, it
   creates a window of vulnerability during the period after the
   transport protocol connection has been established and before the KMP
   has run.  This is not an issue for injection attacks, provided that
   the application layer protocol state machine keeps track of which
   state it is in and reuses to accept un-integrity protected data (a
   standard issue in any application layer protocol when used with a
   channel security mechanism.)  However, DoS attacks on the connection
   are possible during this initial period, which provides a window for
   attack which does not exist with these other modes.

6.2.3.1.  TLS as a Layered KMP

   In the specific case of TLS, another advantage is that this can be
   treated by the application as if it were doing TLS over TCP.  The
   application can simply do TLS as it normally would provided that the
   API stack provides a mechanism for indicating that it wishes to also
   negotiate keys for TCP authentication.  Two models are actually
   possible here:

   In the first, TLS is used purely as a KMP and then it gets out of the
   way and data is sent "in the clear" over TCP with an integrity check.
   This has the advantage of efficiency, at a slight cost to the
   cleanness of the TLS model.

   In the second, the data is protected with TLS before being passed to
   TCP, where it is integrity checked again.  This is less efficient
   (because two MACs are performed) but slightly more compatible with a
   "just use TLS" model.  It also provides an opportunity for
   confidentiality if an appropriate cipher suite is used.


7.  Security Considerations

   This entire document is about security.







Rescorla               Expires September 10, 2008              [Page 12]


Internet-Draft               TCP Auth. Arch                   March 2008


8.  IANA Considerations

   This document has no IANA considerations.


9.  Informative References

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

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

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, May 1996.

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

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

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

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-00
              (work in progress), November 2007.

   [I-D.ietf-avt-dtls-srtp]
              McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for  Secure
              Real-time Transport Protocol (SRTP)",
              draft-ietf-avt-dtls-srtp-02 (work in progress),
              February 2008.

   [I-D.bellovin-tcpsec]
              Edddy, W., Bellovin, S., and R. Bonica, "Problem Statement
              and Requirements for a TCP Authentication Option",
               draft-bellovin-tcpsec-01.

   [WH05]     Wang, X. and H. Yu, "How to Break MD5 and Other Hash
              Functions",  EUROCRYPT 2005.




Rescorla               Expires September 10, 2008              [Page 13]


Internet-Draft               TCP Auth. Arch                   March 2008


Author's Address

   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA  94303
   USA

   Email:  ekr@rtfm.com










































Rescorla               Expires September 10, 2008              [Page 14]


Internet-Draft               TCP Auth. Arch                   March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Rescorla               Expires September 10, 2008              [Page 15]