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

[Eric Rescorla <ekr at networkresonance.com>]

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

> Eric Rescorla wrote:
> >> 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

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.


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

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


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

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.


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

See S 6.1.2.

   K_connection = HMAC(K_static, ISN_client || ISN_server)

-Ekr