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

[Joe Touch <touch at ISI.EDU>]

Eric Rescorla wrote:
...
> > > 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.
>
> It's similar to IPsec but not identical, in that IPsec's notion of an
> 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.

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

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

> > Key changes are to reduce the amount of material signed under a single 
> > 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.

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

> > 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).
>
> I'm not sure which issue you're referring to here by "within a socket
> pair".

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.

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

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
> second case, again discussed in S 3.1, but it's not clear to
> me how important this actually is.

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.

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

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

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

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.

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm