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

[Alper Yegin]

Hi,

Thanks for putting this together. I think working out scenarios and
decomposing the process is a good approach.

What I'm thinking is, there are three phases leading to a service:
[1] Service subscription. 
For example, walking into a cell phone store, registering in a plan
(service) using my credit card, walking out with a SIM card (and a
phone).
[2] Service access admission.
When I turn on my phone, it performs SIM authentication, and gets
authorized to access the cellular network.
[3] Receiving the service. 
Making and receiving phone calls, or generating IP traffic. Traffic is
carried over a channel that can prove the authenticity of the
end-points.

Authentication algorithms and credentials used at each step are likely
to be different, but somehow (mostly cryptographically) they are bound
to each other.
Transformation from one to another would be interesting to this WG, I
think.

I think you also have these steps covered in you write-up. The
difference is, I thought what we call "enrollment" was step [1], whereas
your text suggests step [2] is "enrollment". The charter says:

  There are many cases where a service consumer needs to contact a
  service provider to get credentials that the consumer can use when
  accessing the service; part of this initial contact may involve
  the consumer and the provider mutually validating the other's 
  identity.

It'd be good to know which step we want to call enrollment.

Other comments:

   2.1. First, enrollment requires two channels, an OOB channel and an
in-band 
   channel.

I guess conceptually we can have this separation. In some cases, they
may be the same.

   2.2. Second, ease of use requires that the OOB channel is one-way.
This is because

Same comment for this one too. Sometimes it may be two-way.

  2.5. We want the process initiated by the user, not happen
automatically. This is

A user agent (software) might be acting on behalf of the (human) user
though.

Regards,

Alper





-----Original Message-----
From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu]
On Behalf Of Walker, Jesse
Sent: Monday, March 29, 2004 10:06 AM
To: ietf-enroll at mit.edu
Subject: [ietf-enroll] Some thoughts on ENROLL's direction

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