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

[Alper Yegin]

Hi Jesse,

> What I want is a solution for you call step [1] below. The point of
the
> exercise is to configure authentication and access control credentials
so
> that you can later do [2] and [3]. It sounds like we disagree whether
the
> model I articulated describes [1] or [2]. So the first thing I'd like
to
> understand is why you think the model describes [2].

In your original message you said:

  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.

This suggests me your OOB corresponds to my [1] (service subscription),
and your enrollment process corresponds to [2] (service access
admission).

> Second, I disagree that the OOB channel can in general be the same as
the
> in-band channel, and we want one model that works with a large set of
> plausible media, including radio-based media. The requirement is to
> provide the user with assurance that the devices he wants to
communicate
> are the ones actually communicating. My disagreement with you stems
from
> the fact that all the secure examples I know of rely on a distinct OOB
> channel. If someone describes an algorithm that can provide genuine
> security without an OOB, then I'm sure everyone would be willing to
change
> the requirement. Until then, I am not willing to compromise on this.

I said OOB channel and the in-band channel "may be the same in some
cases." I agree they are not "generally" the same. 

[Assuming I have the same understanding of the channel concept in this
context] When I subscribe to a hot spot service by using my credit card,
I subsequently use the same 802.11 channel to access the service.

> Third, I believe the one-way-ness of my model's OOB channel is
essential.
> We want a model that will work the same way for a large subset of
> plausible physical realizations of the model. We want it in particular
to
> work with RFID tokens and USB tokens and indirect IR channels as well
as
> direct IR connections and cross-over cables. If we specified the
general
> OOB information transfer as two-way, then the user would have to move
the
> physical token back-and-forth between the enrolling and enrollee
devices
> to effect two-way communication. I do not believe this affords
acceptable
> usability. This is not to say that someone could not define a "value
> added" protocol to augment the standard model in a proprietary way for
> some physical realizations of the OOB channel, but I think
one-way-ness is
> a property we want in the base model.

This may be due to different understanding of the terms channel and
one-way-ness, but to me, having a cross-over cable between enrollee and
enroller constitutes a two-way channel.

> Finally, there is nothing wrong with agents, but if an agent is
running on
> my device, then I want it to "automatically" enroll only when I want
it to
> enroll. It may be possible to specify a policy that will allow
"automatic"
> enrollment (e.g., in the public network space, enroll with any network
> that advertise access for less than $5/day), but the point is that I
don't
> want my device to enroll in any network that does not match my policy.
> Enrollment is an access control function, and access control
pre-supposes
> that a human being is involved at some step. There is nothing (I hope)
in
> my model that requires thehuman to be involved at the time of
enrollment-
> -but then the human being has to be able to specify the policy
regulating
> when enrollment is allowed and when not. Even though I am an Intel
> employee, if someone drives past my house with an access point
advertising
> Intel's internal network, I don't want my laptop to enroll with it; I
> already know it is a rogue.

Agreed.

Alper



> 
> Hopefully that helps you better understand my perspective.
> 
> -- Jesse
> 
> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin at samsung.com]
> Sent: Tuesday, April 13, 2004 1:37 PM
> To: Walker, Jesse; ietf-enroll at mit.edu
> Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction
> 
> 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
>