Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

Hello,

Perhaps you've already forgotten the context, but I'm now revising the
dhcpv6-clarify-auth draft, and would like to address your concern in
the next version.

>>>>> On Mon, 26 Jul 2004 18:10:35 +0900, 
>>>>> JINMEI Tatuya <[e-mail]> said:

>> For stateless I think it's generally enough to authenticate the DHCP
>> server. In most cases I don't think it's important to guard against
>> replay, or to authenticate the client. That could perhaps simplify
>> the security mechanism. It's relatively easy to guard against replay
>> anyway though.

> On the one hand, I see and tend to agree that it's nice to prevent
> per-client state for "stateless" DHCP.

> On the other hand, we should be very careful when we are going to
> justify something that could introduce weaker security.  While the
> current main usage for stateless DHCP is client independent, the
> specification leaves the possibility for per-client configuration
> (otherwise, we could have prohibited including the client identifier
> option in Information-request in the first place).  Regarding replay
> attacks, the client might want to minimize the possibility of
> receiving a replayed reply to Information-request that contains a very
> small lifetime in the lifetime option.

> Perhaps a possible compromise would be something like this:

> - loosen the "MUST record the per-client state" to SHOULD
> - allow (using MAY) the server to not record the state when replay
>   attacks can be ignored and it is acceptable that Information-request
>   is always non-authenticated

> What do you think?

