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

Walker, Jesse jesse.walker at intel.com
Mon Apr 19 12:49:29 EDT 2004


Sandi,

-----Original Message-----
From: Roddy, Sue [mailto:saroddy at tycho.ncsc.mil] 
Sent: Monday, April 19, 2004 9:38 AM
To: Walker, Jesse; Alper Yegin; ietf-enroll at mit.edu
Subject: RE: [ietf-enroll] Some thoughts on ENROLL's direction

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?

[Walker, Jesse] I do not think it is off base; manufacturer-installed
uniqueness is feasible, given the work that has transpired on TPMs.

The crux of the problem in my mind is how the two machines being
introduced know they are talking to each other instead of to a third
machine with a unique secret loaded by its manufacturer. This will be
dealt with by what you call "convey that information into some
management entity at first time use" and what I call an out-of-band
transfer. The introduced machines will some how use this transfer to
verify that they are indeed talking with the party their users want them
to be talking with and not to some other machine.

-- Jesse 




More information about the ietf-enroll mailing list