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

[Max Pritikin]

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

Although of course we have to accept that in some deployments (small
scale for example) people may find entering (or verifying) the data
manually is a useful case. Thus we shouldn't completely ignore it. 

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

So I see us discussing the flow of the cryptographic key and
provisioning information. Along with the possible ordering of events but
leaving out of scope the details wrt each system implementation. (Which
isn't to say we won't discuss them but that those discussions lead to
requirements ENROLL must meet rather than requirements on the systems
using enroll). In general. 

	- Max

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