Re: Provisioning, Password Strength (was RE: comments)

[Chris Lonvick <clonvick@cisco.com>]

Hi George and all,

(Apologies for the delay.)

On Wed, 18 Jun 2003, George Jones wrote:

> On Tue, 17 Jun 2003, Chris Lonvick wrote:
>
> > > Actually, per ericb's suggestion, I think a better idea is to have
> > > things shipped unconfigured (no passwords, etc.) and simply not allow
> > > a service/account/whatever to be used unless the user explicitly
> > > configures it.
> >
> > I like that approach as well.  It may be good to differentiate between
> > provisioning and managing as well.  There are a lot of problems associated
> > with provisioning which are similar to configuration but are much more
> > difficult to address.
>
> Examples ?   Any cases where I've got things mixed now ?

I need to do a thorough read-through of the document but at this time I
don't see that the two are unmixed.  :-)  My concern here is that an
attacker may intercept communications during the initial provisioning of a
remote device, or they may substitute a device with the hopes that an
administrator will configure it as a valid device and leave sensitive
information in it which would then be easily retrievable by the attacker.
Changing the configuration of an existing device may not be as susceptible
to this problem as the administrator should have some way to validate that
it is actually a member of the flock, and not a rogue or a decoy.

Essentially, bidirectional authentication is a good thing but it's
sometimes hard to accomplish during the initial remote provisioning step.
I believe that best way (among the proposals that I've heard) to establish
the validity of the remote device is through a pre-provisioning step.  In
this step, a signed certificate (or other immutable or nonforgable
identifier) is placed into the device.  When it is installed and
provisioned, the administrator may then check that the certificate
presented by the device is the same as the one recorded during the
pre-provisioning step.  Somewhat of a pain but once that's accomplished,
you have good assurance that you are configuring the correct device.  I've
lost the pointer at the moment but I belive that the DOCSIS specifications
address this by requiring that the vendor provide recorded, vendor signed
X.509 certificates with each cable modem.

Is this thought worthy of being included in the document, or is that a bit
too far reaching at this time?  It may be best to place a note in the
Security Considerations section with an overall warning of this if that's
acceptable.

Thanks,
Chris


>
> > > See above.
> > >
> > > >  The device should provide the capability
> > > > - to enforce 'strong' password selection.
> > >
> > > Care to provide a definition of "strong" ?
> >
> > Is this a recommendation for the device or for a device within the
> > >system?
>
> Don't care.  If people are setting passwords, they should be strong.
> More accuratly, there should be the option of requiring them
> to be strong...if someone has a policy that says "thou shalt have
> weak passwords" they should be able to have them.
>
> > It would be difficult for a small hub to be able to review contained
> > password for "strenth" (whatever that definition may become) but it is
> > relatively easy for an Access Control Server (ACS - i.e. a RADIUS server)
> > to perform such checks.  I'd recommend going with the association made in
> > the T1M1.5 document which allows that check to either be performed on the
> > device, or within the system.
>
> Actualy, it sounds like two seperate requirements:
>
>   (1) Enforce the selection of strong passwords.
>
>   (2) Support ACS servers.
>
> (2) may be part of the implementation of (1).   (2) may not be univeral.
> (1) should probabably be universal.
>
> I could still use a definition of "strong".
>
> Thanks,
> ---George
>