[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Enterprise-only or more...

Sorry for butting in (cutting in).

The definition of the Trust Anchor is problematic.  The phrase "highest
source of trust within a local context" is not clear.  More importantly,
the meaning I assign to it contradicts the discussion on this list.

I would say that a Trust Anchor is a Public key and (optionally or
always) an associated name that a relying party trusts for an unlimited
scope or a defined scope.  Examples of scope are name spaces,
certificate policies, application/usage types, and any combination of
the above.

I also think there is a simpler way to specify the protocol requirements
at the top level.

We need to define a protocol that can manage these potentially multiple
trust anchors that a relying party depends on.  By manage, we mean the
ability to add, remove or update the trust anchors in the relying party

The security requirements for the protocol are that the relying party
must be able to authenticate the source of trust anchor management
information, must be able to ascertain the authority of the
authenticated source to update the trust anchor information, and must be
able to ascertain that the information has not been changed from what
the authenticated source intended.

We would also like the protocol so that once the relying party system is
initialized with trust anchor information, the protocol can update the
trust anchor management information in-band (i.e., without assuming any
security beyond that afforded by the protocol itself) securely when one
or more (including all) trust anchors have been compromised and hence
need to be replaced.

-----Original Message-----
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
[mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Stefan
Sent: Friday, June 29, 2007 7:35 AM
To: Thomas Hardjono; Stephen Kent; Paul Hoffman
Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
Subject: RE: Enterprise-only or more...

I would like to be slightly more pragmatic.

1) Definition of TA.
This is something we need before a BOF. A TA is obviously a public key
that is the highest source of trust. The question is for whom and within
what context. I think the only reasonable answer is that a TA is always
a TA within a local context. What is TA for me may not be a TA for you.

We also have different level of trust infrastructures serving each
others. We may have a trust management infrastructure based on a trusted
directory that uses one TA. This infrastructure may then used to
distribute TAs for local applications through a directory based
infrastructure. In other cases the security infrastructure is flat (i.e.
for some devices) where we resort to manual procedures.

Attempt at definition:
Trust Anchor: A public key that acts as a highest source of trust within
a local context. A TA may also include parameters that constrain the
context of trust it is intended to serve.

2) What protocols to standardize
In the Enterprise environment a local system using TAs is often
subordinate to one ore more management systems with its own security
model. This might be a directory centric solution distributing
information over a secured network. Example: I bring my device/computer
on the physical corporate network where it is initialized through admin
passwords or tokens and in that process an number of TAs are imported
that makes it possible to communicate remotely in the future with the
enterprise network and update TAs for local applications.

In the flat device scenario which I assume can be mobile devices,
network routers, domain name servers etc, which are not tied to a common
database or directory, TA management needs to cover the complete sets of
security needs on its own.

Common for all scenarios seems to be the potential need for a common
format for the TA object itself and the parameters it is associated

Therefore one candidate for a standard could be a TA object format
- A public key (in the form of key + key parameters, or a self signed
- Optional additional parameters constraining trust in the public key,
- An optional signature

There are situations when a self signed certificate is not desired. This
is the case when I pick a public key from a trusted CA that I do not
control and which self signed root I don't have.

What more can we reasonably do? Currently I can't see it.
I doubt we can define a generic exchange protocol.
- For the device scenario I would suspect that any exchange protocol if
necessary need to be defined in a more local application context. E.g.
DNS SEC has its own solution and mobile devices have another while
wireless access points a third.

- For the Enterprise model I would think that the means of exchange will
be defined by local directory schemas or databases having their own
security model that would be hard to standardize.

Is there anything else?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx [mailto:owner-ietf-trust-
> anchor@xxxxxxxxxxxxx] On Behalf Of Thomas Hardjono
> Sent: den 27 juni 2007 00:02
> To: Stephen Kent; Paul Hoffman
> Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
> Subject: RE: Enterprise-only or more...
> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Stephen
> Kent
> Sent: Tuesday, June 26, 2007 12:57 PM
> To: Paul Hoffman
> Cc: Stephen Farrell; ietf-trust-anchor@xxxxxxxx
> Subject: Re: Enterprise-only or more...
> At 12:40 PM -0700 6/26/07, Paul Hoffman wrote:
> >At 1:30 PM +0100 6/22/07, Stephen Farrell wrote:
> >>...
> >
> >If there is one TA admin, and that person is someone other than me,
> >then your model does not work. That is, the bank needs to get the
> >single TA admin to bless the bank's TA.
> >
> >If there is more than one TA admin (say, a real TA admin plus the
> >controlling the application), then the bank only needs to convince
> >of the (probably the user) to install the bank's TA.
> >
> >I think a reasonable requirement is that the protocol allow the
> >to specify more than one TA admins. If that requirement is met, a
> >system where the user really does control the system can simply name
> >the user as a TA admin.
> There are multiple reasonable models.
> For example, a device may be "owned" by a vendor who delegates to a
> user
> or local admin the authority to install TAs with certain scope, but
> all TAs. This might be a model for desk top boxes or cell phones.
> In an enterprise context, a local admin may want a similar capability
> for himself, delegating some control to individual users, but
> ultimate control over TA management for a desktop or laptop.
> Steve
> Seems to me that we could have several issues/aspects pertaining to
> TAs:
> (1) Definition of a TA (ie. structure, syntax, semantics)
> (2) Protocol(s) to "manage" TAs (and definition/scope of what we mean
> by
> the term "manage")
> (3) Authorization model (ie. authorization to manage TAs)
> (4) Delegation model (i.e. authority-over-TA now delegates portions of
> authority or entire authority)
> (5) Others...
> The scope of the BOF/WG can easily become very wide, which is why I
> suggesting that the Enterprise use-case may be more manageable :)
> /thomas/