[ietf-enroll] Some thoughts on ENROLL's direction

[Walker, Jesse]

Hi Jari,

My comments below are prefaced with [JRW]

I think your model is very useful, and provides
some practical answers that might make ENROLL
more concrete than perhaps seen before. I believe
this is needed.

[JRW] Thanks.

Some additional comments inline:

> Storyboard from the enrollee's perspective. The user decides to 
> configure his device to operate in a new domain. He uses an
Out-Of-Band 
> (OOB) channel to move some data between his device and one of the 
> devices in the new domain. A USB token or cross-over cable is an
example 
> OOB channel common among computing devices, and IR is a common channel


Do you intend to cover a 'null' OOB exchange, such as something
which could be used in a pure leap-of-faith solution? (I have
yet to see an application of pure leap-of-faith that would make
sense, but I'm just trying to see what you intend to cover.)

[JRW] I hadn't thought about this. The intention was to establish
something securely. We are already seeing services based on pure-leap of
faith in 802.11; in particular, people are using browsers under the
e-commerce model at hot spots. We all know this is subject to session
hijacking.

-- snip --

> When the enrollment process completes, the enrolling device is 
> configured with
> 
> a. an authentication algorithm to use with this domain
> 
> b. an identity for the new domain
> 
> c. a key that will subsequently authenticate the domain to the device
> 
> d. an identity the enrollee will subsequently use to identify itself
to the
> 
>    domain

Re: b & d. I suppose identity does not necessarily have
to be a X.509-like name; in some cases a key itself could
act as an identity. Did you intend to cover that possibility
as well, or is there some reason which demands a separate
identity in every case?

[JRW] yes, in some cases the key itself could be the identity. This is
certainly the case at enrollment time.

> e. a key that will subsequently authenticate the device to the domain
> 
> f. a set of permissions for its operation in the domain, which always 
> includes
> 
>    at least basic network access to the domain

1) I suppose this depends on the specific application. Presumably
you might enroll to an application which is separate from
network access, and the system could not grant you access
even if it wanted to.

[JRW] Fair enough. I thought about enrolling for other types of access
controls as well, but this seemed to complicate the problem
tremendously.

2) I think making "network access" the primary target application
case for ENROLL might make the WG's work more bounded/interesting/
feasible. I'm not suggesting a specific scheme tailored for this
application, but it may be useful to have a primary target against
which we could compare our results, provide examples, etc.

[JRW] Right. My feeling is that if we properly restrict what we are
doing, we can at least allow devices to get themselves network access.
If they need other permissions, this can be done using other techniques.

-- snip --

> 2.2. Second, ease of use requires that the OOB channel is one-way.
This 
> is because with a USB token or IR channel used for the OOB transfer,
the 
> user cannot be expected to run back and forth between devices, at
least 
> not if we expect real users to perform the operation themselves. This 
> implies that the initiator of the in-band protocol might be the
enrollee 
> in some cases and the enroller in others, because it is equally
unlikely 
> that the process will be successful if the user has to perform the OOB

> transfer in one direction. This means that there will have to be a 
> designation step at some point, where the devices agree on roles for
each.

Agreed, I think. But doesn't the above assume that something in the
protocols is asymmetric? Perhaps a symmetric protocol would also
be possible, and in that case the step would not be needed.

[JRW] My model is the USB token, or an IR device that can act like one.
You load the OOB information from one of the devices, move the token to
the other device, and then download the OOB information from the
transfer device onto another. The world does not have to adopt my model,
but that is the one I am using. If you want to design another one, be my
guest. I don't know how to make the OOB transfer two-way without the
user running back and forth between the devices.

-- snip --

> e. The third logical protocol is a designation protocol, to indicate 
> which device plays the role of enrolling device and which enroller. 
> Since we have specified that the out-of-band information is one-way,
and 
> that the user can move the out-of-band information from either to the 
> other, the identification protocol is logically distinct from the 
> designation protocol.

I'm not sure about this one.

[JRW] That's fine; that is why we are having a discussion.

-- snip --

> g. Once a security association is in place, roles have been
established, 
> and capabilities have been agreed upon, the device can finally enroll.

> The enrollment protocol establishes the identities, credentials, and 
> access rights that will be used subsequently. Example identities
include 
> device names for use within the context of this domain and key 
> fingerprints. Example credentials could include device names bound to
a 
> randomly generated symmetric key, or a certificate issued by the
domain 
> binding a domain assigned identity to the device's public private key 
> pair. Examples of permissions include the right to access the network,

> the right to perform mesh routing, or the right to admit new devices
to 
> the domain. Each application of the architecture will have to
enumerate 
> the set of permissions afforded by that application.

Agreed.

Taking the network access example once again, maybe the identities
that we have been talking about could be clarified a bit. The clients
would have what we call NAIs (RFC 2486) and the network entities
would have... either nothing or MAC addresses or 802.11 SSIDs.

[JRW] That's fine with me.

-- snip --

> Does this seem right? If not what is wrong and what is missing? Or if 
> this seems ok, what are our next steps to making this happen?

If we can agree on this model (with some discussion & tuning
of course), then I suppose we could split the work into different
documents, each tackling their specific protocol piece.

[JRW] Ok. It sounds like we have a start towards a model. Let's see
where this goes.

-- Jesse