Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

From: Maglione Roberta <[email-masked]>
Date: Fri, 3 Feb 2012 16:26:57 +0100

Hello Matt,
  Sorry for my late reply.
Please see answers inline [RM]
Thanks,
Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matthew Ryan
Sent: martedì 3 gennaio 2012 23.53
To: dhc WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

First, a couple of typos:
Section 3.1.3, 4th paragraph:
   easily be predicted.  The nonce is imbedded as a 128-bit value of the
'imbedded' should be 'embedded', or 'included'

[RM] ok I'll fix it thanks.

Section 3.1.4, 2nd paragraph:
   A DHCP server has indicates its support through the inclusion of the
remove the 'has'.

[RM] ok I'll fix it thanks.

I think some clarifications are needed on renew behavior, and
server support advertisement.

Section 3.1.4 states:
  The client will receive a Forcerenew Nonce from the server in the
  initial DHCP Ack message from the server.
which could be construed to imply that the nonce is only chosen
during the initial 4-way handshake.

However, the protocol interaction diagram in section 3.1.1
seems to indicate that, during a renew, the server may/must
(unclear) create a new nonce.

[RM] The idea is that the nonce is selected and sent by the server in the initial DHCP exchange, then later on when the DHCP server needs to send a Forcerenew message it includes the nonce previously created in the message sent to the client. In this way the client can verify that the Forcerenew message comes from a trusted DHCP server. Please let me know if you think this behavior should better explained in the document

In addition, sections 3.1.3 (server considerations) and 3.1.4
(client considerations) seem to state different things as to
how a server advertises its support for forcerenew-nonce.  Both
sections mention that the server indicates support by including
the FORCERENEW_NONCE_CAPABLE option in OFFERs, but 3.1.4 also
mentions that the server MUST include a forcerenew-nonce
authentication option with type set to zero.  It seems to me
that if a server MUST emit both the FORCERENEW_NONCE_CAPABLE
option and the authentication option, it should explicitly
state so in the server considerations section (3.1.3).  Also,
since 3.1.3 states that the server chooses a nonce only in
response to a REQUEST, what should the value in the OFFER be?

However, I'm not sure I see the need for a server to return
BOTH the FORCERENEW_NONCE_CAPABLE option, and the authentication
type 0 in the OFFER, in order to advertise that it is capable
of forcerenew-nonce.

[RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward compatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPABLE is sent by the client to tell the server that is able support this functionality and then the server replies with both the FORCERENEW_NONCE_CAPABLE and the nonce. Do you think the Server should just send the nonce in this case? I'm open to that behavior too, I would like to ask the other co-authors if they have an opinion on this point.

Roberta

- Matt

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

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Feb 2012 16:27:33 +0000

> [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward compatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPABLE is sent by the client to tell the server that…

There is some cost associated with generating a secure nonce, so requiring the server to send one to all clients is probably not the right tradeoff.   It's unfortunate that the decision whether or not to send a nonce will require an extra decision path, but I think it's a better tradeoff.

---

From: Matthew Ryan <[email-masked]>
Date: Fri, 3 Feb 2012 14:19:21 -0800

> [RM] The idea is that the nonce is selected and sent by the server in the initial DHCP exchange, then later on when the DHCP server needs to send a Forcerenew message it includes the nonce previous…

I believe it's clear that a nonce should be returned in each
ACK message.  However, I think the document needs to be clarified
as to which REQUEST messages (init-reboot, select, renew, rebind)
or conditions should cause a server to generate a /new/ nonce.
Specifically, when the server MUST generate a nonce, and when
it MAY generate (or change) the nonce.

Does the server ONLY generate a nonce the first time it sees the
client?  Is the server ONLY allowed to generate a nonce (even if
it has no previous recorded) in response to a select, or can it do
so for rebind and init-reboot as well?  Can the server (perhaps on
a timer or by admin instruction) choose to generate a new nonce for
a client in response to a renew?

In addition, it should be clarified when a client should update
its record of the nonce.  The draft currently states this is done
in response to the "initial DHCP Ack message".  Depending on the
answers to the server behavior question above, this may not be
sufficient.  If the server is allowed to generate a new nonce
on rebind (which may need to happen in environments that have
multiple DHCP servers that don't do failover), the client should
probably update itself then as well.

Also, what should happen in the case where the client indicates
in a renew that it is capable, and the server is capable, but the
server has no recollection of a nonce for the client?  This condition
can happen if the server support is enabled and the client already
possesses an active lease from the server.

I would probably recommend at the following:
1) The client MUST record the nonce from any valid ACK it receives,
   if the ACK contains one.
2) If a capable server receives a DISCOVER or REQUEST (any type)
   that indicates the client is capable, and the server has no
   previous nonce recorded, it MUST generate a nonce and include
   it in the ACK.
3) The server SHOULD NOT include the nonce in an ACK when responding
   to a renew unless a nonce was generated.  This minimizes the
   number of times the nonce is sent over the wire.

