Subject: [Ntp] Adam Roach's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 19 Nov 2018 22:48:15 -0800

Adam Roach 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:
----------------------------------------------------------------------

Thanks to everyone who worked on this document.

I agree with Mirja's concerns about the backwards compatibility aspects,
especially from an operational perspective -- in particular, is there some way
to roll this change out incrementally, or does it require a flag day? It seems
to me that this document really needs an "operational considerations" section
that either explains how this change might be deployed or cites some already
existing NTP document that does so.

I also have a handful of minor and editorial comments that you may want to
consider addressing.

---------------------------------------------------------------------------

Please consider addressing these id-nits issues:

  ** The abstract seems to contain references ([RFC5905], [RFC4493]), which
     it shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  -- The draft header indicates that this document updates RFC5905, but the
     abstract doesn't seem to directly say this.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please update to use the boilerplate in RFC 8174.

---------------------------------------------------------------------------

§3:

>  A symmetric key is a triplet of ID,
>  type (e.g.  MD5, AES-CMAC) and the key itself.

I don't follow this. A naïve reading of this sentence would lead me to believe
that the key contains three fields, one of which is itself.  I suspect you're
using "key" here to refer to two somewhat different constructs.  Consider
giving them more unique names.

---

From: Hal Murray <[email-masked]>
Date: Tue, 20 Nov 2018 12:07:57 -0800

> especially from an operational perspective -- in particular, is there some
> way to roll this change out incrementally, or does it require a flag day? It
> seems to me that this document really needs an "operational considerations"
> section that either explains how this change might be deployed or cites some
> already existing NTP document that does so. 

No flag day.  The config files specify the crypto algorithm.  Current code 
supports MD5 and SHA1.   AES128CMAC gets added.

If you are thinking about that area, I'd worry about the opposite.  As far as 
I can tell, crypto isn't used much.  News about a new RFC isn't likely to get 
to the admins who are actually in charge of the machines using it so they will 
continue to use whatever they are currently using.

-- 
These are my opinions.  I hate spam.

---

From: Paul Gear <[email-masked]>
Date: Wed, 21 Nov 2018 09:15:21 +1000

> continue to use whatever they are currently using.

I think Hal has the long and short of it, operationally speaking.

I've been in operational roles for much of my career, and I've never
seen NTP crypto deployed in production.  Many (most?) places don't even
care about NTP enough to read the documentation to understand how or why
to configure it well, and only touch it when it's badly broken enough to
affect their production applications.

Any operational considerations should easily be handled by an entry in
the implementation's release notes saying how to switch crypto algorithms.

Paul

---

From: Kyle Rose <[email-masked]>
Date: Wed, 21 Nov 2018 13:01:12 -0500

I think the objection about backwards compatibility is more easily
addressed by noting that deployments currently using MD5 authentication
have a pre-existing relationship that presumes the existence of pre-shared
keys and an implied agreement on MD5. If a new version of the software
allows for selection of the MAC algorithm on a per keyid basis, then there
is a natural rollout path that does not require an atomic upgrade of all
servers in a cluster. (keyid here refers to section 7.3 of RFC 5905.)

So, one potential rollout option is to upgrade all NTP servers in a mutual
trust network, keeping the existing keyid, key, and algorithm (MD5) but
adding an additional keyid, key, and algorithm (AES-CMAC). Once the
software upgrade is complete, alter the servers' configurations to use the
new keyid. This kind of two-phase commit is less flexible than online
negotiation of cipher suites, but it seems fine given the constraints of an
existing wire image and the need to be backwards-compatible. I have not
looked at either the code or the config to know if the necessary degree of
algorithmic agility is currently supported, but I can't imagine it would be
difficult to add.

Other use cases should look to NTS.

Kyle

On Tue, Nov 20, 2018 at 3:08 PM Hal Murray <[email-masked]> wrote:

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

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 21 Nov 2018 16:02:11 -0800

> servers in a cluster. (keyid here refers to section 7.3 of RFC 5905.)

The keyid has ALWAYS been tied to the algorithm and the key.  Nothing
new there.

The "guts" of this proposal just says:

- implementations should provide AES-128-CMAC as a supported algorithm
- MD5 should be deprecated

Implementations remain free to include whatever algorithms they want.

This has been the case for a very long time.  Nothing has changed in
this regard.

H
--

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 22 Nov 2018 08:28:01 +0100

>>> Kyle Rose <[email-masked]> schrieb am 21.11.2018 um 19:01 in Nachricht
> algorithmic agility is currently supported, but I can't imagine it would be

Hi!

It's not related to the draft, but, there is no command to _easily_ change the key of a server/peer only, meaning one must drop the  assoc and reestablish a new one. That means a temporary drop of quality from that assoc. Maybe the reference implementation could add some command like "usekey <keynumber> <assoc>..." that would also allow to add a key where no one existed before...

Regards,
Ulrich
P.S. CC list trimmed somewhat.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 22 Nov 2018 08:43:43 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 22.11.2018 um 01:02 in
Nachricht
<[email-masked]>:

>> have a pre‑existing relationship that presumes the existence of pre‑shared
> ‑ implementations should provide AES‑128‑CMAC as a supported algorithm
> ‑ MD5 should be deprecated
> 

Hi!

While this may seem liberal, it's still problematic: For example HP-UX had
shipped xntp V3 for a long time while Linux had NTP v4 where DES-keys were no
longer supported, while the HP-UX still had them (as kind of default); as a
consequence keys had to be moved to MD5.
If now MD5 is no longer supported (would that be in conformance to the NTPv4
RFC?), you'll have a similar problem (thinking of the many devices around with
some old NTPv3 client in firmware).

Here in a small Intranet we still have NTPv3 clients...

Regards,
Ulrich

> ‑‑
>> adding an additional keyid, key, and algorithm (AES‑CMAC). Once the
>> new keyid. This kind of two‑phase commit is less flexible than online
>> existing wire image and the need to be backwards‑compatible. I have not
>>>> especially from an operational perspective ‑‑ in particular, is there
>>> some
>>> If you are thinking about that area, I'd worry about the opposite.  As
far
>>> as
>>> ‑‑
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 22 Nov 2018 09:55:20 +0100

> some old NTPv3 client in firmware).

NTPv3 has no extension fields, so length extension attacks won't work
unless the implementation is parsing them as NTPv4 packets.

I guess one possibility would be say that implementations should
ignore all extension fields in packets authenticated with an MD5 or
RIPEMD-160 (as Tim points out) key.

-- 
Miroslav Lichvar