|
Stefan, We agree that initial trust anchor must be
provided using secure out of band means such as physically secure means. It is probably ok that the current
certificate format with applicable current or new extension can serve as the
trust anchor information. But, as my post asks (for the nth time),
do we need to define data structures and protocols to replace the trust anchor
routinely and/or in the case of trust anchor compromise. If the community thinks that all this
should be done out-of-band, then we do not need TAMP. If the community thinks that there is some
value, cost saving and efficiency and operational security improvement in doing
this in-band, then a protocol should be vetted so that there is
interoperability and the security of the protocol is vetted through the
collective wisdom of IETF/PKIX. From:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson I can’t see that the TAM proposal
solves the problem of providing the first set of keys. Any security protocol
using cryptography need some keys to be in place before the protocol can work. So essentially the TAM protocol is a key
management protocol for obtaining public keys that can be configured as trust
anchors. An interesting distinction is whether it
is the host/device that obtains the TA or if it is provided (pushed) on to the
host/device. If you want to actively push something to the host, then that may
require some query/response protocol that is initiated from a central source.
However. If the TA is obtained by the host, then no new protocol is needed over
existing infrastructure and protocols. There are several ways the host can come
to a conclusion that it needs to do a TA update. 1) An unresolved cert chain is being
validated, chaining to an unknown TA 2) A scheduled process on the host
periodically downloads TA policy and TAs from a central directory. The only protocols used to obtain data
are standard protocols for directory usage or standard web protocols in combination
with security and authentication protocols such as IPsec and Kerberos. Standard
signature schemes can be used to sign data for authenticity and integrity
protection. The only amendment of standards this
environment would benefit from are signed data structures for TA
information. Microsoft’s way to push
information to clients and hosts is through group policy updates. This is
however not a protocol. This is a function that can be configured in the host
OS which pulls policy information from a central directory. The only thing you
have to do to manage host updates is to update policy data in the central
directory. Group policy is activated when a host is domain joined. You can add all sorts of protection to
this process, but this can be done locally by available protocols and
doesn’t require any TA specific protocol to be secure. My problem is that I can’t see how
TAMP fits into this information and key management model and why TAMP is needed
instead of, or in addition to this. Stefan
Santesson Senior Program Manager Windows
Security, Standards From: Stefan, TAMP is supposed to solve the problem of
how to provide the first set of key and how to refresh those keys in-band in
general as well as when the original key is compromised. Does Microsoft protocol provide for
securely refreshing the keys in-band? If yes, the data structures and
associated protocols are a good candidate as solution to the trust anchor
problem. Also, does the Microsoft protocol provide
for securely refreshing the keys in-band even if the original trust anchor is
compromised? If yes, that aspect can become part of the solution. From: Stefan Santesson
[mailto:stefans@xxxxxxxxxxxxx] In the public space it follows the same
security mechanisms as software updates and code signing chaining to a
Microsoft root. A first set of root keys are provided with the OS. In the enterprise environment it uses
the security infrastructure deployed by the organization. This currently offer
adequate security for the integrity protection of TAs. Stefan
Santesson Senior Program Manager Windows
Security, Standards From: Stefan, You have not explained how Microsoft
securely, automatically, provides and refreshes the trust anchors. How
are Microsoft updates secured on the client? Let us say that they are secured
using trust anchors. In that case, how are those trust anchors provided
to clients securely initially, updated securely, and how do you update them
securely in-band in case of compromise. Separately, I thought TAMP (not the
protocol), but the problem statement was:
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Stefan Santesson 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. 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. 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. 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. 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. 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 Windows
Security, Standards |