That leaves open the question of whether a server MAY change
an existing nonce, but that becomes a non-issue due to (1).

> [RM] The purpose of FORCERENEW_NONCE_CAPABLE option is to allow backward compatibility with legacy DHCP client and server. The FORCERENEW_NONCE_CAPABLE is sent by the client to tell the server that…

My reading of the draft indicated that the server would send
a nonce of type 0 in an OFFER (type 0 is not covered in section
3.1.2) - but there was no indication of what the value should be.

I think, that, in the OFFER message, it is sufficient for the
server to simply send the FORCERENEW_NONCE_CAPABLE, and omit
the authentication option.  So, I would change section 3.1.4
from:
   The client MUST indicate Forcerenew nonce Capability by including the
   FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
   DHCP Discover and Request messages.  DHCP servers that support
   Forcerenew nonce Protocol authentication MUST include the DHCP
   Forcerenew Nonce protocol authentication option in DHCP Offers with
   type set to zero(0), allowing the client to use this capability in
   selecting DHCP servers should multiple Offers arrive.

   A DHCP server has indicates its support through the inclusion of the
   FORCERENEW_NONCE_CAPABLE(<TBD>) option in the DHCP Offer.  The client
   MUST validate the DHCP Ack message contains a Forcerenew Nonce in a
   DHCP authentication option.  If the server has indicated capability
   for Forcerenew Nonce Protocol authentication in the DHCP Offer and a
   subsequent Ack omits a valid DHCP authentication option for the
   Forcerenew Nonce Protocol, the client MUST send a DHCP Decline
   message and return to the DHCP Init state.
to (changed lines marked, no rewrapping done for clarity):
   The client MUST indicate Forcerenew nonce Capability by including the
   FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
   DHCP Discover and Request messages.  DHCP servers that support
*  Forcerenew nonce Protocol authentication MUST include the
*  FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
*  DHCP Offers, allowing the client to use this capability in
   selecting DHCP servers should multiple Offers arrive.

*  The client
   MUST validate the DHCP Ack message contains a Forcerenew Nonce in a
   DHCP authentication option.  If the server has indicated capability
   for Forcerenew Nonce Protocol authentication in the DHCP Offer and a
   subsequent Ack omits a valid DHCP authentication option for the
   Forcerenew Nonce Protocol, the client MUST send a DHCP Decline
   message and return to the DHCP Init state.

 - Matt

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 7 Feb 2012 09:29:26 +0100

Hi Matt,
 Thanks for providing valuable inputs in order to clarify the document.
I'm going to discuss your proposal with the other co-authors and I get back to you
Best regards,
Roberta

-----Original Message-----
From: Matthew Ryan [mailto:[email-masked]]
Sent: venerdì 3 febbraio 2012 23.19
To: Maglione Roberta
Cc: dhc WG; [email-masked]'; Wojciech Dec (wdec); [email-masked]'; Ullio Mario; 'Ted Lemon'
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

*  The client

 - Matt

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 10 Feb 2012 12:52:09 +0100

Hello Matt, Menachem  and All,
 I made some changes to the document in order to address your comments.
Please see answers inline [RM].
I attached a new version of the document I haven't posted it yet, please let me know if the new version covers your points and if you have additional comments.
Thanks,
Best regards,
Roberta

-----Original Message-----
From: Matthew Ryan [mailto:[email-masked]]
Sent: venerdì 3 febbraio 2012 23.19
To: Maglione Roberta
Cc: dhc WG; [email-masked]'; Wojciech Dec (wdec); [email-masked]'; Ullio Mario; 'Ted Lemon'
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

[RM] I clarified this by adding the following sentences:

