Subject: Re: [pkix] EST trust anchor definition

From: "Dan Harkins" <[email-masked]>
Date: Fri, 11 Jan 2013 10:00:44 -0800 (PST)

Hi Mike,

  Sorry for the delay in responding.

On Tue, December 11, 2012 5:57 am, M Jenkins wrote:
> Sorry, hadn't noticed that I didn't send this to the list.
>
> Hi Dan. I'm concerned that the client can trust the contents of the cert
> (know that it has validated the correct cert) before it starts using the
> contents to check the server name. Likewise for the server, if the
> client has been initialized with an "enrollment certificate" (say by the
> vendor; the trust anchor would be provided by the vendor separately to
> the EST server operator).

  That is a valid concern but I'm not sure why the text and tables do not
assuage it. In trying to better understand your concern I noticed in your
mail below you say:

     "The draft does say that the client needs to be configured with the
     correct trust anchor (through out-of-band means), but after that
     all references to TAs are "TA Database". If I can't guarantee that
     I'm using the TA that I configured, there was no point in configuring
     one.'

The point in configuring it is to enable its use. You can always guarantee
that you're using the one you configured if that is the only one available.
That is, you are not required to populate a 3rd party TA database in your
client if you have no need for it and no intention to use it. If you have
more than one TA database then you'll have to, as you say, 'dig through lots
of cert guts' to determine what TA is used. The EST client (server) uses the
TA databases. If it doesn't want to use one then it shouldn't use it and if
it does use one (possibly by 'digging through lots of cert guts') then it
should know how it came to treat the EST server's (client's) certificate as
trustworthy.

  If I am misunderstanding your concern or do not understand the scenario
that you're envisioning, please restate it.

  regards,

  Dan.

