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

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

>>>>> On Tue, 3 Aug 2004 01:33:37 -0400, 
>>>>> "Bernie Volz" <[e-mail]> said:

> Personally, I wouldn't call a message that has failed validation to be
> "unauthenticated". 21.4.2 is pretty clear that these messages should be
> discarded.

Yes.  I think the main problem is in Section 21.4.4.2.

> You really have three types of messages:
> - Authenticated - those that passed the validation and have meaning
> authentication data in them.
> - Failed validation - those that failed validation, because of replay
> detection, MAC validation, etc.
> - Unauthenticated - those that either had no authentication option or had
> incomplete authentication information (such as in a client's SOLICIT). But,
> read on.

> Neither clients nor servers would ever want to process "failed validation"
> messages. However, they better process the other two.

> Now, I believe, but could be wrong, that the intent of section 21.4.4.2 in
> RFC 3315 (your section 5 of the draft) was that a client could well receive
> a message which it can not validate because it doesn't have the required
> security association information or doesn't support the authentication
> protocol. This is very different from when it does have this information and
> finds that a message does not validate.

I think I agree with you on this (I believe this is essentially the
same as the resolution I suggested in my draft).

I guess it's basically an editorial issue, not a serious protocol
problem.  Here is the RFC's text (from section 21.4.4.2):

   Client behavior, if no Advertise messages include authentication
   information or pass the validation test, is controlled by local
   policy on the client.  According to client policy, the client MAY
   choose to respond to an Advertise message that has not been
   authenticated.

The first sentence indicates:

  if all Advertise messages are "Failed validation (from your
  categorization)" messages, client behavior is controlled by local
  policy on the client.

so far, there's nothing odd.  But the next sentence is ambiguous on
the meaning of "message that has not been authenticated".  Natural
interpretation in this context should however be "messages that do not
include authentication information or pass the validation test", i.e.,
"Failed validation" or "Unauthenticated" messages in your
categorization.  From this interpretation, the client MAY accept a
"Failed validation" Advertise message, conflicting with the sense of
Section 21.4.2.

Section 21.4.4.2 then continues to the next paragraph:

   The decision to set local policy to accept unauthenticated messages
   should be made with care.  Accepting an unauthenticated Advertise
   message can make the client vulnerable to spoofing and other attacks.
   [...]

Now, we see another unclear wording "unauthenticated messages" (see
section 4 of my draft).  Again, in this context, the natural
interpretation should be as follows:

  "messages that do not include authentication information or pass the
   validation test" (2nd paragraph of 21.4.4.2)
= "message that has not been authenticated" (2nd paragraph of 21.4.4.2)
= "unauthenticated messages" (3rd paragraph of 21.4.4.2)
= "Failed validation" or "Unauthenticated" messages (from your definition)

Then the result of this interpretation contradicts what is described
in Section 21.4.2.

Once we agree on that Section 21.4.2 should be honored, the resolution
would be minor editorial clarification in Section 21.4.4.2.

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

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