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

[Roddy, Sue]

I had a somewhat differing view of "enrollment" and if my tangent is too far
off, I understand.

When I think of any device wanting to become "aware" of it's home network
for key management or other management functions (downloads, upgrades, etc)
I think of some form of unique identifier (across all vendors to avoid
collisions) loaded in at manufacture.  This could even become some input to
an initial key 'seed' for subsequent 'first time' authentication to it's new
home domain.

That way, if a device comes off a production line with some established
information, it can convey that information into some management entity at
first use time, which would authenticate it and allow subsequent replacement
of key, upgrade of configuration, etc.  The Out-of-Band channel would be
that the provisioning or sale of that serial number is now in a given
domain.

Is this way off base?

Sandi Roddy
CISSP
TD Security, I53
National Security Agency
currently on STDP Tour


-----Original Message-----
From: Walker, Jesse [mailto:jesse.walker at intel.com]
Sent: Wednesday, April 14, 2004 10:09 AM
To: Alper Yegin; ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction


Alper,

----snip----
> 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).
[Walker, Jesse] Ok. That was not the intent, so perhaps this part of the
model is broken or at least the description. The intent was the
observation that the transfer of information across the OOB channel
shows the user wants to enroll some device, so why should she have to do
anything more? That is, the OOB transfer is the user's expression of a
policy decision, and that should be sufficient to accomplish the
configuration.

----snip----

> 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.
[Walker, Jesse] I think the one-way-ness of the OOB channel is
fundamental in the basic model, because we want the model to work with
the broadest possible set of physical realizations. It seems like one
can always augment one-way communication with two-way, but not the other
way around.

This discussion indicates your desire that we provide for more than the
minimum. Doing more than the minimum is always disconcerting, because it
is hard enough getting even one security scheme right. But if it is
required, then that is what we will have to do. We'll see where the
discussion goes.

-- Jesse


_______________________________________________
ietf-enroll mailing list
ietf-enroll at mit.edu
https://mailman.mit.edu/mailman/listinfo/ietf-enroll