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

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.

-Ekr

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