[tcpm] discussion of draft-rescorla-tcp-auth-arch-00.txt

Eric,

Again, thanks for the detailed comments. Discussion below...

This too should be useful to discuss further in TCPM.

Joe

> 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
...
> 1.  Introduction
...
>    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 documents were presented at the last IETF, where we solicited 
comments on those requirements. The requirements were presented as 
having the consensus of the TCP-AO design team only at that time.

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

TCP-AO is identical to IPsec [i.e., 4301] in that regard; neither 
arranges for keys, and both rely on a separate protocol to do so, in the 
sense that IPsec relies on IKE.

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

Changing keys is not related to the above key reuse issue AFAICT.

Key changes are to reduce the amount of material signed under a single 
key, to reduce the utility of signed packets to a cryptoanalyst.

Key reuse is critical to preventing replay attacks within a connection 
ID (src IP, dst IP, src port, dst port, aka socket pair). It is useful 
to avoid keying different ports or even different hosts with the same 
key, but only in a general sense (i.e., to again reduce the amount of 
material signed with a single key).

>    o  To arrange for different cryptographic keying material to be used
>       for each connection, thus preventing cut-and-paste attacks between
>       connections.  (Good)

Those don't seem relevant; the ports change, so the signatures would change.

>    o  To allow rekeying in case of key compromise.  (Good)

Rekeying of a connection is not necessarily related to rekeying an 
endpoint. Connection key compromise is not something we're designing to 
address per se.

>    o  To limit the amount of plaintext/MAC pairs available to the
>       attacker (Not-so-good)

Is that the 'amount of keyed material' kind of stuff above? That was 
given by Bellovin as an issue with TCP-MD5.

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

We definitely do not want to tie the keying directly to the sequence 
space for a variety of reasons (we listed some, I believe); this is done 
indirectly by bytecounts or packet counts to trigger key changes.

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

That would be allowed if the key management system used a single master 
endpoint key, and derived connection keys from that key. I.e., if this 
is critical to BGP, then BGP will require TCP-AO and a specific key 
management protocol. Again, this isn't different from saying "IPsec with 
IKE" at the IP layer, except that we are intending that TCP-AO and its 
key management system are simpler to implement (partly because they're 
specific to a single transport protocol).

> 5.  Handshake and Capabilities Discovery
> 
>    The ability to automatically discover a peer's capabilitiies is a
>    common feature of modern cryptographic protocols. \

Like IPsec, we rely on the key management protocol to perform this. This 
is not a part of TCP-AO as a result.

> 6.  Potential Architectures
> 
>    This section describes a number of potential architectures for key
>    management for TCP.

I'll skip them here, excepting ones that affect TCP-AO:

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

TCP option space is already consumed by a number of commonly used 
options, and we want to retain space for additional options where 
possible. Space is most limited in the SYN packet, which is where the 
initial key exchange would occur.

Because there isn't enough TCP option space for this sort of solution, 
we excluded it as a possibility.
...
> 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)

This fails to protect the SYN exchange, which we consider a requirement. 
It also changes state from non-keyed to keyed; it would be very 
difficult to introduce that sort of stateful change inside the TCP 
protocol in ways that affect the data stream, since no other options 
have that kind of effect (i.e., of affecting all data after some point).

---

[tcpm] discussion of draft-rescorla-tcp-auth-arch-00.txt

Attachment: signature.asc