Subject: [tcpm] SHA-2 auth draft on TCP-AO

From: "Sujeet Nayak A (sua)" <[email-masked]>
Date: Tue, 3 Jun 2014 07:21:27 +0000

Hi,
In the last few months, we have been seeing a lot of customer interest for SHA-2 based auth on TCP-AO enabled connections. In this regard, we (Brian Weis and myself) have posted a draft for the same:
http://tools.ietf.org/html/draft-nayak-tcp-sha2-00

Pl. review and let me know your valuable comments.

Regards,

Sujeet Nayak A.

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Jun 2014 11:11:26 -0700

Hi, Sujeet,

This doc should, AFAICT, update RFC 5926

It should also provide motivation for the need for SHA-2 - i.e., some of 
the discussion in the Security Considerations section should be 
mentioned in the abstract and explained in detail in the body (e.g., 
sections 1 or 2).

Please scrub the use of RFC2119 language - I saw a couple of uses of the 
magic words that were not capitalized but should have been.

IMO, the doc should also provide advice as to the necessity of these 
algorithms - are they MUST (likely not), SHOULD (probably not either), 
or MAY implement?

Joe

On 6/3/2014 12:21 AM, Sujeet Nayak A (sua) wrote:
> Hi,
> In the last few months, we have been seeing a lot of customer interest
> for SHA-2 based auth on TCP-AO enabled connections. In this regard, we
> (Brian Weis and myself) have posted a draft for the same:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Sujeet Nayak A (sua)" <[email-masked]>
Date: Wed, 18 Jun 2014 12:04:34 +0000

Hi Joe,

>>This doc should, AFAICT, update RFC 5926
[SUJEET]: Brian would be responding to this one.

>>It should also provide motivation for the need for SHA-2 - i.e., some
>>of the discussion in the Security Considerations section should be
[SUJEET]: Sure, will make the changes as described above.

>>Please scrub the use of RFC2119 language - I saw a couple of uses of
>>the magic words that were not capitalized but should have been.
[SUJEET]: Sure, will look for these and make changes.

>>algorithms - are they MUST (likely not), SHOULD (probably not either),
[SUJEET]: Section 2.2 has the recommendation. Pl. let us know if you were
expecting this at any other place, and I can add it.

Thanks again for your feedback.

Regards,

Sujeet & Brian

---

From: Brandon Williams <[email-masked]>
Date: Wed, 18 Jun 2014 09:29:51 -0400

Hi Sunjeet,

The mac lengths of the algorithms specified here increase the option 
size, don't they? There is a detailed discussion of the option space 
tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact 
that all mac lengths would be 96 bits. An I.D. that increases the 
possible mac lengths should probably revisit that discussion.

In particular, the use of a 256 bit mac length would mean that the most 
commonly used TCP options must be discarded in favor of TCP-AO. On the 
SYN, you would have just enough room for MSS and that's it. On systems 
that word align options, there isn't even enough space available for a 
128 bit mac length on the SYN, and such systems would also be unable to 
support both timestamps and SACK.

Regards,
--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Brian Weis <[email-masked]>
Date: Wed, 18 Jun 2014 09:12:38 -0700

Hi Joe,

>>> This doc should, AFAICT, update RFC 5926

We're proposing updates to the IANA registries to add new algorithms, but it is not our goal to change the requirements language in RFC 5926. I was recently given advice by IESG members that if an I-D doesn't propose changes to the base RFC, then the new I-D isn't considered an "update" to it.

There isn't any compelling reason to change the existing algorithm requirements as both algorithms remain acceptable. We should clarify that the algorithm recommendations are really only relevant when this Internet-Draft is implemented. An implementation of TCP-AO still is required to comply with RFC 5926, but if it also implements this draft then it would need to pay attention to the algorithm recommendations in this draft. We'll add some text pointing this out, to make it clear this does not need to be considered an update to RFC5926.