> On 12/06/2012 01:01 PM, Dan Harkins wrote:
>>    Hello,
>>
>>    Perhaps I'm missing something but the "selected TA database" is
>> allowing
>> the client to verify the trustworthiness of the EST server's
>> certificate. The
>> client is still supposed to decide whether this is the _correct_ EST
>> server by
>> checking the contents of the certificate against whatever policy might
>> be configured as well as performing the TLS handshake and ensuring
>> that the EST server holds the private analog to the authenticated public
>> key it now holds.
>>
>>    To stretch your analogy, the "selected TA database" is allowing you
>> to
>> determine whether this is a bonafide Schlage deadbolt lock that you're
>> looking at. Whether it's _your_ bonafide Schlage deadbolt lock is the
>> next step you have to do by putting your key into the lock and seeing
>> whether it opens the door. If your neighbor's rabid dog bites you then
>> it's a sign that 2 keys open the same door which is a failure of a
>> different
>> kind.
>>
>>    Dan.
>>
>> On Thu, December 6, 2012 8:13 am, Michael Jenkins wrote:
>>> I suppose that helps - but it's more wordy and less clear, and
>>> therefore
>>> more prone to error. It's not that the system supporting the EST client
>>> can't have a TA database - I'm assuming it will. It's that the database
>>> is
>>> irrelevant to the protocol. I don't unlock the lock on my front door
>>> with
>>> a
>>> keyring, I do it with a key. Whether I only have one key, or whether I
>>> have
>>> 100, and whether I keep my 100 on a ring or in a box, is irrelevant.
>>>
>>> Crucially, I have to make sure the wrong thing doesn't happen. Say that
>>> I
>>> have a key to my neighbor's house. I want to enter my house. If my
>>> neighbor's house and mine look alike, and I walk up to his house by
>>> mistake, and I "use my keyring" to unlock the lock on the door - it
>>> works!
>>> Which is unfortunate for me, because his rabid dog just bit my leg.
>>>
>>> The problem I'm having with "TA Database" is that such databases are
>>> generally designed to make things work, not to make things work only in
>>> certain circumstances, as defined by the operator or local admin. It's
>>> no
>>> accident that most consumer systems come with a laundry-list of trust
>>> anchors, and there generally isn't any notification to the operator
>>> that
>>> any particular one was used during any particular transaction.
>>>
>>> Saying "use the TA Database" requires me to think up all of the ways
>>> that
>>> applying the entire database to my protocol might fail, and say how to
>>> prevent them. Saying "use only the XYZ trust anchor" is much more clear
>>> and
>>> precise. How to ensure that that particular trust anchor gets used is
>>> up
>>> to
>>> the system designer - which is a good thing, because I don't think it's
>>> desired that EST be limited to any one particular type of client
>>> system.
>>>
>>>
>>> On Wed, Dec 5, 2012 at 5:52 PM, Max Pritikin (pritikin)
>>> <[email-masked]>wrote:
>>>
>>>> (I corrected Peter Yee's email address)
>>>>
>>>> On Dec 5, 2012, at 3:50 PM, Max Pritikin<[email-masked]>  wrote:
>>>>
>>>>> On Dec 4, 2012, at 9:55 PM, Michael Jenkins<[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> I think that the tables, broken out according to TAs and Certs, are
>>>>>> a
>>>> big improvement. However, the TA table has really taken a hard turn
>>>> /away/
>>>> from the ability to specify a single TA as the one to use for EST.
>>>>> What prevents the client from having a "Third-Party TA Database" that
>>>> contains only TA's (or a single TA) to be used for EST?
>>>>>> Without digging through a lot of cert guts over and over, I'll never
>>>> know if any particular validation is terminating in the selected TA,
>>>> be
>>>> it
>>>> a provided vendor-supplied initialization root, or a "public" CA, or a
>>>> locally supplied root. I'm not prejudiced toward one or the other of
>>>> those
>>>> options, as long as it's the one I've initially configured - that is,
>>>> as
>>>> long as I have a way of expressing which TA must terminate my EST
>>>> transactions.
>>>>>> Ideally that would happen through some kind of labeling, but I don't
>>>> think that there's anything that does that now, natively, in a system
>>>> trust
>>>> anchor store. Other solutions would be to remove all trust anchors
>>>> /except/
>>>> the selected one (drastic, but might work for some specific-use
>>>> devices),
>>>> or to configure the EST client app with a keyID for the selected trust
>>>> anchor (and then check that it's the one used).
>>>>>> The draft does say that the client needs to be configured with the
>>>> correct trust anchor (through out-of-band means), but after that all
>>>> references to TAs are "TA Database". If I can't guarantee that I'm
>>>> using
>>>> the TA that I configured, there was no point in configuring one.
>>>>> We can make this the "selected TA Database" and we can indicate that:
>>>>>
>>>>> "The Client MUST support a configurable option to enable checking all
>>>> or
>>>>> a subset of either the EST client Third-Party TA database or the EST
>>>>> client TA database."
>>>>>
>>>>> Would that address your concerns?
>>>>>
>>>>> - max
>>>>>
>>>>>
>>>>>> Hope that makes sense. If I'm interpreting the table incorrectly,
>>>>>> let
>>>> me know where I went wrong.
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 3:56 PM, Max Pritikin (pritikin)<
>>>> [email-masked]>  wrote:
>>>>>> Thanks for all the feedback. We've already updated the table similar
>>>> to
>>>> what you recommend below so its good to see we're on the same page.
>>>>>> Below is the current table in our working copy. I'll read through
>>>> your
>>>> suggestions carefully to see if additional clarity can be gained.
>>>>>> Similarly I'll go through you other email of specific feedback and
>>>> merge them to the revisions we've made since the ietf85 meeting.
>>>>>> - max
>>>>>>
>>>>>> Current table in our working revision (best viewed in monospaced
>>>> font):
>>>>>>    Certificates and their corresponding uses:
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>    | Certificate  | Issuer             | Use and section references
>>>> |
>>>>>>    +==============+====================+===============================+
>>>>>>    | EST server   | The CA served by   | Presented by the EST server
>>>> |
>>>>>>    | certificate  | the EST server     | during the TLS handshake
>>>> |
>>>>>>    |              |                    |
>>>> |
>>>>>>    |              |                    | Section 3.3.1.1
>>>> |
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>    | EST server   | A CA               | Presented by the EST server
>>>> |
>>>>>>    | certificate  | authenticatable by | during the TLS handshake
>>>> |
>>>>>>    |              | a third-party TA   |
>>>> |
>>>>>>    |              |                    | Section 3.3.1.1, and
>>>> |
>>>>>>    |              |                    | Security Considerations
>>>> |
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>    | EST client   | A CA               | Presented by the EST client
>>>> |
>>>>>>    | certificate  | authenticatable by | to the EST server by
>>>>>> clients
>>>> |
>>>>>>    |              | a third-party TA   | that have not yet enrolled
>>>> |
>>>>>>    |              | e.g., a device     |
>>>> |
>>>>>>    |              | manufacturer       | Section 3.3.1.2
>>>> |
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>    | EST client   | The CA served by   | Presented by the EST client
>>>> |
>>>>>>    | certificate  | the EST server     | to PKI End Entities.
>>>> |
>>>>>>    |              |                    | Including to the EST server
>>>> |
>>>>>>    |              |                    | during future EST
>>>>>> operations
>>>> |
>>>>>>    |              |                    |
>>>> |
>>>>>>    |              |                    | Section 3.3.1.2
>>>> |
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>    | EST client   | The CA served by   | Presented by the EST client
>>>> |
>>>>>>    | certificate  | the EST server     | to PKI End Entities.
>>>> |
>>>>>>    |              |                    | Clients can obtain certs
>>>> |
>>>>>>    |              |                    | that can not be used for
>>>>>> EST
>>>> |
>>>>>>    |              |                    | client authentication
>>>> |
>>>>>>    |              |                    |
>>>> |
>>>>>>    |              |                    | Section 4.4.1
>>>> |
>>>>>>    +--------------+--------------------+-------------------------------+
>>>>>>
>>>>>>
>>>>>>                                  Figure 3
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pritikin, et al.          Expires May 21, 2013                 [Page
>>>> 12]
>>>>>> Internet-Draft                     EST                     November
>>>> 2012
>>>>>>
>>>>>>    Trust Anchor databases and their corresponding uses:
>>>>>>    +--------------+----------------------------------------------------+
>>>>>>    | TA database  | Use and section references
>>>> |
>>>>>>    +==============+====================================================+
>>>>>>    | EST server   | EST servers use this TA database to authenticate
>>>> |
>>>>>>    | TA database  | certificates issued by the CA, including EST
>>>> |
>>>>>>    |              | client certificates during enroll/re-enroll
>>>> |
>>>>>>    |              | operations
>>>> |
>>>>>>    |              |
>>>> |
>>>>>>    |              | Section 3.3.1.2
>>>> |
>>>>>>    +--------------+----------------------------------------------------+
>>>>>>    | EST server   | EST servers use this TA database to authenticate
>>>> |
>>>>>>    | Third-Party  | certificates issued by third-party TAs.
>>>> |
>>>>>>    | TA database  | e.g., EST client certificates issued by a device
>>>> |
>>>>>>    |              | manufacturer
>>>> |
>>>>>>    |              |
>>>> |
>>>>>>    |              | Section 3.3.1.2
>>>> |
>>>>>>    +--------------+----------------------------------------------------+
>>>>>>    | EST client   | EST clients use this TA database to authenticate
>>>> |
>>>>>>    | EST CA       | certificates issued by the EST CA, including EST
>>>> |
>>>>>>    | TA database  | server certificates.
>>>> |
>>>>>>    |              |
>>>> |
>>>>>>    |              | Section 3.3.1.1 and
>>>> |
>>>>>>    |              | Section 4.3
>>>> |
>>>>>>    +--------------+----------------------------------------------------+
>>>>>>    | EST client   | EST clients use this trust anchor database to
>>>> |
>>>>>>    | Third-Party  | authenticate an EST server that uses an
>>>>>> externally
>>>> |
>>>>>>    | TA database  | issued certificate.
>>>> |
>>>>>>    |              |
>>>> |
>>>>>>    |              |
>>>> |
>>>>>>    |              | Section 3.3.1.1 and
>>>> |
>>>>>>    |              | Security Considerations
>>>> |
>>>>>>    +--------------+----------------------------------------------------+
>>>>>>
>>>>>>
>>>>>>                                  Figure 4
>>>>>>
>>>>>> On Nov 19, 2012, at 1:24 PM, M Jenkins<[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> I think that the current EST draft is weak when it comes to talking
>>>> about trust anchors. Many of the right ideas are there, but a bit
>>>> scattered
>>>> about. Figure (Table) 3 has a lot of this information, but there's
>>>> some
>>>> fuzz in it, and it's not very explicit about how crucial TA
>>>> initialization
>>>> is to the security of the protocol.
>>>>>>> A specific concern is a perception that *any* trust anchor that
>>>> happens to be in a trust anchor store might be used to terminate a
>>>> certificate validation chain. The use of the phrase "third party Trust
>>>> Anchor Database" is worrisome. Who cares if the TA comes from any
>>>> (acceptable) third party - if you can't ensure that your validation
>>>> chain
>>>> is going to terminate in that TA in the first place? The present state
>>>> of
>>>> TA store management doesn't inherently provide this selectability. I
>>>> think
>>>> that explicit text is needed here.
>>>>>>> I would suggest that table in Figure 3 be replaced with something
>>>> like
>>>> the following:
>>>>>>> Trust Anchors
>>>>>>> +--------------------------------------------------------------+
>>>>>>> | NOTE: EST Servers and Clients must be initialized to know    |
>>>>>>> |       which specific public keys in their trust anchor       |
>>>>>>> |       stores correspond to which function from this table.   |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | CA Root       | * End of validation path of all CA certs     |
>>>>>>> |  public key   | * End of validation path of Device Cert      |
>>>>>>> |               | * May be identical to EST Server TA          |
>>>>>>> |               | * May be identical to EST Client TA
>>>>>>> |               | * Obtainable by /CACerts command             |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | EST Server TA | * End of validation path of EST Server cert  |
>>>>>>> |               | * Must be securely installed to EST Client   |
>>>>>>> |               | * Must be obtained securely, out-of-band     |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | EST Client TA | * End of valid. path of EST Client init cert |
>>>>>>> |               | * Must be securely installed to EST Server   |
>>>>>>> |               | * Must be obtained securely, out-of-band     |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>>
>>>>>>> Certificates
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | CA Signing    | * Crsp. private key signs Device Cert        |
>>>>>>> |  Certificate  | * Intermediate CA certs may exist in path    |
>>>>>>> |               | * Obtainable by /CACerts command             |
>>>>>>> |               | * Must be validated against CA Root
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | EST Server    | * Used by EST Client during TLS handshake    |
>>>>>>> |  Certificate  | * Must be validated against EST Server TA    |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | EST Client    | * Used by EST Server during initial enroll   |
>>>>>>> |  Init Cert    |    (if certificate TLS auth used)            |
>>>>>>> |               | * Must be validated against EST Client TA
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | Device Cert   | * Any certificate returned as a result of    |
>>>>>>> |               |    /simpleEnroll, /simpleReEnroll, /fullCMC, |
>>>>>>> |               |    or /serverKeyGen                          |
>>>>>>> |               | * May be used for subsequent EST sessions    |
>>>>>>> +---------------+----------------------------------------------+
>>>>>>> | NOTE: The CA, EST Server, EST Client, and other servers may  |
>>>>>>> |       have other certificates for other purposes, including  |
>>>>>>> |       inter-server communication during EST sessions.        |
>>>>>>> +--------------------------------------------------------------+
>>>>>>>
>>>>>>> Mike
>>>>>>
>>>>
>>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Michael Jenkins <[email-masked]>
Date: Fri, 18 Jan 2013 14:26:49 -0500

Dan,

If the device is an enterprise-owned, special purpose device (like a
router), what you say probably applies. If the device is a personally-owned
and managed BYOD type device, then 1) the TA database won't ever just have
one TA in it - even if you make it only have one, it'll have a bunch again
after the next vendor system update; 2) as unlikely as it is that the
device operator will bother to manage the TAs, even a savvy operator isn't
going to remove all of the TAs that don't relate to EST (that would make
the device useless for purchasing tunes); and 3) it's possible that the
device won't even allow the operator to manage the TAs in the first place.

