Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2014 15:00:50 -0700

Hi, all,

Given a few recent discussions on TCP encryption alternatives, I figured 
I'd throw my view into the mix.

The following describes a variant of TCP-AO that, in addition to 
authenticating the TCP header and payload, also encrypts the payload.

It's a fairly simple approach that seems like it might be useful whether 
or not we consider other TCP encryption approaches.

Feedback welcome.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Date: Wed, 19 Mar 2014 14:53:35 -0700
From: [email-masked]
To: Dr. Joseph D. Touch <[email-masked]>, Joe Touch <[email-masked]>

A new version of I-D, draft-touch-tcp-ao-encrypt-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tcp-ao-encrypt
Revision:	00
Title:		A TCP Authentication Option Extension for Payload Encryption
Document date:	2014-03-19
Group:		Individual Submission
Pages:		7
URL: 
http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-00.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt/
Htmlized:       http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00

Abstract:
    This document describes an extension to the TCP Authentication
    Option (TCP-AO) to encrypt the TCP segment payload in addition to
    providing TCP-AO's authentication of the payload, TCP header, and IP
    pseudoheader. This extension changes how the packet contents and
    headers are processed and which keys are derived, but not its key
    coordination or protection of long-lived connections.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 21 Mar 2014 21:52:57 +0000

Joe,

Good to see this. 

Though it's still early to understand how  and why ENC is needed here;
 but  due to SDN/NFV/etc.. there are routing  specifications which talk about complete internal topology transport between AS'es or to  a central controller..

Frankly we were recently having this discussion internally and realized this extension could be useful.

Quick comments:

1.   TCP-AO NAT Extension  ==> Title inside the document says this..

2.   Given the in band processing AUTH/CIPHER by processors, it's better to give the flexibility  to have Symmetric/Stream 
      ciphers (remove the restriction) and yes, this requires introduction of  padding and pad length

3.   Section 3
     "...TCP-AO-NAT is intended
   for use only where coordinated between endpoints for connections
   that match the shared MKT parameters, as with all other MKT
   parameters."
   
   Should have been TCP-AO-ENC

4. Section 4.1
   We need another Master Key for Encryption.
   Else we may potentially get the same key for both AUTH and ENC if the same algorithm is used.

5. Section 4.1 - Something is missing here
   "   PTCP-AO-ENC processes TCP packets in the same way as TCP-AO, except
   that it replaces the authentication input and output processing as
   follows:.."

6.  Section 4.3. Per-Connection TCP-AO Parameters
     Yes, can use the same SendID, RecvID with encryption and still can have 2 Master Keys one for encryption and one for AUTH. 
     The quality (randomness requirements etc..) of the master key can be different for both purposes.

7.  Section 5.
     "..Note that the encryption
   initialization vector MAY depend on TCP header state, but MUST NOT
   depend on the processing of previous segments because segments may
   arrive (and need to be decrypted) out of order."

   IV is critical for some algorithms, this may need to be looked into further.
   I remember FIPS tests are very hard on this.

8. Section 7
    "Where are required algorithms specified? This doc or a separate one?"
   Separate.

--
Uma C.

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Wednesday, March 19, 2014 3:01 PM
To: [email-masked]
Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt

Hi, all,

Given a few recent discussions on TCP encryption alternatives, I figured I'd throw my view into the mix.

The following describes a variant of TCP-AO that, in addition to authenticating the TCP header and payload, also encrypts the payload.

It's a fairly simple approach that seems like it might be useful whether or not we consider other TCP encryption approaches.

Feedback welcome.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Date: Wed, 19 Mar 2014 14:53:35 -0700
From: [email-masked]
To: Dr. Joseph D. Touch <[email-masked]>, Joe Touch <[email-masked]>

A new version of I-D, draft-touch-tcp-ao-encrypt-00.txt has been successfully submitted by Joe Touch and posted to the IETF repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 15:04:58 -0700

> Though it's still early to understand how  and why ENC is needed here;

I'm not sure either, except that if you want it, you can do it nearly 
for free (i.e., in terms of extending the protocol) with the information 
you already have.

> but  due to SDN/NFV/etc.. there are routing  specifications which
> talk about complete internal topology transport between AS'es or to
> a central controller..

AOK - SDN is definitely a good example.

> 1.   TCP-AO NAT Extension  ==> Title inside the document says this..

Yeah - I reused the template and didn't figure that out before I sent 
it. I'll fix in the next rev.

>        ciphers (remove the restriction) and yes, this requires introduction of  padding and pad length

But we can't pad; that would potentially run up against MTU 
considerations, as well as needing support for a length field somewhere 
(i.e., it'd change the option header too).

>     Should have been TCP-AO-ENC

Yup - will fix.

>     Else we may potentially get the same key for both AUTH and ENC if the same algorithm is used.

It seems simpler to either salt the algorithm when used for encryption 
key derivation, or declare that the two keys must use different algs.

>     that it replaces the authentication input and output processing as

It's complete, but poorly worded; I'll fix.

>       The quality (randomness requirements etc..) of the master key can be different for both purposes.

Yes, but as noted above it just makes the MKT larger with no clear benefit.

Besides, if we salt the algs differently we would avoid a clash where 
the same key is used twice. If we leave it to the user to provide two 
keys, they may provide the same key for both encryption and auth.

>     I remember FIPS tests are very hard on this.

Right, which is why we would need to take that into consideration if 
needed based on the alg, but that's an alg-specific consideration.

>      "Where are required algorithms specified? This doc or a separate one?"

Preference noted. I tend to agree, FWIW.

Thanks for the feedback.

Joe

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 21 Mar 2014 23:20:29 +0000

2 quick comments in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, March 21, 2014 3:05 PM
To: Uma Chunduri; [email-masked]
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt

...
> introduction of  padding and pad length

But we can't pad; that would potentially run up against MTU considerations, as well as needing support for a length field somewhere (i.e., it'd change the option header too).

[Uma]: Sure. Padding is needed for 2 reasons
1. Based on the algo to make it to the block size boundary
2. Also sometimes hardware crypto engines require 4 byte boundary.
Well, this should be seen bit more depending on the algorithms proposed for both ENC and KDF.

...

Yes, but as noted above it just makes the MKT larger with no clear benefit.
Besides, if we salt the algs differently we would avoid a clash where the same key is used twice. If we leave it to the user to provide two keys, they may provide the same key for both encryption and auth.

[Uma]: Right, in manual mode. But it's possible this could be provisioned  through KMP and master  key quality could be  central to the ENC (can quickly become serious security requirement).
            If it's manual nothing much can be done, if you start with poor quality (of course guidance should be provided)

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Mar 2014 16:25:54 -0700

...
> 2. Also sometimes hardware crypto engines require 4 byte boundary.

That's true only for non-stream cyphers.

> Well, this should be seen bit more depending on the algorithms proposed for both ENC and KDF.

We can pad for the KDF, but not the ENC alg. Option processing really 
should never change the size of the TCP payload.

>              If it's manual nothing much can be done, if you start with poor quality (of course guidance should be provided)

Let's hear back from others, perhaps during security review on this. 
It's not a big issue to do either method, but they're not compatible 
(both sides need to do the same thing).

I'll see if I can come up with a way of describing things that allows 
two master keys that could be identical and could use the same PRKs but 
are still sufficiently distinct; that way if the OOB key alg wants to 
negotiate different master keys it can.

Joe