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

[Roddy, Sue]

Max, I prefer Sandi....

Some clarification please - is the intent to have the OOB exchanges
"managed" by humans who will be populating information from some external
markings on a given piece of equipment?  Thus the option of using a baked in
UID?  

I had thought that some form of either IP or "over-the-air" exchange between
the equipment and the management center as the key conversion/exchange
process would be part of domain enrollment, along with something that a
human "sponsor" needs to do to inform the management center that this
specific equipment was indeed part of their domain.  

Is ENROLL only addressing the human factor exchange?  And is there a
constraint that only externally viewable identifiers will be
required/utilized for UID?

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


-----Original Message-----
From: Max Pritikin [mailto:pritikin at cisco.com]
Sent: Monday, April 19, 2004 12:52 PM
To: Roddy, Sue
Cc: 'Walker, Jesse'; Alper Yegin; ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction


Sandi (or is it Sue?),

As you point out an unique identifier provides authentication
information but an "OOB" exchange to provision the management entity is
still necessary.

What a baked in ID does is allows the cryptographic identity information
to be bound to a unique identifier that is arguably 'easier' for humans
to read. This allows it to be transported on paper (bill of sale),
placed on stickers (serial number sticker on device) and inputed or
compared by user who are actively part of a secure deployment.

These are advantages but they are not strictly necessary. As such our
discussions should include them but shouldn't require them. Thus we're
back to discussion what/how/which is the OOB exchange and how best to
incorporate that into a protocol itself.

	- Max


On Mon, 2004-04-19 at 09:37, Roddy, Sue wrote:
> 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
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll