Subject: FW: TA requirements doc - do we need it?

From: Stefan Santesson <[email-masked]>
Date: Thu, 18 Dec 2008 16:47:13 +0000

I'm resending this as my original mail got filtered due to exceeding pkix message size restrictions.
I have now replaced the embedded picture with a URL to the screenshot.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Stefan Santesson
Sent: den 17 december 2008 11:43
To: 'Kemp, David P.'; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Dave,

You raise valid points and I partly try to avoid them because the answer is somewhat long and complex. Long and complex answers are seldom successful in standards discussions :)

Let me try to show my point through a screenshot that helped explain this issue to at least one of the original contributors to the proposed protocol. This is a screenshot of the Microsoft certificate management snap-in:

http://www.fiddler.nu/pkix/certmgr_mmc.jpg

What you see here is the certificate trust policies in my laptop. It is not one root store and it is not just about trust anchors. In my laptop I have a certificate trust management snap-in for:

*         Each host (local machine)

*         Each user account

*         Each service running on any host

In the Certificate snap-in window to the right, you see a fraction of the list of services with individual certificate trust settings for one host/machine.

And it is not about just TA:s. It is about:

*         My personal certificates

*         Trusted roots

*         Intermediary CAs

*         Directly trusted or untrusted certificates

*         Etc, etc (See above)

The structure of this information is not globally agreed and generic. It is just how Microsoft have structured this in the Microsoft OS.

One could call this a set of certificate trust policies that are dynamically managed and as you get closer to reality, the border between roles, peoples and machines are getting more and more virtual and dynamic and it becomes harder and harder to reduce this into one generic, intrusive and centrally managed TA management protocol.

Let me take a few examples from the requirements:

*         The assumed roles and authorization model

*         The assumption that there exist clearly identifiable TA stores.

The TA requirements are assuming a TA manager responsible for a TA store. The TA manager have authority over this TA store and have the power update it or replace it. This also assumes that each TA store is individually identifiable in the protocol itself. In my environment above, I first of all don't have any isolated  identifiable TA stores. Secondly I don't have a clearly defined TA manager that has the right to view and update this information on a local machine.

The applications or services that eventually are being affected by these trust policy updates will not have a clue about what information that was passed in any TA management protocol, or any IETF defined TA format file several layers and APIs below their existence. So any discussion about how applications should take into account specific path processing preferences provided by passing TA format information around, such as applying specific constraints rules, is just pretty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation.

In the environment I'm working with, I have no use for a transaction based TA management protocol based on the simplified relationship between a TA manager and a TA store.
If I had one, I would not know how to use it.
The only thing I would know how to use, is the TA format specification. That one I can use to pass TAs around in my existing trust policy framework.

I hope this was a useful clarification and my apology for passing graphics in a PKIX posting. I hope you can view it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: den 16 december 2008 18:12
To: [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

Refining the requirements as a series of I-Ds until "the scope of the requirements is in harmony with problem space", then publishing as an RFC once the requirements have converged, certainly sounds like the best approach.

But you have not explained how "The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure."  The requirements in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes?

*         Are you claiming that adversaries have no access to a "common network and data sharing infrastructure" and therefore no protection is needed in the networked case?  That is patently false for all networks of interest to the IETF.

*         Or that the protection mechanisms appropriate for managing networked platforms (Connection-oriented?  MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?)

Without understanding the nature of your objections it's hard to tell whether the scope of the requirements is already in harmony with the entire problem space or not.   Your 4-quadrant slide from Minneapolis is not self-explanatory - I thought we had already disposed of the push-pull issue by determining that there is no security-relevant difference between posting to a repository from which a client may pull and pushing directly to the client.  Therefore the TAM requirements already cover the left half of the space.  If there is a single existing TAM requirement that precludes pull, or a single missing TAM requirement needed for pull, please provide an example.

And I need help understanding the difference you see between TA and TA Policy - if policy is "Host/App A will trust provider X for security critical firmware category Z", and the TA store of Host/App A has provider X's TA in the slot for firmware category Z, what is the difference, other than level of abstraction, between "determine current TAs in store" and "demonstrate compliance with policy"?  Again, an example of a missing TAM requirement needed to satisfy the right half of your slide would go a long way toward understanding the scope issue.

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Hi Santosh,

As I expect, I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue:

The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.

I would also prefer to see the requirements document as a living document as you suggest. I think that purpose is best served if the requirements document remains in draft form.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

See my responses in-line below.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form.
I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC.

I have two major reasons:

First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment.
[Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution.

The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure.
[Santosh] The requirements are generally the same in terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or open.

Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression.
[Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc.  I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities.

The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol.
[Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.

My proposal going forward is to do the following:

-          In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for.

-          Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 27 Dec 2008 00:46:34 -0500

Stefan,

I for one do not see how your e-mail relates to the TA requirements
document or Dave's post.  See responses in-line.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, December 18, 2008 11:47 AM
To: [email-masked]; Kemp, David P.
Subject: FW: TA requirements doc - do we need it?

I'm resending this as my original mail got filtered due to exceeding
pkix message size restrictions.

 

Stefan Santesson

Senior Program Manager

From: Stefan Santesson 

Dave,

You raise valid points and I partly try to avoid them because the answer
is somewhat long and complex. Long and complex answers are seldom
successful in standards discussions :-)

Let me try to show my point through a screenshot that helped explain
this issue to at least one of the original contributors to the proposed
protocol. This is a screenshot of the Microsoft certificate management
snap-in:

What you see here is the certificate trust policies in my laptop. It is
not one root store and it is not just about trust anchors. In my laptop
I have a certificate trust management snap-in for:

*         Each user account

[Santosh] This is consistent with TA requirements since TA requirements
deal with each TA store.  In your case, the TA and TAMP will be applied
to three stores.

In the Certificate snap-in window to the right, you see a fraction of
the list of services with individual certificate trust settings for one
host/machine.

[Santosh] This is consistent with TA material in that constraints can be
associated individually with the TAs.

[Santosh] This is not relevant to the topic since it does not relate to
TA management. 

*         Trusted roots

*         Intermediary CAs 

*         Etc, etc (See above)

The structure of this information is not globally agreed and generic. It
is just how Microsoft have structured this in the Microsoft OS.

[Santosh] This is precisely why we need TAF and TAMP.  That is what
requirements highlight.

One could call this a set of certificate trust policies that are
dynamically managed and as you get closer to reality, 

[Santosh] I would say a more accurate and complete characterization of
these is the constraints on the trust anchors.

the border between roles, peoples and machines are getting more and more
virtual and dynamic and it becomes harder and harder to reduce this into
one generic, intrusive and centrally managed TA management protocol.

[Santosh] One would think that as things become more virtual and
dynamic, more you need the associated data with the TA and TAMP that can
enforce the constraints on the TA and on the associated data.

*         The assumption that there exist clearly identifiable TA
stores.

The TA requirements are assuming a TA manager responsible for a TA
store.

[Santosh] While operationally this may be one manager managing the TA
store, the requirements and TAMP should be oriented towards many to
many.  A TA manager can manage one or more TA in the TA store.  A TA in
a TA store can be managed by more that one manager.

 The TA manager have authority over this TA store and have the power
update it or replace it. This also assumes that each TA store is
individually identifiable in the protocol itself. In my environment
above, I first of all don't have any isolated  identifiable TA stores.

[Santosh] The TA need not be in a specific store, but it is always
identifiable by some combination of name, SPKI, and SKID. 

Secondly I don't have a clearly defined TA manager that has the right to
view and update this information on a local machine.

[Santosh] The TA requirements and TAMP should clarify this with the
constraints on the TAs. 

The applications or services that eventually are being affected by these
trust policy updates will not have a clue about what information that
was passed in any TA management protocol, or any IETF defined TA format
file several layers and APIs below their existence. 

[Santosh] Agree and the applications do not do this.  This is part of TA
management and not part of applications using the TA.

So any discussion about how applications should take into account
specific path processing preferences provided by passing TA format
information around, such as applying specific constraints rules, is just
pretty theory without substance unless it is made part of standard RFC
5280 path processing and implemented in the APIs for path validation.

[Santosh] The TA requirements in the area of path processing are
consistent with 5280.  5280 specifically cites additional checks based
on the  information associated with TA.  See section 6.2 of 5280.

In the environment I'm working with, I have no use for a transaction
based TA management protocol based on the simplified relationship
between a TA manager and a TA store. 

[Santosh] That does not mean others do not need it.  It also does not
mean that the environment you cited above would not benefit from in-band
re-key of the TA.

The only thing I would know how to use, is the TA format specification.
That one I can use to pass TAs around in my existing trust policy
framework.

[Santosh] You as a person will need not be aware of it, just like many
of nuances of PKI.  The processing software will securely process the
transactions and update the TAs.

I hope this was a useful clarification and my apology for passing
graphics in a PKIX posting. I hope you can view it.

[Santosh] The primary purpose of TA work is to permit in band, secure
installation and rekey of TAs.  Unless you propose an alternative
mechanism to achieve this securely, the discourse you are having is not
providing any critique of the TA work.

Stefan Santesson

Senior Program Manager

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp, David P.
Sent: den 16 december 2008 18:12
To: [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

Refining the requirements as a series of I-Ds until "the scope of the
requirements is in harmony with problem space", then publishing as an
RFC once the requirements have converged, certainly sounds like the best
approach.

But you have not explained how "The requirements are radically different
in a device oriented environment with disconnected units compared with a
centrally managed IT environment with a common network and data sharing
infrastructure."  The requirements in either case are for managed
devices/applications/services to receive configuration items from
managers without those items being compromised in transit, yes?

*         Are you claiming that adversaries have no access to a "common
network and data sharing infrastructure" and therefore no protection is
needed in the networked case?  That is patently false for all networks
of interest to the IETF.

*         Or that the protection mechanisms appropriate for managing
networked platforms (Connection-oriented?  MACs?) are different than
those needed for managing disconnected platforms
(Datagram/message-oriented? Signatures?)

Without understanding the nature of your objections it's hard to tell
whether the scope of the requirements is already in harmony with the
entire problem space or not.   Your 4-quadrant slide from Minneapolis is
not self-explanatory - I thought we had already disposed of the
push-pull issue by determining that there is no security-relevant
difference between posting to a repository from which a client may pull
and pushing directly to the client.  Therefore the TAM requirements
already cover the left half of the space.  If there is a single existing
TAM requirement that precludes pull, or a single missing TAM requirement
needed for pull, please provide an example.

And I need help understanding the difference you see between TA and TA
Policy - if policy is "Host/App A will trust provider X for security
critical firmware category Z", and the TA store of Host/App A has
provider X's TA in the slot for firmware category Z, what is the
difference, other than level of abstraction, between "determine current
TAs in store" and "demonstrate compliance with policy"?  Again, an
example of a missing TAM requirement needed to satisfy the right half of
your slide would go a long way toward understanding the scope issue.

Dave

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Hi Santosh,

As I expect, I sense that we have a slightly different view of the
generality of the proposed solution, but we seem to agree on the main
issue:

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols.  If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

I would also prefer to see the requirements document as a living
document as you suggest. I think that purpose is best served if the
requirements document remains in draft form.

Stefan Santesson

Senior Program Manager

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; [email-masked]
Subject: RE: TA requirements doc - do we need it?

Stefan,

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: [email-masked]
Subject: TA requirements doc - do we need it?

After all discussions in Minneapolis and going back and looking at the
current situation, I feel less and less convinced that we need to
approve any TA requirements document as an RFC. At least not in its
current form.

I'm fine with having it around as a draft for reference, but I fear it
may be a lot more harmful than beneficiary to us as an RFC.

First, as I have argued and tried to explain with my slide in
Minneapolis, there is no general overall approach to TA management in a
complex IT environment.

[Santosh] In a complex distributed environment that needs to scale
across Enterprises, applying requisite security services to the payload
provides a scalable, interoperable, extensible, and secure solution.

The requirements are radically different in a device oriented
environment with disconnected units compared with a centrally managed IT
environment with a common network and data sharing infrastructure.

[Santosh] The requirements are generally the same in terms of security
services.  Some Enterprise IT management implementations may have
implemented Enterprise specific solutions taking advantages of existing
infrastructure and security services provided by the Enterprise network.
But, that solution may not be as scalable or open.

Secondly, the requirements didn't come first. These requirements were
written with an existing protocol in mind. The lasting impression is
therefore that the requirements document was written to match and
support the original protocol, making it a tool to grandfather the
original protocol into IETF. I'm not claiming that this is the case, but
it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake,
requirements are based on past experience, security vulnerabilities we
have encountered, past systems, etc.  I do not know of many successful
efforts where requirements were developed in vacuum. In short, it is
fair to say that the requirements and protocol benefited from each other
and from past experiences with protocols and vulnerabilities.

The question one have to ask is if these requirements, in the form of an
RFC, would serve us as a community if we encounter a problem with the
proposed protocol. I doubt that it will as it at most will strengthen
the argument for those having an interest to adopt the original
protocol.

[Santosh] Having a requirements document that is a living document,
permits us to evaluate various solutions and protocols.  If we do
encounter a security problem, it should be useful to analyze where the
engineering process failed, e.g., did we not articulate some
requirement, did we not have sufficient detail for a requirement, did
our analysis of protocol meeting a requirement was flawed, etc.

-          In any case adjust the scope of the requirements document to
reflect the problem space the problem space it is designed for.

-          Leave it as a draft, or at least not publish it as an RFC
before the scope is in harmony with the requirements.

Stefan Santesson

Senior Program Manager