Thanks,
Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 10:31:37 -0700

> Thanks a lot of your quick and valuable comments:
...
> expecting this at any other place, and I can add it.

It should definitely be reiterated in the abstract and intro.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 10:30:55 -0700

On 6/18/2014 9:12 AM, Brian Weis wrote:
> We're proposing updates to the IANA registries to add new
> algorithms,but it is not our goal to change the requirements language in RFC 5926.

RFC 5926 indicates the security algs for TCP-AO; this doc proposes to 
augment that list. Yes, that's captured by the IANA registry, but the 
way RFC 5926 is written appears to indicate that additions to that 
registry should UPDATE that RFC. If the WG or IESG sees otherwise, 
that's fine with me.

> There isn't any compelling reason to change the existing algorithm
> requirements as both algorithms remain acceptable. We should clarify
> that the algorithm recommendations are really only relevant when this
> Internet-Draft is implemented. An implementation of TCP-AO still is
> required to comply with RFC 5926, but if it also implements this draft
> then it would need to pay attention to the algorithm recommendations in
> this draft.

That's how all RFCs work, though. It would certainly be useful to be 
more clear about the impact of this doc - i.e., that it adds additional 
optional algorithms, rather than deprecating existing ones.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 10:37:59 -0700

> possible mac lengths should probably revisit that discussion.

+1.

I ought to be trivial to have this approach truncate the MAC, as other 
algorithms do, and for the same reason.

Joe

---

From: Brian Weis <[email-masked]>
Date: Wed, 18 Jun 2014 11:46:45 -0700

Hi Joe & Brandon,

On Jun 18, 2014, at 10:37 AM, Joe Touch <[email-masked]> wrote:

> I ought to be trivial to have this approach truncate the MAC, as other algorithms do, and for the same reason.

The proposed methods do already truncate the output down to the minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC output.

Brian 

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jun 2014 11:53:50 -0700

On 6/18/2014 11:46 AM, Brian Weis wrote:
> The proposed methods do already truncate the output down to the
> minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC
> output.

IMO if they cannot be truncated to 96 bits for this use then they are 
not appropriate for TCP-AO. Using a longer HMAC directly in the TCP-AO 
field would require this doc to UPDATE RFC 5925, as well as addressing 
the comments already made on the impact of using the additional space, 
and I don't think that's a good idea.

Joe

---

From: Brian Weis <[email-masked]>
Date: Fri, 20 Jun 2014 09:11:54 -0700

Hi Joe,

On Jun 18, 2014, at 11:53 AM, Joe Touch <[email-masked]> wrote:

> IMO if they cannot be truncated to 96 bits for this use then they are not appropriate for TCP-AO. Using a longer HMAC directly in the TCP-AO field would require this doc to UPDATE RFC 5925, as well as addressing the comments already made on the impact of using the additional space, and I don't think that's a good idea.

I understand the concerns of using too much option space. But can you point me to the requirements language requires a maximum of 96 bits for the MAC? Although that may have been your intent, I can find no such requirement in either RFC 5925 or RFC 5926.

Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Jun 2014 11:04:08 -0700

On 6/20/2014 9:11 AM, Brian Weis wrote:
>> IMO if they cannot be truncated to 96 bits for this use then they
>> are not appropriate for TCP-AO. Using a longer HMAC directly in the
>> TCP-AO field would require this doc to UPDATE RFC 5925, as well as
>> addressing the comments already made on the impact of using the
>> additional space, and I don't think that's a good idea.
>
> I understand the concerns of using too much option space. But can
> you point me to the requirements language requires a maximum of 96
> bits for the MAC? Although that may have been your intent, I can find
> no such requirement in either RFC 5925 or RFC 5926.

You're correct; TCP-AO allows MACs of (nearly) any length. We had a 
discussion on the lengths specified for the specific algorithms in RFC 
5926, and came up with 96 bits. The key question here is "why should 
these algorithms be different"?

Joe