Subject: [saag] discussion of draft-rescorla-tcp-auth-arch-00.txt

From: Joe Touch <[email-masked]>
Date: Mon, 10 Mar 2008 18:30:02 -0700

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

---

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 07:52:20 -0400

At Mon, 10 Mar 2008 18:30:02 -0700,
> having the consensus of the TCP-AO design team only at that time.

Sure. I was just trying to say that I wasn't taken them as a given
for the purposes of this document.

> sense that IPsec relies on IKE.

It's similar to IPsec but not identical, in that IPsec's notion of an
association spans multiple TCP connections.

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

Well, part of my point in this section is to distinguish these
cases in which one might or might not wish to use different
keys at different times.

> key, to reduce the utility of signed packets to a cryptoanalyst.

As I indicate in S 3.3, while this is certainly crypto lore for
symmetric ciphers, I am unaware of any evidence that having
large (but practical) numbers of plaintext/ciphertext pairs 
is of any significant value in attacking modern algorithms.

> material signed with a single key).

I'm not sure which issue you're referring to here by "within a socket
pair".

- With a single connection.
- Between connections which happen to share parameters by coincidence.

As I indicate in S 3.1, there's no replay issue in the first case
except for TCP sequence number rollover, which can be fixed by
using extended sequence numbers. The relevant issue is the
second case, again discussed in S 3.1, but it's not clear to
me how important this actually is.

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

Yes, I'm talking about the second of the two issues above.

> given by Bellovin as an issue with TCP-MD5.

Yes, presumably. As I say, I'm unaware of any cryptographic issue
here.

> indirectly by bytecounts or packet counts to trigger key changes.

The only mention of sequence number in your draft is in S 9:

   Value (ICV). In TCP-AO, 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-AO 
   authentication calculation, because many out-of-window segments still 
   cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is 
   similarly not useful to add a separate Sequence Number field to the 
   TCP-AO option, because doing so could cause a change in TCP's 
   behavior even when segments are valid. 

But this is not what I'm talking about. I'm merely talking about
using the ISNs as a diversifier for the per-connection key.
Could you elaborate more on issues with this.

> we excluded it as a possibility.

I tend to agree that this is not that attractive an alternative.

> This fails to protect the SYN exchange, which we consider a requirement. 

I certainly agree that it does not protect the SYN. I noted it as
the second major disadvantage. As for whether this is a requirement,
I think that's deserving of some discussion.

> have that kind of effect (i.e., of affecting all data after some point).

I'm no expert on TCP options and I'm certainly prepared to believe
that no other options have this effect, but I'm not sure I see
the issue here as to why this is a problem. The sides can simply
place the option in the segment keyed with some null key and
algorithm (e.g., all zero MAC) and then start processing when
the key is set. As I recall, a similar algorithm is used in
SCTP-AUTH.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2008 05:17:15 -0700

Eric Rescorla wrote:
...
> association spans multiple TCP connections.

There are numerous differences, however, regarding the statement "does 
not arrange for) a fresh key for each association", they are identical IMO.

> cases in which one might or might not wish to use different

Agreed. Unless your doc is intended to be longer term, it's not an issue.

> is of any significant value in attacking modern algorithms.

That lore is expressed in RFC3562,and implied in RFC4107 in the phrase 
"short term" key. We'd be glad to be advised otherwise; if so, then:

	- we could note that the key-ID would be used only for
	deliberate key changes, e.g., due to compromise, or to
	avoid a key rollover replay attack

		note: this is also why we need a byte/segment
		counter; when it hits 2^32, we MUST change
		keys or there is a clear replay attack

	- we could ignore the reuse of keys across different
	connections within the same machine, though we'd still
	want to avoid reuse within a connection ID due to replay
	attacks

> I'm not sure which issue you're referring to here by "within a socket

It's defined in RFC793 as [srcIP, dstIP, srcport, dstport]; it defines a 
TCP connection, and noted as such in sec 3 of the tcp-auth I-D.

> using extended sequence numbers. 

TCP does not have extended sequence numbers. Adding that 
cross-connection information, and including it in every tcp-opt header, 
was explored but is decided against for numerous reasons.

> The relevant issue is the

That's why we believe it's sufficient to address this at the TSAD, 
requiring keys to change when connections end and new ones start with 
the same port numbers. That can be accomplished in various ways, e.g., by:
	- forcing a TSAD key change
	- keeping a cache of previous TSAD keys for that connection
	etc.

The first one above might be sufficient - and simple to implement - if 
this is not a severe concern.

...
>    behavior even when segments are valid. 

Thanks for rechecking; we can add text to capture our previous thoughts 
on this, though, as you note below, that's not important here.

> Could you elaborate more on issues with this.

Are you suggesting instead to retain the ISN for a connection and use it 
in the crypto alg? TCP doesn't currently require any specific entropy in 
the ISN change; if it's sufficient that it change, this might be a way 
to achieve the lack of key reuse.

> the key is set. As I recall, a similar algorithm is used in

We'll raise that today at TCPM, but I expect that all state associated 
with a TCP connection will continue to be negotiated solely at SYN time. 
Agreed that this is not the case for other stateful protocols.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 08:38:51 -0400

At Tue, 11 Mar 2008 05:17:15 -0700,

> 		keys or there is a clear replay attack

As I stated in my original document, this is not correct. You simply
treat the sequence number as 64 bits long with only the low order
32-bits represented on the wire, but include the entire sequence
number in the MAC. The relevant technique is described in RFC 4304.

> was explored but is decided against for numerous reasons.

As noted above, this is not included on the wire. 

> this is not a severe concern.

Well, you're assuming that it's something we need to do at all. Given
that it comes at some cost, I think it should be discussed first.

> in the crypto alg? 

See S 6.1.2.

   K_connection = HMAC(K_static, ISN_client || ISN_server)

-Ekr