Subject: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO")

From: Gregory Lebovitz <[email-masked]>
Date: Tue, 30 Sep 2014 16:19:05 -0700

On Fri, Jun 20, 2014 at 11:04 AM, Joe Touch <[email-masked]> wrote:

>
>
> On 6/20/2014 9:11 AM, Brian Weis wrote:
>
>> Hi Joe,
>>
>> On Jun 18, 2014, at 11:53 AM, Joe Touch <[email-masked]> wrote:
>>
>>
>>>
>>> On 6/18/2014 11:46 AM, Brian Weis wrote:
>>>
>>>> Hi Joe & Brandon,
>>>>
>>>> On Jun 18, 2014, at 10:37 AM, Joe Touch <[email-masked]> wrote:
>>>>
>>>>
>>>>>
>>>>> On 6/18/2014 6:29 AM, Brandon Williams wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> +1.
>>>>>
>>>>> 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.
>>>>
>>>
>>> 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"?

GML> 5296, 3.2 states:

   - MAC_Length:  The final length of the bits used in the TCP-AO MAC
                  field.  This value may be a truncation of the MAC
                  function's original output length.

GML> and

An important aspect to note about these algorithms' definitions for
   use in TCP-AO is the fact that the MAC outputs are truncated to 96
   bits.  AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1
   produces a 160-bit result.  The MAC output is then truncated to 96
   bits to provide a reasonable trade-off between security and message
   size, for fitting into the TCP-AO option field.

GML>  we clearly didn't say "MUST be 96 bits, no more", but the last
sentence was meant to guide people toward a truncation of the MAC down to
96-bits in order to fit nicely into the -AO option field. There was
security review and consensus that truncating a MAC output > 96 bits would
be fine.

GML>  Further, we specifically used known and crypto-industry-vetted
specifications for MACs with 96 bit output truncations, to ensure that
there would be no crypto issues truncating either MAC down to 96 bits.

GML> I haven't researched it, but is there a published NIST spec for
HMAC-SHA-256-96. I know there is HMAC-SHA-256-128 in RFC 4868. Are there
issues simply truncating further from 128 to 96? (Though I authored the
doc, I'm not a cryptographer, so if this is a ridiculous statement to said
community, pls forgive my ignorance :-)

GML> NOTE: Regardless of the HMAC truncation, the variant PRF (e.g.
PRF-HMAC-SHA256) would be un-truncated.

GML> Gregory

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

-- 
----
IETF related email from
Gregory M. Lebovitz

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Sep 2014 16:54:33 -0700

On 9/30/2014 4:19 PM, Gregory Lebovitz wrote:
...
> sentence was meant to guide people toward a truncation of the MAC down
> to 96-bits in order to fit nicely into the -AO option field. 

The -AO option supports any MAC length. The issue is conservation of TCP
header option space and its interaction with other TCP options.

> There was
> security review and consensus that truncating a MAC output > 96 bits
> would be fine.

"fine" was determined at the time by both Security and Transport, i.e.,
Security felt it was large enough for the desired protection and
Transport felt it was small enough to "play nice" with other options.

Joe