|
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: Santosh Chokhani
[mailto:chokhani@xxxxxxxxxxxx] 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: Santosh Chokhani
[mailto:chokhani@xxxxxxxxxxxx] 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 |