More specific examples (use-cases of TAM) -- RE: Issue with the requirements document: PKIX-centric terminology

["Thomas Hardjono" <thardjono@xxxxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx 
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of 
> Stephen Kent
> Sent: Friday, August 10, 2007 8:33 AM
> To: Paul Hoffman
> Cc: ietf-trust-anchor@xxxxxxxx
> Subject: RE: Issue with the requirements document: 
> PKIX-centric terminology
> 
...cut

> However, many (most?) of the messages I've seen on this list 
> discussing broader applicability have been very vague in this 
> respect. Thus I think we need more specific examples from 
> these other areas. Also, these examples should be such that 
> they can all be accommodated by standards that are specific 
> enough to be useful, not just broad enough so that we can say 
> that we encompass everything.
> 
> Steve

Since I was one of the persons at the BOF who mentioned wider
applicability of TAs and TAM (a) beyond browsers and TLS, and (b) beyond
the IETF, I'll provide some use-cases.  

(PS. Carl/Raksha/Sean/Stephen, its not perfect but please feel free to
use the text in the draft or charter).


TA and TAM Use-Cases
--------------------

UC#1: Code-signing
Code-signing is an important requirement for the security of computers
today. Essentially, in code-signing only digitally-signed code or
executables are allowed to be installed and executed on a computer
systems. This requirement introduces the need to have present on the
computer systems a set of Trust Anchors representing entities trusted by
the computer owner. The owner of the machine needs the ability to set
acceptable TAs according to the policies in place using a standardized
protocol.


UC#2: Field upgrade of sensitive firmware
There are over 50 million Trusted Platform Modules (TPM) hardware on PC
client machines today (with a projected number of 100M by 2010).  Once
in the field, a TPM's firmware will require updates in a secure manner.
RFC4108 (Using CMS to protect firmware) has already begun addressing
firmware packages. However, what is still required is a protocol to
update the original TA (from the TPM manufacturer) that reside inside
the TPM hardware. Additionally, each TPM hardware may incorporate a
number of TPM-specific (X.509) certificates issued by various entities
in the PC supply-chain. These certificates are in fact Trust Anchors,
and in turn require management using a standardized protocol.


UC#3: Secure boot
Within a Pre-OS environment, it is desirable from a trust/security
perspective to configure computers to load the various boot codes in a
pre-defined sequence (eg. configured by the IT admin).  One
interpretation of a secure boot is one in which the sequence of loaded
codes follow exactly what has been pre-defined (by the IT admin).
Additionally, it is desirable that the loaded codes can be verifiable as
coming from a trusted source (eg. BIOS vendor). Verification of Pre-OS
components requires Trust Anchors issued by the vendors to be readily
available in the Pre-OS environment. Among others, this allows updates
to the boot codes be introduced into the Pre-OS environment. However,
this introduces the need to manage and update TAs within the Pre-OS
environment.



UC#4: Multi stakeholder mobile phones
Today within the mobile telecommunications industry there are a number
of key stakeholders that participate in the mobile phone ecosystem and
management lifecycle.  These include the device manufacturer , the
carrier (MNO), various third-party content providers and lastly the
device owner.  Each of these stakeholders through contractual agreements
have access to different physical components of a mobile phone in the
field. A given stakeholder will allow access to be made (to the
components under its control) only by verifiable authenticated entities
(usually themselves or subordinates). One way to express this control is
through the presence of a X.509 certificate (namely a Trust Anchor)
issued by the respective stakeholder. Software and firmware updates
over-the-air and other senstive management commands will only be
accepted by the mobile phone when it can be verified against one or more
TAs found on the phone. Thus, TAs  and TA management represents a
crucial part of mobile phone security and the mobile phone ecosystem as
a whole.


UC#5: Secure virtualization
With the advent of client-side virtualization, it is desirable that a
given physical host machine be able to run more than one Guest Operating
Systems (GOS) simultaneously.  A typical architecture of such a host
machine includes a hypervisor layer which may include a virtualization
management component that supervises the loading and off-loading of the
Guest Operating Systems. An organization (eg. Enterprise) may wish to
allow only certain authorized GOSs to be loaded on its host machines.
This may be governed by business reasons or security reasons (or both).
With the absence of a full operating system, the hypervisor may use
Trust Anchors (TA) to identify and authenticate GOSs that are permitted
to load and execute.