Subject: [Ntp] Ambiguous parsing in draft-stenn-ntp-extension-fields

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 23 Mar 2018 11:36:57 +0100

I've read the latest version of the draft. I like that it dropped the
MAC optional/required bits.

I still don't like that it allows ambiguous parsing of NTP packets.
This is a problem for the correction field that I proposed. I don't
think we want to allow switches to corrupt MACs in random NTP packets,
even if the probability is small.

Requiring NTP implementations to select between multiple possible
parsings seems like a poor engineering to me. Imagine there was a
programming language where associativity of an operator was not
defined as left or right, but as one where the side is selected
dynamically to give a higher value. That's how it feels to me.

Here is a packet I captured from an ntpd client using Autokey
(72 octets of the UDP data, 24 octets per line):

23 01 03 E9 00 00 00 00 00 00 00 40 53 48 4D 00 DE 5F 92 7D 00 00 02 DB
DE 5F 92 77 01 6C 97 1E DE 5F 92 77 02 13 A3 A2 DE 5F 92 7F 00 00 02 DA

09 A0 00 18 A1 F3 C1 9E 9B 79 1E E4 9A 54 0E 11 AA 03 B2 B2 21 3A 0D F8
<--key ID-> <---------------------- SHA1 digest ---------------------->

The draft allows the last extension field to be shorter than 28
octets, so the key ID of 09A00018 can be interpreted as a valid header
of a 24-octet extension field. How are we (as random observers)
supposed to know if it is a MAC or an extension field?

Even the server cannot check whether it is a valid MAC when it no
longer has the key. How is it supposed to respond to the client?

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 23 Mar 2018 04:10:15 -0700

> supposed to know if it is a MAC or an extension field?

For it to be a valid legacy MAC, each side would have to have that keyID
associated with the association.

If the association is flagged for requiring authentication (in this
case, Autokey), then if the data processes as a valid EF, the
association still requires authentication, which the packet does not
have.  Therefore this would be an inappropriate parsing and should not
be chosen.

Therefore, the packet cannot be valid if that data is parsed as an EF.

The only way for the packet to be valid is if it is authenticated, so
the EF choice should not be taken.

I'm pretty sure this is what the draft requires, but I'm happy to
re-read it and add this case to the logic if it's missing.

> longer has the key. How is it supposed to respond to the client?

I'm not sure I understand this case yet.  Are you saying that the client
is sending an authenticated (autokey?  symmetric key?) packet to a
server, but the server doesn't know about the authentication so it
cannot respond with an authenticated packet?
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 23 Mar 2018 04:30:07 -0700

Miroslav,

Isn’t you example ambiguous today, too?

Current code could parse it as either an EF or a legacy MAC. 

Sent from my iPhone. Please excuse brevity and typos.

> On Mar 23, 2018, at 4:10 AM, Harlan Stenn <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 23 Mar 2018 12:32:01 +0100

Guys,

> associated with the association.

Assuming Miroslav's proposal for a correction field is for routers or
switches which can measure the packet propagation delay, and add the
measurement to a correction field in the packet:

How should a router or switch distinguish whether a part of this field
is a keyID that is known to the client and server?

> cannot respond with an authenticated packet?

Maybe I've asked this question before:

Wouldn't it be *much* simpler and *less* error prone for any
implementation to *only* support *either* the old extension fields *or*
the new EFs in a single packet?

When an NTP daemon that is supposed to support the old autokey etc.
stuff beside the new EFs then receives a packet with extension fields,
it can try to determine if the extension fields are legacy or the new
ones, and can send an appropriate reply.

For a switch or router it would only be important to identify packets
that include the *new* EFs, which may contain a correction field that
can be updated. All other NTP packets could simply be forwarded without
modification.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 23 Mar 2018 12:50:16 +0100

>From our point of view (or that of the switch) we don't know anything
about associations or key IDs they are supposed to be using. It's just
a random NTP packet we need to look at (or in the case of the switch
modify and forward).

> cannot respond with an authenticated packet?

The client may have authenticated the packet using an old cookie. The
server cannot verify the MAC and doesn't know if it should respond
with a crypto-NAK to tell the client to restart the protocol, or if
it should respond to it as an unauthenticated packet with an unknown
extension field.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 23 Mar 2018 12:52:44 +0100

> Isn’t you example ambiguous today, too?

Per RFC7822 an extension field at the end of the packet cannot be
shorter than 28 octets, so it's a MAC. No ambiguity here.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 23 Mar 2018 23:02:34 -0700

> is a keyID that is known to the client and server?

It seems to me that devices along the path will have to add the
correction field *after* any MAC, which means it could not be done when
using a legacy MAC, unless the devices also have access to the key and
algorithm.

The correction data can easily come after any MAC-EF.

I don't think it will be necessary to have:

base+EFs+MAC-EF+LAST-EF which becomes:
base+EFs+MAC-EF+Correction1-EF+LAST-EF which becomes:
base+EFs+MAC-EF+Correction1-EF+Correction2-EF+LAST-EF which becomes:
...

as the packet traverses the network, but it's certainly an option.

> the new EFs in a single packet?

What if there are clients in the network that only know about legacy MACs?

> ones, and can send an appropriate reply.

I haven't thought much about this case, but I suspect it's not as robust
as what I have working now, which is what I based the proposal on.

> can be updated. All other NTP packets could simply be forwarded without

The issue of "when can an NTP packet be augmented with a correction
field" is interesting, and in that case I think the easy way to decide
is to add the correction field iff the last EF of the packet is a
LAST-EF and there is no legacy MAC after that.  This could be overridden
in the device with a list of IPs that should/should not get the
correction field if (some conditions were satisfied).

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 23 Mar 2018 23:11:25 -0700

> a random NTP packet we need to look at (or in the case of the switch

So you're looking at this from the POV of a switch that wants to do a
delay correction?

Please see my previous message about this.  And I'll re-read your proposal.

> it should respond to it as an unauthenticated packet with an unknown

Can you please share the relevant parts of the ntp.conf file for the 2
endpoints?

I submit it doesn't matter.  If the "other side" gets the packet and
can't recognize the keyID because the sender is using an expired
autokey, then it is free to return either a crypto-NAK or an
unauthenticated response.

If it sends back a crypto-NAK then the sender knows it has to
re-negotiate autokey.

If it sends back an unauthenticated response, the originating side sees
a packet that passes the loopback test, and is unauthenticated when the
association requires authentication.  So re-negotiate autokey.

But nobody should be using autokey anymore.  If they are, that's fine
and it will be as secure as it is for their environment, and we're
working on a replacement for autokey.

If the "other side" gets the packet and knows the sender is using
autokey but we don't have that keyID, we do a key re-negotiation.

Are there other cases?

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 23 Mar 2018 23:16:32 -0700

> shorter than 28 octets, so it's a MAC. No ambiguity here.

RFC7822 is broken and wrong.

draft-stenn-ntp-extension-fields intends to fix/change 7822.

But if one is talking to a system that only implements 7822, then the
data you cite will be seen as a MAC, and that system will return a
crypto-NAK.

If one has an environment that contains 7822-based servers, then until
those are replaced other systems may need to make sure that the final EF
is at least 28 octets long.  That should be a config file option to
address this.

So is there still a problem?

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 26 Mar 2018 15:37:33 +0200

> using a legacy MAC, unless the devices also have access to the key and

The devices are supposed to identify and modify an existing extension
field in the packet. They must not add any new fields.

> correction field if (some conditions were satisfied).

I'm not sure if that changes anything. If the restrictions on lengths
are removed, a MAC could always look like a single or multiple
extension fields, including the LAST-EF at the end of the packet.

BTW, the switch could be anywhere in the Internet. It should not make
any assumptions about NTP implementations or their configurations.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 26 Mar 2018 15:48:25 +0200

> RFC7822 is broken and wrong.

I understand that David Mills has a different idea about how this
should work, but the restrictions on lengths that RFC7822 specified
were needed to avoid the ambiguity in parsing. Now you are trying to
remove them. That does not make sense to me.

If there is a need for short extension fields in NTPv4, they can be
packed in a longer extension field which follows RFC7822.

> So is there still a problem?

I don't see how updating 7822-based servers to your proposal will
prevent the issue I have described.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 26 Mar 2018 16:03:29 +0200

> unauthenticated response.

In either case it may be an unexpected response for the client.

> If it sends back a crypto-NAK then the sender knows it has to

Are clients sending unauthenticated packets with extension fields
supposed to accept packets with crypto-NAKs for synchronization of the
clock?

> association requires authentication.  So re-negotiate autokey.

I don't see this in the Autokey specification or the ntpd code. The
client should restart the protocol when it stops getting useful
replies, but this is a change in the protocol.

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Mar 2018 11:46:02 -0400

On 3/24/2018 2:02 AM, Harlan Stenn wrote:
> ....

Last-EF is not needed if there is no legacy MAC since the extended
packet will only contain EF's. Any correction needs to come after any EF
MAC's and cannot be authenticated. Furthermore having a Last-EF at the
end of such a packet will require that the router/switch first overwrite
or eliminate the last-ef before adding a correction. In addition to this
you need to fix the UDP checksum each time (see RFC7821) which requires
padding each correction with additional bits.

Not nice.

>> the new EFs in a single packet?

Unfortunately for some use cases you don't know if they recipient
understands EF MAC's or Legacy MAC's or both. If a client sends a
request to a server with just an EF MAC and the server only understands
Legacy MAC's how do you handle this. Conversely if you are using
Broadcast or Multicast mode you don't even know what the receiving
server knows.

> as what I have working now, which is what I based the proposal on.
Right now my recommendation is that if autokey is being used then ONLY
send Legacy MAC's and don't send EF MAC's. Since autokey is being
obsoleted (slowly) by the NTS replacement this should work without code
changes for autokey.

> correction field if (some conditions were satisfied).

Interesting idea.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Mar 2018 10:40:54 -0700

> field in the packet. They must not add any new fields.

OK.  I would be looking at adding one of these correction EFs at as many
steps along the path as possible, and I'm curious to see how the Origin
ID and Path ID fields are used/useful in the current model.

Yes, one would have to specify what to do if the packet were to want to
grow beyond some size limit.

But again, it can be a single EF that comes after a MAC-EF.

> extension fields, including the LAST-EF at the end of the packet.

One reason to put a LAST-EF is to make it easy for these network devices
to see where to add additional NTP correction fields, but if the
proposal is to only have one of them that's not necessary.

> any assumptions about NTP implementations or their configurations.

Of course.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Mar 2018 10:45:16 -0700

> remove them. That does not make sense to me.

It's more folks than Dave.  It's even more than Dave and I.

What parts of
https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/ are
unclear to you.

> packed in a longer extension field which follows RFC7822.

Your choice.  You can implement whatever you want.  It will even be
interoperable if the specs are followed.  You can still follow 7822's
rules about the final EF size with draft-stenn-ntp-extension-fields if
that's what you want to do.  It will interoperate just fine.

> prevent the issue I have described.

How can I help?  I thought I'd described this very clearly, in multiple
ways.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Mar 2018 10:54:59 -0700

> In either case it may be an unexpected response for the client.

Then the client has a problem.  If you're talking about "old code" then
all I can say is that things work fine with what I have proposed and an
old client.

If this were to be a problem with "new" client code, then I submit the
new code either has a bug or the implementor didn't do a good job.

Of course, I'm assuming the "other side" in the above-cited paragraph
has properly implemented the spec.

If you think the proposal won't handle this case, please show me an
example.  Otherwise, I point you at something you wrote:

> BTW, the switch could be anywhere in the Internet. It should not
> make any assumptions about NTP implementations or their
> configurations.

and the addage about "Be liberal about what you accept, and conservative
about what you send".

> supposed to accept packets with crypto-NAKs for synchronization of the

For an unauthenticated session, sure, and that might need to be a local
policy choice.

If the respondent sends back a packet with LI=3, then obviously the
packet should not be used to synchronize the time.

> replies, but this is a change in the protocol.

I'm not sure how much of this is there now.  Autokey requires
authentication, and the client (at least) knows that the association
must be authenticated.  So when an unautheneticated packet is received,
it is dropped.

I'm not worried about addressing this case for 5906 as we're about to
obsolete it.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Mar 2018 11:09:46 -0700

> padding each correction with additional bits.

I disagree with you, Danny.  The LAST-EF may easily be used to tell a
device where the expected EOPacket is.  This is about robust mechanism
and providing local policy choices.

Of course the portion of the packet that is covered by a MAC cannot be
modified in-transit.  But that's not what we're discussing here.

We're talking about changing things that come after the MAC.

Let's not turn this thread into a discussion about the ntp-correction
proposal.

> Broadcast or Multicast mode you don't even know what the receiving

Danny, you don't seem to have understood the various proposals.

Unrecognized EFs should/must be ignored.  But there is old code out
there, and we cannot rely on its behavior.  We can, however, behave
robustly in this case.

The I-DO proposal handles this quite easily.  If a new/updated
implementation chooses to support *any* new EFs and does not choose to
implement I-DO (assuming that proposal is accepted), then that's the
implementeor's choice.  With any luck the implementor will have handled
this, if they care about interoperability.

If you're saying "If the client sends a legacy MAC and the server
replies with a MAC-EF that the client doesn't understand" then you're
right, and that's clearly a bad implementation on the server side.

As for the broadcast/multicast case, that's easy, too.  If these are
authenticated, then send MAC-EF, maybe LAST-EF, and then legacy-MAC.

If you have an environment where the clients are ancient and don't drop
unrecognized EFs, then your *cast servers can alternate sending a packet
with MAC-EF/LAST-EF/legacy-MAC with a packet that only contains the
legacy-MAC.

Local policy choice.

Or have more than 1 *cast server, some that send MAC-EFs, and others
that send legacy-MAC.

> obsoleted (slowly) by the NTS replacement this should work without code

OK, that's fine, and it's your local policy choice.

But I don't want your recommendation to prevent anybody who still wants
to use Autokey (leaving aside the issue of 'do they have good reason to
do this) *and* use new EFs.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 26 Mar 2018 15:00:42 -0400

> Let's not turn this thread into a discussion about the ntp-correction
It wasn't originally but you brought it up.

> Danny, you don't seem to have understood the various proposals.
I do. I'm just pointing out that you can't do one and not the other
since you don't know anything initially about the other end and may
never do so if you are doing broadcast mode.

> there, and we cannot rely on its behavior.  We can, however, behave

What I said.

> authenticated, then send MAC-EF, maybe LAST-EF, and then legacy-MAC.

Old Clients may only understand Legacy MAC's and may well fall over new
EF's. Not sure what to recommend here.

> with MAC-EF/LAST-EF/legacy-MAC with a packet that only contains the

If clients are ancient they don't get to make that choice since only
Legacy MAC's exist for them and *maybe* autokey.

> Or have more than 1 *cast server, some that send MAC-EFs, and others

Yes.

> do this) *and* use new EFs.