The server SHOULD NOT include the nonce in an ACK when responding to
   a renew unless a nonce was generated.  This minimizes the number of
   times the nonce is sent over the wire.  (as per your proposal)

   If the server to which the DHCP Request message was sent at time T1
   has not responded, the client enters the REBINDING state and attempts
   to contact any server.  The new Server receiving the DHCP message
   MUST generate a new nonce.

[RM] In case of rebind the Server MUST generates a new nonce

[RM] Good points, I think the 3 points you propose below take care of these cases.

[RM] I added the 3 points you suggested

*  The client

[RM] I modified the text as per your proposal

 - Matt

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 10 Feb 2012 15:12:31 +0100

Hello Roberta,

Looks good to me.

Regards,
Woj.

On 10/02/2012 12:52, "Maglione Roberta" <[email-masked]>
wrote:

> I attached a new version of the document I haven't posted it yet, please let
> me know if the new version covers your points and if you have additional
> comments.
> Thanks,
> Best regards,
> Roberta
> 
> Cc: dhc WG; [email-masked]'; Wojciech Dec (wdec);
> [email-masked]'; Ullio Mario; 'Ted Lemon'
>> [RM] The idea is that the nonce is selected and sent by the server in the
>> initial DHCP exchange, then later on when the DHCP server needs to send a
>> Forcerenew message it includes the nonce previously created in the message
>> sent to the client. In this way the client can verify that the Forcerenew
>> message comes from a trusted DHCP server. Please let me know if you think
>> this behavior should better explained in the document
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>

---

From: Matthew Ryan <[email-masked]>
Date: Mon, 13 Feb 2012 10:57:16 -0800

Minor item: The 'imbedded' typo in section 3.1.3 is still present.

While reviewing this, I noticed something I had missed before.
Section 3.1.4 indicates:
    If the server has indicated capability for Forcerenew Nonce
    Protocol authentication in the DHCP Offer and a subsequent Ack
    omits a valid DHCP authentication option for the Forcerenew Nonce
    Protocol, the client MUST send a DHCP Decline message and return
    to the DHCP Init state.

    The client MUST record the Forcerenew Nonce from any valid ACK it
    receives, if the ACK contains one.

There are two problems here.  First, the two paragraphs are contradictory
with respect to the client's behavior when receiving an ACK without
an auth option.  One says it is an error, and the other implies that
it's possible and valid.

Second, the DECLINE message is used by clients to indicate that an
address is already in use, and servers respond by marking the address
as unavailable.  As such, I don't believe it's safe behavior to
require clients to respond to an unauthenticated ACK with a DHCPDECLINE,
especially given the contradiction above.

I reviewed RFC-3118; it dictates that that a client "SHOULD be configured
by default to decline unauthenticated messages."  Given that it refers
to other DHCP messages in all-caps form DHCP<message>, I read that
to mean 'discard', and not "respond with a DHCPDECLINE".  This is in-line
with RFC-3315 (DHCPv6) behavior.  Perhaps someone who is more familiar
with the intent of RFC-3118 could confirm or deny that interpretation?

Assuming my read of RFC-3118 is correct, I would suggest the following
replacement text which should resolve both of those issues:

    If the server has indicated capability for Forcerenew Nonce
    Protocol authentication in the DHCP OFFER and the subsequent ACK
    received by the client while in the SELECTING state omits a valid
    DHCP authentication option for the Forcerenew Nonce Protocol, the
    client MUST discard the message and return to the INIT state.

    The client MUST record the Forcerenew Nonce from any valid ACK it
    receives, if the ACK contains one.

 - Matt

On Feb 10, 2012, at 03:52 , Maglione Roberta wrote:

> <draft-ietf-dhc-forcerenew-nonce-04.txt>

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 14 Feb 2012 11:00:18 +0100

Please see answers inline.
Thanks,
Roberta

-----Original Message-----
From: Matthew Ryan [mailto:[email-masked]]
Sent: lunedì 13 febbraio 2012 19.57
To: Maglione Roberta
Cc: 'Menachem Dodge'; dhc WG; Wojciech Dec (wdec); [email-masked]'; Ullio Mario; 'Ted Lemon'; 'Henderickx, Wim (Wim)'
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

Minor item: The 'imbedded' typo in section 3.1.3 is still present.
[RM] sorry about that I'll correct the typo

There are two problems here.
[...]

This is in-line

[RM] ok, I modify the text based on your proposal.

Roberta

 - Matt