Re: RFC/patch 1/6: wusb: add authorization control for devices

On Wednesday 25 April 2007, David Brownell wrote:
> On Wednesday 25 April 2007, Inaky Perez-Gonzalez wrote:
> > On Tuesday 24 April 2007, David Brownell wrote:
> > > On Tuesday 24 April 2007, Inaky Perez-Gonzalez wrote:
> > > > This patch introduces 'struct usb_device'->authorized. Devices with
> > > > that bit set can be used in the system (drivers are allow to
> > > > attach). Devices that don't will have the usb_probe routine aborting
> > > > driver binding.
> > > >
> > > > This is needed for WUSB devices: until we don't do the crypto
> > > > handshake, we can't allow the device to be used -- but in the
> > > > meantime, we need to be able to talk to it's default endpoint.
> > >
> > > How would this be different from testing whether
> > >
> > > 	udev->state == USB_STATE_UNAUTHENTICATED
> > >
> > > Other than "authenticated" != "authorized" ... as in, WUSB talks
> > > about the not-authenticated state, but a "not authorized" notion
> > > exceeds (what I recall of the) WUSB specs by presuming an identity
> > > based acceess control mechanism.  (Access control list, etc.)
> >
> > Well, for once, the authorized-to-connect/authenticated are two
> > different concepts (as I have explained in previous emails).
>
> And WUSB devices only need the "authenticated" notion ... the other
> notion really should not get mixed up with this one.  I've seen too

Correct, and they are kept completely separated. 

The reason why WUSB auth requires the 'autorization' control is that 
before we are done authenticating, we need to do normal USB transactions 
with them in EP0 (to establish the authentication and in some cases--when
doing numeric pairing--to establish the trust relationship itself).
So I need a USB stack capable of talking to a unauthenticated device
the same way as if it were a normal device. The difference is about it
being only partially available (only a few requests will fly--the ones
for authenticating) and once that is done, I need to tell the USB stack
to finish the enumeration...

> much confusion caused by security code confusing the two.  Way too
> much trouble caused by that confusion too (and when I say "trouble"
> I certainly include "designed-in security bugs").

...so that's why, if for implementing the WUSB I kept both concepts
completely separated; authorization to connect on one side, authentication
in another. User space first authenticates, and if it matches, then
it authorizes the kernel to fully enumerate the device--both mechanisms
are kept completely unmixed.

I think at the end we are talking about the same thing

> > On the case of udev->state, I considered that, but rejected it due
> > to the following reason: a non-authorized to connect device could
> > be in the DEFAULT/ADDRESS/CONFIGURED or SUSPENDED states, as what
> > differentiates from a normal device is that drivers are not bound
> > to it, so effectively, it cannot be used.
>
> But again, WUSB doesn't have that notion.  If (big if!!) that notion
> of "authorization" is going to enter the system, it should not be
> coupled to patches that enable WUSB.

Yes, I agree--it does not strictly in the sense of the word (there 
are devices than can word with no authentication/encryption). 

But you still need (as I said above) full transaction support from 
the stack. At this point, the concepts become orthogonal for 
implementation purposes (unless we want to modify much more of the
USB stack just to be purists with the WUSB spec, which frankly,
is not my mission). 

I don't really care if the auth state comes before or after; all I 
need is that unauth, auth, default and configured are basically the 
same state (actually substates of connected) and that allows me to 
reuse all the unmodified USB stack code state machine by just 
qualifying the substate using an extra bit. Makes 

it easy.

> > I am still pondering how much the USB_STATE_UNAUTHENTICATHED/
> > RECONNECTING states can be used for the WUSB auth model, as we need
> > the device up and running and ready to service requests on ep0 to
> > do the authentication--so that means the whole stack needs to recognize
> > it as a normal device.
>
> I'm pondering your pondering ... that state is part of the WUSB spec,
> so either that spec has fundamental problems *or* you're missing a
> few key points.
>
> I'm suspecting the latter.  And that this is the sort of issue that
> becomes a lot clearer when extraneous issues (i.e. "authorization")
> get stripped out, and the code really implements the stuff (like
> moving a device -- wired or not -- through authentication states)
> causing the confusion, rather than being ground work for it.

They can't be more stripped out than they are with this design :)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel