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

"Bernie Volz" <volz@cisco.com> Tue, 03 August 2004 05:42 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03245; Tue, 3 Aug 2004 01:42:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrryV-0007UR-6s; Tue, 03 Aug 2004 01:36:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrrwK-0006IJ-4w for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 01:34:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02899 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 01:34:19 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrrzJ-0003hS-O3 for dhcwg@ietf.org; Tue, 03 Aug 2004 01:37:27 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2004 22:35:14 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i735Xh78013603; Mon, 2 Aug 2004 22:33:43 -0700 (PDT)
Received: from volzw2k (rtp-vpn3-154.cisco.com [10.82.216.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO31694; Tue, 3 Aug 2004 01:33:38 -0400 (EDT)
From: "Bernie Volz" <volz@cisco.com>
To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= <jinmei@isl.rdc.toshiba.co.jp>, "'Christian Strauf'" <strauf@rz.tu-clausthal.de>
Subject: RE: [dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00
Date: Tue, 3 Aug 2004 01:33:37 -0400
Organization: Cisco
Message-ID: <000001c4791b$6e25deb0$3e858182@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
Importance: Normal
In-Reply-To: <y7v7jsrmc7j.wl@ocean.jinmei.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

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.

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.

So, perhaps the "Unauthenticated" category needs another condition - if the
client or server is unable to validate a message because it lacks the key
(for the realm/server) or doesn't support the authentication protocol.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> On Behalf Of JINMEI Tatuya / _–¾’BÆ
> Sent: Monday, July 26, 2004 3:59 AM
> To: Christian Strauf
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] Comments on 
> draft-jinmei-dhc-dhcpv6-clarify-auth-00
> 
> 
> Hello,
> 
> Thanks for your positive feedback, and sorry for the delayed response.
> 
> >>>>> On Tue, 20 Jul 2004 16:23:41 +0200,
> >>>>> Christian Strauf <strauf@rz.tu-clausthal.de> said:
> 
> > I paragraph 4. you write:
> 
> > "A reasonable interpretation of the phrase is probably as
> follows: a
> > DHCPv6 message is called unauthenticated when it fails the
> validation
> > test described in Section 21.4.2, it does not contain an
> > authentication option, or when it includes an authentication option 
> > but does not have authentication information when necessary."
> 
> > I would propose a minor rephrasing to clear the language up
> a little
> > (if I understand the above paragraph correctly, the following
> > rewording should work):
> 
> > "A reasonable interpretation of the phrase is as follows: a DHCPv6
> > message is called unauthenticated if it fails the validation test 
> > described in Section 21.4.2, if it does not contain an 
> authentication
> > option, or if it includes an authentication option without the
> > necessary authentication information."
> 
> OK.  I've modified the local source of the draft with the
> suggested change.
> 
> > Minor typos:
> 
> > para 2.:
> > 	-It should also be noted that [RFC3315] does not define how the
> >          server should do when it receives
> >         +It should also be noted that [RFC3315] does not
> define what the
> >          server should do when it receives
> 
> > para 3.:
> > 	-3.  What If Reply Is Detected
> > 	+3.  What If Replay Is Detected
> 
> > para 5.:
> > 	-Apparently this contradicts with the requirement in Section
> >          21.4.2.
> > 	+Apparently this contradicts the requirement in Section 21.4.2.
> 
> > para 5.1.:
> > 	-Accepting an non-authenticated
> > 	+Accepting a non-authenticated
> 
> Thanks, fixed in the local source.  (The second and fourth
> typos should already be fixed in the published version of the 
> draft.  I guess your comments are for a preliminary version 
> available at my web
> page.)
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center,
> Toshiba Corp.
> 					jinmei@isl.rdc.toshiba.co.jp
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg