[ietf-enroll] Re: Notes from Cullen presenting on TTI in enroll

[Max Pritikin]

Cullen and Rohan, thanks again for representing me there.

Everybody,

I'm more than interested in answering any questions or continuing the
discussion online. From Rohan's notes some quick comments:

On Tue, 15 Jul 2003, Rohan Mahy wrote:

> Jim Schaad asked how the leap of faith model maps to TTI, gave an
> example of imprinting with ssh-keygen

Leap of faith is less a model than a mechanism. Essentially though one
could concider this an example of TTI where the introduction material
includes a wildcard key material.

For ssh-keygen the user is just generating key material. During later ssh
exchanges this material should be verified out-of-band, but lacking a
protocol for such things most users just accept it.

> Someone got up at mic to support the model (supported working on
> Introduction)

Thank you.

> Someone asked if this applied to Users as well as Devices.  yes
>
> comment that this was already "solved" in 3g and cable (using
> kerberos).  he didn't understand the full flexibility of the model.
> Jim Schaad said yes they were introduced at the factory

I'm not sure which 3g mechanism is being refered to. For cable (cable
modems?) a well known root is used. A well known root limits the number of
introductions to one (send the well known root around) and the
administrator usually does this during installation.

For kerberos either a pre-shared key is used, which requires the transport
of that key (introduction) or pkinit is used ... which requires the
introduction mechanisms to securely perform pki enrollment.

> comment that we should be clear about the difference between a user
> helping a device imprint, and a device helping a user imprint (because
> a human can't do exponentiation) (Paul Hoffman)

Sorry I missed you Paul. The TTI model does not require complex keys a
device helping a user imprint is directly supported. The later enrollment
and authentication mechanisms must of course support simple symmetric keys
if users are invovled (as that is all they normally use).

I agree that an example of this scenario should be included.

> random comment that a burnt in key is like a console port for
> imprinting a users keys

I'm thinking that a burnt in symmetric key is more like a default password
prior to any imprint sequence. After imprint some other key is used.

A burnt in asymmetric key is very much like a console port in that it
allows a introducer an alternative to physical security when imprinting
the new device. Take the example of a new wireless device on a home
network, the user may use knowledge of the burnt in public key to
determine that the wireless network accessable new device is really the
device expected.

Introduction mechanisms for how the user knows which is the burnt in
public key include reading it off the device, bill of sale, OR recieving
it from the manufacturing in electronic form. If the later then this is an
example of an introduction where the user (and their local system) is the
Registrar and the manufactere or vendor is the introducer. It is
introductions 'all the way down' until the security requirements don't
require it.

> concern about expanding scope of the charter

>From the charter:

> When doing enrollment of a user against a service provider, three pieces
> of information need to be provided or created in order to support
> authentication of the user to the provider and to allow for additional
> security services to be provided any information exchanged.  These
> pieces of data are:
>
> 1.    The name of the entity being enrolled,
> 2.    A piece of keying information to be used
> 3.    A set of permissions for operations for the entity being
> enrolled.
>
> This group will create a model to be used in describing enrollment
> procedures and create a document for a framework how this is to be done.
> The group will then produce three documents profiling the use of the
> framework for the following cases:
>
> 1.    A shared secret key
> 2.    A base asymmetric key
> 3.    A bound asymmetric key (e.g. an X.509 certificate).

The TTI model directly addresses the charter and provides a clear path
toward supporting shared secrets, raw asymmetric keys, and X.509
certificates.

For review I've posted the presentation at:
http://www.employees.org/~czmax/tti/ttimodel-cj1.ppt

Thanks,

	- Max