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

[Jari Arkko]

(resending, original e-mail bounced from the list.)

Hi Jesse,

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.

Some additional comments inline:

> While on vacation last week I had time to think about ENROLL. Here is a 
> possible model for ENROLL operation. This discussion is trying to tease 
> out some requirements for this function. The first part of the 
> discussion gives a storyboard for what I think we want to happen. The 
> next part attempts understand the implications of the storyboards. It 
> finally closes with a suggested functional decomposition and discussion 
> of WG scope.
> 
>  
> 
> 1. Storyboards
> 
>  
> 
> 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.)

> for consumer electronics devices. The user would want the OOB transfer 
> to be as easy as possible, while implementers would like it to work with 
> arbitrary OOB channels, and together these preferences dictate that the 
> OOB transfer is not a two-way exchange, as doing so would require the 
> user to move information back and forth between devices, perhaps 
> multiple times, on many OOB channels. The user should be able to perform 
> the OOB transfer in either direction, as a procedure that requires the 
> information be always transferred, e.g., from the enrollee device to the 
> enroller, is unlikely to be simple enough for arbitrary users to use.

These are excellent and practical requirements.

> The transfer of the OOB information somehow triggers the enrollment 
> process. The enrollment process occurs over the normal in-band channel, 
> e.g., 802.11. It may be necessary in some cases for the user to 
> designate which is the enrollee device, but no other user intervention 
> should be required in the normal case. Examples where this extra step 
> may be required are enrollment of personal devices into personal 
> networks, where both devices might play either role of enrollee or 
> enroller, or the initial configuration of a new network at home, etc.
> 
> 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?

> 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.

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.

> Storyboard from the enroller perspective. The operator designates an 
> enroller device. It plays roughly the role of a PKIX RA. When the OOB 
> exchange completes, the enroller device executes the in-band protocol to 
> verify that it is indeed communicating with the enrollee designated by 
> the OOB transfer. Once this is accomplished, the enroller device and the 
> enrollee agree on
> 
>  
> 
> g. the authentication method the domain and the enrolle will use to 
> authenticate
> 
>    one another
> 
> h. a name for the domain
> 
> i. a key that will authenticate the domain to the enrollee
> 
> j. a name for the enrollee
> 
> k. a key that will authenticate the enrollee to the domain
> 
> l. a set of permissions for the enrollee, which includes at least access 
> to the
> 
>    domain's network.
> 
>  
> 
> The process may require the operator of the enroller device to approve 
> the enrollment prior to its completion, or approval may be automatic, 
> e.g., if the enrollee device presents a valid credit card number. Other 
> operator intervention should not be required.
> 
>  
> 
> 2. Architectural implications
> 
>  
> 
> If these storyboards are correct, they have several implications:
> 
>  
> 
> 2.1. First, enrollment requires two channels, an OOB channel and an 
> in-band channel. The goal of this separation is to establish basis for 
> believing each of the devices is communicating with intended peer. The 
> model we are using is the in-band channel gets bound to information 
> transferred over the OOB channel, to serve as the basis for this belief. 
> This is different from the e-commerce model, which posits that anyone 
> with a certified name is the intended peer. When a radio channel is used 
> as the in-band channel, we need some reason to believe the device in my 
> hand is communicating with the device in yours, and not with one 
> controlled by someone else that just happens to have a certified name.

Agreed.

> 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.

> 2.3. There must have some way for enroller to advertise authentication 
> mechanism(s) used in the domain and for the enrollee to select which 
> among these it will use. This is a policy negotiation step.

Agreed. To put this in the network access and 802.11 terminology,
we could require an EAP method to be agreed upon.

> 2.4. Finally there is the enrollment step itself -- the process whereby 
> (a) the enrollee and enroller agree on identities for one another (b) 
> and bind keys to these identities.

Ok. My earlier question about identities still applies...

> 2.5. We want the process initiated by the user, not happen 
> automatically. This is because the user provides the ultimate access 
> control for his own device, and will not take kindly to external 
> “services” unknowingly inviting themselves in without his permission.

Hmm... this would certainly apply in the usual laptop/pda
network access enrollment case. But I'm not yet convinced
it holds for all cases. Unfortunately I don't have a
counter example :-(

> 2.6. Since we want the in-band protocol to work with 802.11i, it must 
> present itself as an EAP authentication method. This is because an 
> 802.11i access point expects mobile stations to use an EAP method to 
> authenticate themselves prior to offering any further service.

Hmm... interesting! Yes, this would allow unmodified 802.11
protocols to be run, and the actual enrollment take place at
a higher layer. Supposedly you'd run this EAP method once,
and after that you'd run another, chosen EAP method such as
EAP Archie or EAP TLS, using the keys and identities agreed
on the first run.

> 3. Discussion
> 
>  
> 
>  From this description, there are a number of separate components: two 
> different devices operating in enrollee and enroller roles, and a suite 
> of five logical protocols that work together to effect enrollment. More 
> explicitly,
> 
>  
> 
> a. There is, of course, the enrolling device, as well as
> 
>  
> 
> b. what we will call the enroller device. A enroller device is a special 
> purpose server whose sole function within the architecture is to 
> coordinate enrollment. Obviously, the identification protocol runs 
> between the registration server and the enrolling device. Also the user 
> moves the out-of-band information between the enrolling device and the 
> registration server.

Yes. Or a pair of devices to be "paired".

> c. The first protocol operates over a one-way, out-of-band channel, used 
> to exchange information between devices. This information is used to 
> provide a root of trust in the subsequent steps of the enrollment process.

Yes.

> d. The second protocol is an “identification protocol,” consuming the 
> out-of-band, which is used to establish a secure channel between the 
> enrolling device and the domain's enroller. This protocol will 
> demonstrate that the domain is talking with the intended enrolling 
> device, and that the enrolling device is talking with the intended 
> enroller. The second point of this the identification protocol is to 
> establish a security association which is used to protect the remainder 
> of the enrollment process. The second point is to bind proof of 
> possession of enroller’s and enrollee’s keys to the OOB information, so 
> that everyone knows they are communicating with the intended peer.

Agreed.

> 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.

> f. Once the role of enrollee and enroller is established, the parties 
> must negotiate the capabilities of the enrollee against the policies of 
> the domain. Not all devices will be capable of using every 
> authentication technique, so there will have to be a question and answer 
> session to establish whether the two can indeed communicate. We will 
> call this the negotiation protocol.

Yes. Alternatively we fix the type of credentials and
authentication methods allowed through ENROLL and skip
this phase.

> 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.

> I think the purpose of the ENROLL WG is to establish an architecture 
> that is along these lines, define standardized pieces such as these, and 
> to define how the pieces work together to accomplish the entire 
> enrollment process.

Sounds good.

> 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.

--Jari