Subject: [tcpm] Joe Touch: [Tsvwg] new I-D: TCP Simple Authentication Option

From: Mark Allman <[email-masked]>
Date: Mon, 12 Jun 2006 13:15:33 -0400

fyi

Subject: [Tsvwg] new I-D: TCP Simple Authentication Option
From: Joe Touch <[email-masked]>
To: [email-masked]
Date: Fri, 09 Jun 2006 15:01:26 -0700
List-Id: Transport Area Working Group <tsvwg.ietf.org>

Hi, all,

The following I-D has just been submitted. It is intended to provide a
simpler alternative to updating TCP/MD5. Comments welcome.

It is currently available at:
http://www.isi.edu/touch/pubs/draft-touch-tcpm-tcp-simple-auth-00.txt
(and should appear in the usual places very shortly)

Joe and Allison

---------------------------------------------------

TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Expires: December 2006                                        A. Mankin
                                                           June 9, 2006

                   The TCP Simple Authentication Option
                  draft-touch-tcpm-tcp-simple-auth-00.txt
...
Abstract

   This document specifies a TCP Simple Authentication Option (TCP-SA)
   which is intended to replace the TCP MD5 Signature option of RFC-2385
   (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and
   provides more details on the association of security associations
   with TCP connections. TCP-SA assumes that rekeying is supported by
   restarting the TCP connection, and so omits in-band parameter
   negotiation, session key establishment, and rekeying support; where
   such features are desired, use of the IPsec suite is recommended.
   The result is intended to be a simple modification to support current
   infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to
   support a larger set of hashes with minimal other system and
   operational changes. TCP-SA requires no new option identifier, though
   it is intended to be mutually exclusive with TCP/MD5 on a given TCP
   connection.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Jun 2006 10:20:42 -0700

Hi, all,

Yes - I had intended to forward this post to TCPM too ;-)

The doc is hoped to be a TCPM WG standards-track item, *if* we decide
that fixing TCP/MD5 is useful. An alternative approach, of course, is to
encourage the use of IPsec instead; that doc, IMO, ought to come out of
SAAG rather than TCPM or even TSVWG, however.

Joe

Mark Allman wrote:
> fyi
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [Tsvwg] new I-D: TCP Simple Authentication Option
> From:
> To:
> [email-masked]
> To:
> [email-masked]
> ------------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 12 Jun 2006 14:34:21 -0400

Joe,

In your approach, how would you address the problem of rekeying on the
PE-CE interface, where Graceful Restart is least likely to be available
and IPSec may be impractical?

Also, in Section 4, you say that "Middleboxes may alter TCP options
en-route are a kind of attack and would be successfully detected by
TCP-SA". How would you deal with situations in which the owner of one or
both TCP peers put the middle box in-line, intentionally?

                               Ron

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Jun 2006 11:39:05 -0700

> and IPSec may be impractical?

The doc is clear on this - it assumes either graceful restart or an
application that can handover between two TCP connections itself.

> both TCP peers put the middle box in-line, intentionally?

That's an attack that would be successfully detected. ;-)

The alternative would be to allow options to be either signed or
unsigned on a per-connection basis; that 'bit' ought to be pre-shared
along with the key and algorithm if so. That can easily be added.

Joe

---

From: Andrew Lange <[email-masked]>
Date: Mon, 12 Jun 2006 12:47:36 -0700

Hi Joe,

The main reason for the TCP extended auth proposal is the ability to  
rollover keys without taking the session down.  Adding additional,  
more secure algorithms is a secondary goal.

A key attack vector our customers are concerned about is the  
disgruntled employee let go or other compromise of the key list.   
They need to be able to change the keys without interrupting the  
session and causing routing to suffer.  Without this, a new mechanism  
is not particularly useful.

Andrew

On Jun 12, 2006, at 10:20 AM, Joe Touch wrote:

>> TCPM WG                                                        J.  
>> Touch
>> Internet Draft                                                   
>> USC/ISI
>>                                                            June 9,  
>> 2006

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Jun 2006 12:53:44 -0700

Andrew Lange wrote:
> rollover keys without taking the session down.  Adding additional, more
> secure algorithms is a secondary goal.

I can update my draft to correct that impression.

> A key attack vector our customers are concerned about is the disgruntled
> employee let go or other compromise of the key list.  They need to be
> able to change the keys without interrupting the session and causing
> routing to suffer.  Without this, a new mechanism is not particularly
> useful.

See my draft regarding the ability of routing to accommodate session
changes.

Joe