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 6:53 PM, Bernie Volz (volz) <[e-mail]> wrote:

> Hi:
>
> I don’t see need to change DUID practices that have been used for a long
> number of years (as originally specified in 3315). There are a lot of
> things one could do, but what’s the benefit?
>

The benefit is that you have a pile of different mechanisms which are
redundant. This would simplkify that.

And, if you’d really like the WG to develop a new format, that doesn’t seem
> something to do in a bis document?
>

I'm not suggesting a new format. You already support UUIDs. I'm suggesting
that you recommend that people use UUIDs and generate them using the same
inputs they already use for generating the other DUIDs.


Regarding Replay Protection, as this is for Reconfigure (server to client),
> there should only be a need for a single Reconfigure per client. Even if
> multiple are sent by server for a single client, that only causes some to
> fail replay checks if out of order delivery or processing and means maybe
> some are dropped, which isn’t an issue (especially as now Reconfigure no
> longer communicates what may need reconfiguration).
>

All right

-Ekr


>
> - Bernie (from iPad)
>
> On Jan 22, 2018, at 9:11 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> 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
>>
>
>