Subject: RE: draft-ietf-dhc-userclass-08.txt

From: Nathan Lane <[email-masked]>
Date: Fri, 14 Jul 2000 11:31:45 -0500

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, July 14, 2000 11:22 AM
> To:	DHCPv4 discussion list
> Subject:	RE: draft-ietf-dhc-userclass-08.txt
> 
> >It is required to simplify the management of such things as access lists
> and
> >firewall rules.
> 
> If that's the intent, there are a few problems:
> 
> a. DHCP isn't an access control mechanism, even with authenticated DHCP;
>    the user can choose their own static address and thereby get around
>    any rules you impose.
> 
	Not necessarily.  If the DHCP server writes the access list in the
router or uses other means to limit the ability to route addresses not
assigned by the DHCP server.  This doesn't prevent LAN access, of course,
unless the DHCP server also dynamically writes VLAN information into the
switch.

> Therefore the user can claim any userclass they
>    want unless the DHCP server intends to verify the userclass
>    assignment based on the client identifier.
	I would certainly do that.  The draft doesn't enforce any specific
server behavior on this option.

	-Nathan Lane

**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jul 2000 09:49:23 -0700

The user class option was originally intended to be something where
the user typed in a user class and got different options on that
basis, probably as documented by the system administration staff.   It
has no authentication.   You can't use it as a credential - if you
have to look the credential up on the server, there's no point in the
client sending it.

However, as most of us know but usually don't write in RFCs, the only
reason the Internet hasn't been taken over by bandits already is that
most of us are trustworthy.   It's certainly not because we have much
security.   Sometimes it works to just tell people they should use a
certain value for the user class, and trust them to honor your
request.   This is useful, despite the fact that it isn't secure.   It
is also useful to use the user class option to say where you're
located, so you get the right printer.

So I think it's perfectly legitimate to use these as examples in the
draft, although you'll spend less time arguing with security people if
you don't mention any access control mechanism that depends on the
honor system.   So using the printer selection bit as an example is
probably the best thing to do.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 17 Jul 2000 10:19:42 -0700

[Ted Lemon]
> The user class option was originally intended to be something
> where the user typed in a user class and got different options
> on that basis, probably as documented by the system administration
> staff.  It has no authentication.   You can't use it as a
> credential - if you have to look the credential up on the server,
> there's no point in the client sending it.

[Barr Hibbs]
I suggest thinking about this in business terms:  a system administrator
might choose to organize their clients in several different ways to simplify
their ability to understand and configure them for their operating
environment.

For example, older clients probably do not include any sort of machine
readable serial number (useful for inventory purchases), while newer systems
do.  Is it useful to group older machines in one vendor class and newer
machines in another?  It certainly may be for some implementations.

Likewise, in an automatic call distributor (ACD) application, an
ACD-attached client may need to use a DNS server integrated with the ACD, so
a User Class Identifier that categorizes clients as belonging to the user
class of ACD-attached clients or to a general class would be quite useful.

Don't obscure the purpose of the class identifier by changing it into some
sort of authenticator.

[Ted]
> It is also useful to use the user class option to say where you're

[Barr]
...another useful application of the User Class Identifier....

[Ted]
> So I think it's perfectly legitimate to use these as examples in
> the draft, although you'll spend less time arguing with security
> people if you don't mention any access control mechanism that
> depends on the honor system.

[Barr]
Actually, any discussion of how to use a DHCP option to address a "problem"
in the routing or security areas is bound to draw argument from the other
areas.

--Barr

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 17 Jul 2000 10:19:42 -0700

[Bernard Aboba]
>> DHCP isn't an access control mechanism, even with authenticated
>> DHCP;  the user can choose their own static address and thereby
>> get around any rules you impose.

[Nathan Lane]
> Not necessarily.  If the DHCP server writes the access list in
> the router or uses other means to limit the ability to route
> addresses not assigned by the DHCP server.  This doesn't prevent
> LAN access, of course, unless the DHCP server also dynamically
> writes VLAN information into the switch.

[Barr Hibbs]
Are you proposing to write a new Internet-Draft to support DHCP server to
router or switch updates, Nathan?  While that is an interesting idea that
certainly deserves review and comment, I think it strays pretty far from the
purpose of the User Class Identifier.

I have always seen a need for finer classification of DHCP clients than the
Vendor Class Identifier provided, going all the way back to when Glenn Stump
first proposed this option:  in fact, depending on the business organization
and processes of an enterprise, there may be other useful classifiers that
could be proposed.

But back to the question of whether this option could be used to alter
router or switch configurations:  that discussion opens a whole new thread
that probably should be introduced simultaneously in the routing aread.
Let's keep the User Class Identifier focussed on what I believe to be its
original purpose as another useful way to classify clients so that an
administrator can deliver different sets of options based on some
identifiable characteristic.

[Bernard]
> > Therefore the user can claim any userclass they want unless
> > the DHCP server intends to verify the userclass assignment
> > based on the client identifier.

[Nathan]
> I would certainly do that.  The draft doesn't enforce any
> specific server behavior on this option.

[Barr]
We have long had an unwritten principle for DHCP options, that one option
generally does not depend on the value of another.  While that occasionally
leads to curious situations such as the FQDN in the DHCP-DNS options not
being required to bear any relationship to options 12 and 15, I would
strongly question any requirement for cross-validation of the User Class
Identifier with the Client Identifier before accepting it as the desired
mode of operation, and especially as I see immediate application for a User
Class Identifier without any relationship to routing, it would have to be a
very strong argument to win my support.

--Barr