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

["Bernie Volz" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> On Behalf Of JINMEI Tatuya / _–¾’BÆ
> Sent: Monday, July 26, 2004 3:59 AM
> To: Christian Strauf
> Cc: [e-mail]
> 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 <[e-mail]> 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.
> 					[e-mail]
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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