Subject: RE: Asessment of TAMP with vendor hat on

From: "Reddy, Raksha P." <[email-masked]>
Date: Mon, 17 Dec 2007 20:36:59 -0500

I am in favor of TAM as a PKIX WG item to develop a standard format for TAs
as well as a protocol to define an interoperable, in-bound mechanism to
remotely manage them.  Having such a protocol that enables either
session-oriented or store-and-forward mechanisms and is agnostic to
operating systems does not exist today.

The need for TAs exists in order to provide cert path validation as well as
to provide source authentication for delivery of signed objects such as
firmware and key material.  The need for TAM exists out of wanting a
non-proprietary in-bound means of managing trust anchors for various
applications, thus reducing the burden on TA Administrators and increasing
operational efficiency.  The need also exists to establish delegation of
authority and have a means to ensure that any given object is signed by the
appropriate constrained authority.  For example, a device may have multiple
applications that each require different types of firmware developed by
different sources.  The device can have constrained authorities so that each
firmware type can be validated from each respective source.  Furthermore,
having the flexibility to target TA configurations to a specific group of
devices is beneficial if changes need to be made to a particular TA that is
applicable to a specific set of devices.

Although TAMP and CCC are two drafts that were proposed to provide a
solution for TAM, I am not opposed to other solutions that also meet the
goals of the problem statement.  I do agree with Steve's comments that the
PKIX WG should use the last iteration of the problem statement as a starting
point in order to further define TAM requirements.  

