Re: [Ntp] Eric Rescorla's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

On Fri, Jan 4, 2019 at 12:53 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Jan 4, 2019 at 9:49 AM Aanchal Malhotra <aanchal4@bu.edu> wrote:
>
>> HI Eric,
>>
>>
>>
>> On Fri, Jan 4, 2019 at 12:25 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>>
>>>
>>> On Fri, Jan 4, 2019 at 8:24 AM Aanchal Malhotra <aanchal4@bu.edu> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Thanks for the comments.
>>>>
>>>> On Sat, Nov 17, 2018 at 5:59 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>>> Eric Rescorla has entered the following ballot position for
>>>>> draft-ietf-ntp-mac-05: No Objection
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> COMMENT:
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Rich version of this review at:
>>>>> https://mozphab-ietf.devsvcdev.mozaws.net/D3591
>>>>>
>>>>>
>>>>>
>>>>> COMMENTS
>>>>> S 3.
>>>>> >      If authentication is implemented, then AES-CMAC as specified in
>>>>> RFC
>>>>> >      4493 [RFC4493] SHOULD be computed over all fields in the NTP
>>>>> header,
>>>>> >      and any extension fields that are present in the NTP packet as
>>>>> >      described in RFC 5905 [RFC5905].  The MAC key for NTP MUST be at
>>>>> >      least 128 bits long AES-128 key and the resulting MAC tag MUST
>>>>> be at
>>>>> >      least 128 bits long as stated in section 2.4 of RFC 4493
>>>>> [RFC4493].
>>>>>
>>>>> Is there a way for either of these values to be > 128 bits? If not,
>>>>> maube just say "must be 128 buts:
>>>>>
>>>>
>>>> How about the following?
>>>> "The MAC key for NTP MUST be 128 bits long AES-128 key and the
>>>> resulting MAC tag MUST be at least 128 bits long as stated in section 2.4
>>>> of RFC 4493 [RFC4493]."
>>>>
>>>> This is to make sure that the MAC tag is not truncated to < 128 bits.
>>>>
>>>
>>> As I understand it, this text is specifying just AES-CMAC (otherwise the
>>> text about it being an AES key doesn't make sense) and AES-CMAC has a 128
>>> bit output. And thus the "at least 128 bits" text  doesn't do anything and
>>> just says "MUST be 128 bits".
>>>
>>
>> I see what you are saying but here is what I am worried about. Section
>> 2.4 of RFC 4493 says the following:
>>
>> "It is possible to truncate the MAC. According to [NIST-CMAC
>> <https://tools.ietf.org/html/rfc4493#ref-NIST-CMAC>], at least a 64-bit
>> MAC should be used as protection against guessing attacks. "
>>
>> And I do not want to NTP MAC tag to be truncated to < 128 bits. So here
>> is a possible rephrasing:
>>
>
> Well, I'm not quite sure why you think truncating is bad in this case, but
> ignoring that.
>
> "The MAC key for NTP MUST be 128 bits long AES-128 key and the resulting
>> MAC tag MUST be 128 bits long as stated in section 2.4 of RFC 4493
>> [RFC4493]. Truncation as permitted in Section 2.4 of RFC 4493 MUST not be
>> used. "
>>
>> What do you think?
>>
>
> This just seems redundant. You can't use truncation and have the MAC be !=
> 128 bits, and your first sentence says it's 128 bits long.
>

I want to make the point clear but also agree that redundancy is bad. So
how about the following:

"The MAC key for NTP MUST be 128 bits long AES-128 key.  Truncation as
permitted in Section 2.4 of RFC 4493 [RFC4493] MUST not be used and
therefore the resulting MAC tag MUST be 128 bits long."

>
> -Ekr
>
>
>>> -Ekr
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ntp
>>>
>>