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

[Roddy, Sue]

thanks for the clarification.  

I agree that the more automated the process, the less potential for error.
I was confused about the earlier statement about human "readability".  It's
one thing to track a device using a bar-code reader and labels (and then
relying on some protocol to convey that tracking data to some central point
of management) as opposed to requiring a user to enter the data manually.

I'm still trying to clearly understand the boundaries of ENROLL and what
areas it will and won't address, as well as what are the underlying "out of
scope expectations" that manufacturers will do and what are the "out of
scope expectations" that a human/tracker/life cycle maintainer (especially
if the devices change domains) must do.

thanks

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


-----Original Message-----
From: Max Pritikin [mailto:pritikin at cisco.com]
Sent: Wednesday, April 21, 2004 1:38 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,

On Wed, 2004-04-21 at 04:56, Roddy, Sue wrote:
> 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.  

More the latter I think (ie we agree). I define the entity driving this
introduction/enrollment process (the 'Introducer') as a system which may
include a user. 

Humans are not directly part of complex data exchanges. They use tools
(devices) that are part of the exchange. And as we focus more on
usability issues I think we'll find that humans will have an even
smaller direct role. I don't expect we ever will, or should, be in a
situation where people know and understand (and remember) and exchange
strong cryptographic information directly. We will always use devices
and tools for that. 

So from that perspective the human element may be a driver for the
process (e.g. directing their local device/system to introduce two other
device to each other). This level of tool use comes very easy and we
shorten the discussion by saying "the user introduces" when what we
really mean is "the user uses their laptop with some application to
perform an introduction". 

The advantage of this is that the human becomes one element of the
Introduction system - but a human is not a required element (rather the
human interaction may be limited to the setup and policy configuration
of the Introducer rather than the day to day introductions). 

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

No, I think that we need to support mechanisms that are completely
automated. Although as some point obviously human interactions are
involved. So it is important to identify how those interactions are
entered into the Introduction/enrollment systems.

	- max

> 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
> 
[snip]