Nothing prevents using new EFs. I'm just recommending that if they use
autokey then they MUST send a Legacy MAC and should *not* use an EF MAC.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 26 Mar 2018 13:21:21 -0700

> never do so if you are doing broadcast mode.

I don't yet understand what you are trying to say.

I can tell you that I've implemented what I've proposed and it works
with old clients, so in my experience the behavior you are concerned
about is just not a problem.

> EF's. Not sure what to recommend here.

I provided 2 ways forward for this very situation.

Do you see a problem with those solutions?

> Legacy MAC's exist for them and *maybe* autokey.

You keep bringing this up even though I think I've clearly described how
to handle this case.

Where do you think the problem is with what I have proposed?

Concrete example, please.

> autokey then they MUST send a Legacy MAC and should *not* use an EF MAC.

OK, if that's your local policy choice then that's fine.

There is certainly no problem in *allowing* autokey and MAC-EF, or any
other new EFs, if both sides are OK with that.

Such an agreement is trivial.  It can be via the config file for that
association, and/or via I-DO negotiation.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Mar 2018 00:13:36 -0400

> Do you see a problem with those solutions?

Old clients won't have been updated irrespective of what you provide.
Those are the ones I'd be concerned about. I recognize that most old
clients only look at the base of packet and ignore extension fields and
MACs. However we are still seeing clients/servers running v3 so do we
have to worry?