Say the device is a wireless device, and comes to the edge of a wireless
network to which the operator wants to connect. It receives a cert from an
EST server - who's it signed by? The preferred CA - or TurkTrust (to pick
on the latest poster-child for unfortunate judgement in CA behavior)? With
a current NSS, Win, or Apple trust anchor database, it doesn't matter and
there will be no indication that it wasn't your preferred one, it'll
validate just fine. In fact, since what's supposed to be in the "right"
cert is obtainable by issuing a /CACerts, the "wrong issuer but validates
anyway" cert can even have the right URI in it. [So you might want to check
the language about trusted URI while you're at it...]

As crucial as TA management is, I actually think this is an easy fix for
EST. The TA database is commonly a system resource. There really isn't any
need to refer to the TA database or get into the management of it. Simply
call out that there will be one specific TA that will be used for EST -
whether that TA happens to come from the device vendor, is a public CA root
cert, or is an enterprise-owned CA public key, it doesn't matter - and make
the client responsible for ensuring that that TA is used. As you note, one
way to do this is to only have one TA. Another way is to make a pointer to
the right TA a configuration detail of the client (yeah, there's a
configuration data integrity issue, but that's significantly more difficult
than the vector described in the paragraph above). Then, the fact that that
TA resides in and is managed as a datum in a database is irrelevant. (Well,
not completely irrelevant of course but can be left to the device
management policy.)

Mike