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

On Fri, Jun 20, 2014 at 11:04 AM, Joe Touch <touch@isi.edu> wrote:

>
>
> On 6/20/2014 9:11 AM, Brian Weis wrote:
>
>> Hi Joe,
>>
>> On Jun 18, 2014, at 11:53 AM, Joe Touch <touch@isi.edu> wrote:
>>
>>
>>>
>>> On 6/18/2014 11:46 AM, Brian Weis wrote:
>>>
>>>> Hi Joe & Brandon,
>>>>
>>>> On Jun 18, 2014, at 10:37 AM, Joe Touch <touch@isi.edu> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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