> Where do you think the problem is with what I have proposed?

Are you suggesting that we update these existing clients?

> other new EFs, if both sides are OK with that.

Unless you are going to be updating RFC5906 then if you use autokey then
you must send the legacy MAC irrespective of what other EF's you may send.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 27 Mar 2018 00:16:21 -0700

Danny,

> MACs. However we are still seeing clients/servers running v3 so do we

I have not tested against v3.  But if these EFs are a v4 feature, we
cannot *expect* them to work with a v3 client.  Then again, somebody
might have augmented a v3 client to recognize these things.  It is
certainly easy enough to say "Don't send V4 EF stuff to a client that
claims v3".

The new EF responses are sent *in response to an EF request*, so if a v3
client isn't sending new EFs, it won't get any in return.

I don't yet see any reason to worry more about this case.

> Are you suggesting that we update these existing clients?

Uh, no.

I'm still asking why you think it's a problem.

I've been talking about NTPv4.  If somebody has NTPv3 clients that do
not accept v4 broadcasts, then they get to say:

 broadcast IP version 3

in the broadcast server's ntp.conf file, and that should be enough to
prevent the use of v4 features from the server.

So again, where do you think the problem is with what I have proposed?

> you must send the legacy MAC irrespective of what other EF's you may send.

I disagree.

As I wrote in draft-stenn-ntp-extension-fields, which you say you have read:

 Because there is a reasonable expectation that RFC 5906 will
 be deprecated, this document does not propose changes or updates
 to RFC 5906.

This language has been in this document for a while, and you're the
first person to suggest that we now consider updating 5906.  But if you
want to update 5906 in accordance with this proposal, goferit.

Why do you think that autokey EFs require legacy MACs?  I can easily see
cases where, when using autokey, as long as a MAC-EF and/or a legacy MAC
is sent, that's fine.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 27 Mar 2018 10:24:05 +0200

> ID and Path ID fields are used/useful in the current model.

Changing length of the packet in the network would create an
asymmetric delay as longer packets take longer to receive and
transmit, which would add an error to the measured offset. The whole
point of the correction field is to improve the accuracy, so the
length of the packet should not change, or at least change
symmetrically (e.g. VLAN tags added and removed at the same point in
network in the opposite directions).

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 27 Mar 2018 10:59:36 +0200

> https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/ are

The document is pretty clear to me. What is not clear to me is why
would you prefer this problematic approach when its only advantage is
that it can save up to 20 octets per packet.

> that's what you want to do.  It will interoperate just fine.

Is it ok that if your client sends a request with a short EF to
my server following 7822, it will not get any response?

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 27 Mar 2018 03:12:11 -0700

> that it can save up to 20 octets per packet.

I don't see my approach as problematic.  Are you forgetting that the
proposal notes 2 separate ways to completely avoid any ambiguity, and
the only remaining chance of an ambiguity is if one side specifically
decides to not implement the two simple/preferred recommendations?

I also don't understand how you can think that 20 wasted octets in a
packet is not a big deal.

I listed a number of other benefits over 7822 in the proposal as well.

Yes.

And if I know that will happen, I'll configure a minimum EF size for the
last packet in my client to avoid it.

I can also use I-DO to see if I can learn if your server requires 7822
behavior.

If draft-stenn-ntp-extension-fields is passed, then sure, for some
period of time we'll need to accommodate legacy 7822 systems.  But that
accommodation will last as long as it needs to, and then it will no
longer be needed, just like some day the legacy MAC will no longer be
needed.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Mar 2018 13:02:27 -0400

> want to update 5906 in accordance with this proposal, goferit.

That's not what I'm saying. I don't want to update RFC5906 but if you
want to replace Legacy MACs with EF MACs in an autokey exchange you
would need to update it.

> cases where, when using autokey, as long as a MAC-EF and/or a legacy MAC

Because that's what RFC5906 states. Changing this requires a change to
the RFC since it would not conform to the requirements of the RFC.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 27 Mar 2018 14:11:16 -0700

Danny,

We're talking past each other.

If somebody wants to propose language for a note to 5906 saying
something along the lines of "Parts of this specification are obsoleted
by XXX" then that's fine.

I have no current plans to spend time on that.

H

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 27 Mar 2018 14:18:53 -0700

...
> longer be needed, just like some day the legacy MAC will no longer be

I can also decide if I want the client code to detect this case, and act
accordingly.  But I'd rather not bloat the codebase with this when
there's an option to handle it in the config file.

Implementor's choice, and user's choice.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 28 Mar 2018 07:53:14 +0200

>>> Danny Mayer <[email-masked]> schrieb am 27.03.2018 um 19:02 in Nachricht
> the RFC since it would not conform to the requirements of the RFC.

Probably it would be more precise to say that autokey EFs were implemented on "top of" legacy MACs.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 27 Mar 2018 23:04:17 -0700

> Probably it would be more precise to say that autokey EFs were implemented on "top of" legacy MACs.

Autokey requires MAC protection.  It shouldn't matter if it's legacy MAC
or MAC-EF, or both.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Mar 2018 09:07:11 -0400

> I have no current plans to spend time on that.

Me neither, which is why you need to keep Legacy MAC for autokey. I'm
making a *statement* and not a suggestion.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Mar 2018 19:51:31 -0700

Danny,

> making a *statement* and not a suggestion.

We're still talking past each other.

Autokey will still "work" with legacy MAC.

If each side supports MAC-EF, autokey will work Just Fine with MAC-EF
and no legacy MAC.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 29 Mar 2018 12:13:51 -0400

> If each side supports MAC-EF, autokey will work Just Fine with MAC-EF

It will not conform to RFC5906 in that case. It's not worth the effort
to change anything. That's what you are not understanding.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 29 Mar 2018 11:27:28 -0700

I suspect we’re in violent agreement. 

> On Mar 29, 2018, at 9:13 AM, Danny Mayer <[email-masked]> wrote:
>