Subject: RE: Asessment of TAMP with vendor hat on

From: Carl Wallace <[email-masked]>
Date: Mon, 17 Dec 2007 11:23:11 -0500

_____  

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 problematic that 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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 Dec 2007 13:52:56 +0000

Carl,

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

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.

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.

Stefan Santesson
Senior Program Manager