Re: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Jan 22, 2018 at 5:07 PM, Tomek Mrugalski <[e-mail]
> wrote:

> On 01/23/18 01:25, Eric Rescorla wrote:
> > On Mon, Jan 22, 2018 at 4:14 PM, Tomek Mrugalski
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >     On 01/21/18 20:26, Eric Rescorla wrote:
> >     > Eric Rescorla has entered the following ballot position for
> >     > draft-ietf-dhc-rfc3315bis-10: No Objection
> >     Hi Eric,
> >
> >     Thank you for your review and your favourable ballot. See my answers
> >     below.
> >
> >     > ------------------------------------------------------------
> ----------
> >     > COMMENT:
> >     > ------------------------------------------------------------
> ----------
> >     >
> >     > Document: draft-ietf-dhc-rfc3315bis-10.txt
> >     >
>
> >     Anyway, this part of the spec hasn't changed in bis. It would be
> >     extremely difficult to make any changes as there are millions of
> devices
> >     that already use those DUID types.
> > Well, we could encourage people to move to a UUID type for sending, no?
> In many environments there is no standard way of getting the UUID. As an
> implementor of DHCPv6 client I have no idea how to check whether the
> hardware provides access to its UUID. Also, sysadmins like usage of LLT
> and LL, because it has MAC address in it. This is something they know
> and can read from the box or from the device itself. It's reasonable to
> ask a user "what's your mac address?" but it's much more tricky to ask
> "what's your uuid?" and expect to get a coherent answer.
>
> There may be privacy concerns, too. Once your phone discloses its UUID,
> it's much easier to track it and changing MAC address wouldn't help you
> at all. Devices using anonymity profile (RFC7844) must use LL type.
>
> I'm not saying that UUID is a bad type of DUID, just pointing out that
> it has its own issues. But does it matter that much? DUID is just a blob
> that must be unique and the server uses it to identify a client. If the
> DUID is of certain type, additional information about the client can be
> printed and that's about it.
>

I think you're misunderstanding me. What I am proposing is that you take the
DUID input values, hash them, and use them as input to a name-based
UUID: https://tools.ietf.org/rfcmarkup?doc=4122#section-4.3


>     > The description of how to actually do replay detection seems pretty
> >     > thin. Do you think more detail would be helpful here.
> >     It would. How about this text added to the end of Section 20.3:
> >
> >     "The client that receives a message with RDM field set to 0x00 MUST
> >     compare its replay detection field with the previous value sent by
> >     the same server. If this is the first time a client sees
> Authentication
> >     option sent by the server, it MUST record the replay detection value,
> >     but otherwise skip the replay detection check.
> >
> >     The servers that support reconfigure mechanism MUST ensure the replay
> >     detection value is retained after restarts. Failing to do that will
> >     cause the clients to refuse reconfigure messages sent by the server,
> >     effectively rendering the reconfigure mechanism useless."
> > This seems like it scales badly as you need to keep an infinite replay
> > list.
> Not at all, unless your client interacted with infinite number of
> servers and intends to visit them again. The server stores a single 64
> bit integer. Every time a packet is sent, that value is incremented. The
> client stores one value for every server it wants to continue
> communicating with. For great majority of cases this would be one
> server. For mobile clients that visited multiple locations and have the
> capability to retain the information to possibly resume operation in
> previous locations that would be a handful of servers at most.
>

It seems like you're assuming that the client can only have one outstanding
transaction with the server. Is that correct?

-Ekr



> What happens if you falsely declare something a replay?
> If you falsely declare something a replay (why would you do that?), the
> reconfigure packet is dropped by the client. The server will retransmit
> its reconfigure message with a higher value which hopefully be accepted
> by the client. If you somehow sabotage the client or trick it to believe
> that a very high value of replay detection was sent previously, it will
> continue to reject reconfigure messages. So you effectively disabled the
> reconfigure mechanism on that client, but it continues to operate and
> can still renew its configure, just after t1 timer, not immediately.
>
> Note that the replay detection is intended to be used with RKAP. So in
> principle you could perform an attack by sending a packet with high
> replay detection to confuse the client, but to do that you'd have to
> also put the correct HMAC-MD5 digest. Otherwise the client will discard
> your packet. If you have that ability, then you can do worse things than
> confuse client's notion of a replay value.
>
> There is a text about possibility of exploiting the reconfigure key
> mechanism to attack a client. Do you think we should extend it to also
> mention the replay attack?
>
> Tomek
>