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

JINMEI Tatuya / 神明達哉 <> Tue, 03 August 2004 06:14 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id CAA17391; Tue, 3 Aug 2004 02:14:18 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BrsRL-0004fP-0z; Tue, 03 Aug 2004 02:06:23 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BrsKx-0007tX-9P for; Tue, 03 Aug 2004 01:59:47 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id BAA04170 for <>; Tue, 3 Aug 2004 01:59:46 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BrsNt-00046w-Mh for; Tue, 03 Aug 2004 02:02:54 -0400
Received: from (unknown [2001:240:5bf:128:85e5:b60e:c1e:7e67]) by (Postfix) with ESMTP id BFDF71525D; Tue, 3 Aug 2004 14:59:37 +0900 (JST)
Date: Tue, 03 Aug 2004 14:59:39 +0900
Message-ID: <>
From: JINMEI Tatuya / 神明達哉 <>
To: Bernie Volz <>
Subject: Re: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00
In-Reply-To: <000001c4791b$6e25deb0$>
References: <> <000001c4791b$6e25deb0$>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>>>>> On Tue, 3 Aug 2004 01:33:37 -0400, 
>>>>> "Bernie Volz" <> 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

> 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 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

   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

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 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
= "message that has not been authenticated" (2nd paragraph of
= "unauthenticated messages" (3rd paragraph of
= "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

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

dhcwg mailing list