I've not seen any responses to this rough proposal, so I'm currently
going to implement the idea in the next draft.  I've attached the
current cut of the new text below (sorry, it's quite long), so it
would be nice if you could review and make comment on it (whether it's
acceptable or not, etc).

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

2.  Usage with Information-Request

   According to [RFC3315], it seems possible to use the authentication
   mechanism for Information-request and Reply exchanges.  The RFC says
   in Section 21.4.4.4 as follows:

      If the server has selected a key for the client in a previous
      message exchange (see section 21.4.5.1), the client MUST use the
      same key to generate the authentication information throughout the
      session.

   However, this description is not really clear.  Section 21.4.5.1,
   which is referred from the above part, actually describes the case of
   Solicit and Advertise exchange:

      21.4.5.1.  Receiving Solicit Messages and Sending Advertise
      Messages

      The server selects a key for the client and includes
      authentication information in the Advertise message returned to
      the client as specified in section 21.4.  [...]

   It does not necessarily mean contradiction because the client and the
   server may have exchanged Solicit and Advertise with authentication
   before starting the Information-request and Reply exchange.  However,
   it then restricts the usage scenario of the authentication mechanism
   for Information-request and Reply exchanges.  In particular, this
   assumption prohibits the use of the mechanism with the "stateless"
   service using DHCPv6 [RFC3736].  Whereas the specification allows an
   implementation that only supports the stateless service and does not
   support Solicit and Advertise messages, the authentication mechanism
   depends on Solicit and Advertise exchanges.

   This fact can (partly) invalidate a security consideration in
   [RFC3736]:

      Authenticated DHCP, as described in sections 21 and 22.11 of the
      DHCP specification [1], can be used to avoid attacks mounted
      through the stateless DHCP service.

   (where [1] refers to [RFC3315].) In fact, as was just shown above,
   authenticated DHCP cannot be used unless the implementations also
   support Solicit and Advertise messages (or the entire [RFC3315] in
   general).

   It should also be noted that [RFC3315] does not define what the
   server should do when it receives an Information-request message
   containing an authentication option; Section 21.4.5.2 excludes the
   Information-request message.

2.1  Suggested Resolution

   Considering the fact that [RFC3736] allows implementations that only
   support the subset of the full specification [RFC3315], it should
   make sense to define the authentication usage for Information-request
   and Reply exchanges separately.

   One significant difference between Information-request and other
   "stateful" cases is that there is no explicit notion of "session" in
   the former.  In some cases, however, the same client and server may
   exchange Information-request and Reply multiple times, where the
   entire exchanges can be regarded as a "session".  For example, the
   client may want to get different configuration information in
   multiple exchanges.  Also, if the client and the server use the
   Information Refresh Time Option [I-D.ietf-dhc-lifetime], they will
   restart exchanges when the refresh time expires.

   On the other hand, keeping a "session" in the server decreases an
   advantage of the [RFC3736] usage that the server can run in a
   stateless fashion without any client-specific state.  Thus, it is
   worth considering a trade off between securing multiple exchanges as
   a single session and keeping the server stateless.

   Securing multiple exchanges has two beneficial points:

   o  the server can authenticate Information-request messages from the
      client.

   o  the client and the server can perform replay protection.

   In other words, it would make sense to separate each exchange and to
   keep the server stateless in the case where neither of them is
   desired.  And, in fact, it is not so important to authenticate
   client's messages in the current usage of [RFC3736] for providing
   client-independent information.  Additionally, replay attacks in such
   a typical usage might not be a big threat, since any Reply messages
   from the server will simply be the same.

   Still, there will be other cases where (one of) the above two points
   are important.  For example, if the address of a DNS recursive name
   resolver [RFC3646] is provided in reply to an Information-request
   message and the address is renumbered, the client will not want to be
   confused with the previous address containing the previous valid
   authentication information.  In this case, the client wants to reject
   such an invalid or stale Reply by the reply protection mechanism.
   Also, the current design of the Information-request message still
   allows including the Client DUID option in order for per-client
   configuration, while it is not common today.  In this type of
   configuration, the server will want to authenticate the client's
   request.

   The proposed revision of Section 21.4.4.4 is therefore as follows:

      21.4.4.4.  Sending Information-request Messages

      When the client sends an Information-request message and wishes to
      use authentication, it includes an Authentication option with the
      desired protocol, algorithm and RDM as described in section 21.4.
      The client does not include any replay detection or authentication
      information in the Authentication option.

      If the client authenticated past exchanges of Information-request
      and Reply, the client MAY reuse the same key used in the previous
      exchanges to generate the authentication information.  In this
      case, the client generates authentication information for the
      Information-request message as described in section 21.4.

      Normally, the client performs replay detection when it reuses the
      same key.  However, to be able to interoperate with "stateless"
      servers that do not maintain per-client state, the client MUST be
      configurable to turn off replay detection for a Reply message to
      Information-request.  Since disabling replay detection can cause a
      security threat, the client SHOULD be configured by default to
      enable it.

      Note that the keys used for these exchanges are separately managed
      from the keys used for the other exchanges beginning with the
      Solicit message when the two types of exchanges run concurrently,
      while the two keys may happen to be the same.  For example, replay
      detection should be performed separately, and validation failure
      for one type of exchanges does not affect the other.

   Section 21.4.4.5 will also need to be revised.  However, since this
   section has a separate issue per se as will be discussed in Section
   6, we do not discuss further details on this here.

   The server side behavior needs to be described, too.  Along with the
   above change to Section 21.4.4.4, we propose to add a new subsection
   of Section 21.4.5:

      21.4.5.x.  Receiving Information-request Messages and Sending
      Reply Messages

      If the Information-request message includes an authentication
      option without authentication information, the server selects a
      key for the client and includes authentication information in the
      Reply message returned to the client as specified in section 21.4.
      The server SHOULD record the identifier of the key selected for
      the client so that it can validate further Information-request
      messages from the client if the client reuses the same key for the
      future exchanges.

      In some cases, however, the server would rather be just stateless,
      without maintaining any per-client state.  Thus, the server MAY
      skip keeping per-client state, in which case it will not
      authenticate Information-request messages from clients or
      necessarily provide a valid replay detection information with the
      client which performs replay detection.

      If the Information-request message includes an authentication
      option with authentication information, the server uses the key
      identified in the message and validates the message as specified
      in section 21.4.2.  If the message fails to pass the validation
      test, or the key identified by the authentication information of
      the message is not identical to the key that the server used in
      the previous exchange (when it has recorded the key), the server
      MUST discard the message and MAY choose to log the validation
      failure.  If the server has not recorded the key, it MAY skip
      replay detection in the above procedure, but MUST perform the rest
      of validation.

      If the message passes the validation test, the server responds to
      the Reply message as described in section 18.2.5.  The server MUST
      include authentication information generated using the key just
      selected or identified in the received message, as specified in
      section 21.4.

      Note that the keys used for these exchanges are separately managed
      from the keys used for the other exchanges beginning with the
      Solicit message when the two types of exchanges run concurrently
      (See Section 21.4.4.4).

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg