Subject: TA requirements doc - do we need it?

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Dec 2008 12:25:25 +0000

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.
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.

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.

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.

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: Mon, 15 Dec 2008 11:46:51 -0500

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.

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Dec 2008 14:57:51 +0000

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?

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.

Stefan Santesson
Senior Program Manager

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 16 Dec 2008 12:12:15 -0500

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:

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

On Behalf Of Santosh Chokhani

Stefan,

  _____  

 

Stefan Santesson

Senior Program Manager