Raksha Reddy
National Security Agency

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Monday, December 17, 2007 1:56 PM
To: Stefan Santesson
Cc: [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

Stefan,

A few of observations about you TAM comments, many of which may have been
stated by others, since I am late in responding:

	- you are right that the presentation we saw in Vancouver focused on
a solution, not a problem statement. PKIX will need to start with a problem
statement (or a requirements I-D) that the WG agrees upon.  There was
considerable discussion of the problem statement on the TAM mailing list. I
think we can start from the most recent iteration there, but this will need
to be developed in the context of PKIX, i.e., we are not rubber stamping
what was done before.

	- we need an interoperable solution, in typical IETF style, so
whatever Microsoft or other vendors have done may be useful as input, but it
probably is not a substitute for a IETF standard.

	- there were suggestions on the TAM list that offline management was
needed. So any solution that relies on live connectivity is not sufficient,
IF the WG agrees with this as a requirement.

	- the TAM list also indicated a desire to have a flexible management
capability, in which one TA, with ultimate responsibility for the managed
object, can delegate authority to other entities to manage TAs with
constrained scope. My quick read of what you described as the MS management
capability did not seem to accommodate this sort of delegation. Again, if
PKIX decides this is a real requirement, that motivates developed of a more
sophisticated management framework.

	- in certain contexts the receipt capability seems useful, as does
the ability to query a managed device to determine which TAs are installed,
etc. Again, we'll have to see whether these are features that the WG agrees
are needed.  If so, then they motivate a request/response protocol model.

	- the secure TA replacement function defined in TAMP seems to be
attractive, and hopefully not patent encumbered, and would be a nice feature
for PKIs to have, although I agree that it could be accommodated as a cert
extension without the rest of TAMP.

Steve

---

From: Carl Wallace <[email-masked]>
Date: Tue, 18 Dec 2007 17:21:12 -0500

Stefan,
 
We could revise the problem statement and try to address your comments
(probably not until January).  Should we resubmit as a PKIX draft?  In the
meantime, additional comments on the existing problem statement could be
posted to the list for inclusion in the next revision.
 
Carl

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, December 18, 2007 8:53 AM
To: Carl Wallace; [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

BM__MailEndComposeCarl,

I have read the problem statement and in many aspects it is a great start.
However it assumes one management model and it does not explain why this
management model is needed.

The problem statement further express many requirements for functionality
where I miss a "why" explanation. I think this is caused by the assumed
management model.

I would also like to see an analysis of the actual problems (maybe in the
form of scenarios) and what part of the overall problem space that can be
solved by an IETF standard.

The area is complex and involves applications and their functionality,
network resource infrastructures and present security architectures.

Also, what interoperability problems do we set out to solve. Even if we want
to, we can't solve them all as there always will be several reasonable ways
to solve TA management and all of them will not work together.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carl Wallace
Sent: den 17 december 2007 17:23
To: [email-masked]
Subject: RE: Asessment of TAMP with vendor hat on

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, December 13, 2007 3:02 PM
To: [email-masked]
Subject: Asessment of TAMP with vendor hat on

When it was requested that the TAM work would present at PKIX, it was
advertised as a presentation of a problem statement.

However, what I saw was more a presentation of a protocol with a clear
direction, but not much of the rationales behind this solution. 

[CRW] The problem statement is still very much available and could be used
as the basis for discussion here. 

An important factor of whether to adopt this work is not only if the area as
such is of importance, it is even more important to make an assessment of
how this fits into our current IT infrastructures. E.g. if there are any
Vendors interested in implementing this and for what problems they see this
as a preferred solution.

I'm here taking my pkix-chair hat of and my vendor hat on to provide an
assessment of how this fits into Microsoft product infrastructure and what
problems I see. However, this is still a personal contribution, expressing
my personal view.

Background.

Microsoft already has a solution for distribution and management of trust
anchors.  

[CRW] Part of the aim is vendor interop.  An aim, as described in the
problem statement, is to vet new TAs in terms of a key that was installed
out of band in a trusted manner, while supporting in-band replacement of the
initial key.  

 As soon as a host or device enters as a member of a network it becomes
member of a security infrastructure based on some primary credentials. Vital
data and security relationships are managed through common repositories,
e.g. the Active Directory. The domain joined environment adds refined
management capability of trust anchors /root keys. 

[CRW] Disconnected devices require TA management as well.

In the global environment, trust anchors/roots are managed through Microsoft
update. Both infrastructures share common architectural principles. In no
case is this a query/response protocol. Clients are pulling status
information from a trusted source protected by a basic pre-configured and
later upgraded security infrastructure. Based on this information the
client/host/device pulls down and authenticates necessary TAs to appropriate
TA stores on the local host, such as stores on machine, user and application
levels. 

[CRW] An aim is to make the trusted source be common across applications.
Placing the trusted source in the control of PKI operators instead of domain
administrators would be a good thing to enable as well.   

Need

The need I see in this area is primary focused on a standardized data
structure for TAs that is not provided in the form of a self signed root. A
second void area could be a standard structure for a main repository to
store a list available TAs and their applicability. For the first issue we
have no solution today, for the second we do have a proprietary format for a
signed root list.

Need for a query and response protocol.

I can't see any need for this type of protocol. The query and response
protocol provide quite an amount of unnecessary overhead and redundancy in
term of infrastructure, protocols and security infrastructure and is a lot
less flexible than incorporating this into an existing data management and
security infrastructure. A query and response protocol to a central function
with signed response also comes with scaling issues. There are significant
advantages to have a dumb repository containing pre-signed objects over an
active protocol with signed requests and responses. The sum of this is that
the query and response protocol aspects of the TAM proposal brings
significant complexity that does not solve any current problems. 

[CRW] There are aspects of existing solutions that are problematicthat are
addressed by TAMP, i.e., in-band updates and TA usage.   The
request/response nature of TAMP is certainly not central to its
functionality.  A signed TrustAnchorUpdate message verified using a
previously installed trust anchor can be used without the production of a
receipt.  

Scope

Some may claim that the proposed protocol is needed for other architectures
than the private hosts on the internet or the enterprise environment, but if
that is the case, the scope of this protocol should be clearly defined. If
this is developed as the IETF protocol for TA management for all
environments, then this is a big problem as it clearly does not fit well
with many current infrastructures. 

[CRW] There is plenty of common ground.  You've noted the potential utility
of signed TA information and non-self-signed structures for TAs. 

Call for opinions from supporters and implementers

If you support this protocol as the direction for this work, I would like to
know what problem it solves for you and if you are prepared to implement
this.

Conclusion

I support TAM as work item in PKIX as a general problem area. I reject the
current protocol proposal as the basis for doing this work in PKIX.

If TAM is accepted, I propose that the work focus on a common data format
for storing TAs both in the form of self signed root certificates and as
key+paramenters. If more work needs to be done, it should first be preceded
with a requirements document (or problem statement) where we all can agree
of the scope of the protocol to be defined.

[CRW] There is a problem statement from the TAM BOF.   

Stefan Santesson

Senior Program Manager

Windows Security, Standards