Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01

From: Max Pritikin <[email-masked]>
Date: Mon, 4 Jun 2012 16:09:17 -0600

Anders may not recall that I worked with Apple on this but I certainly appreciate his praise.

The basics are that an XML configuration profile is provided over HTTPS which includes the configuration settings for a number of iOS aspects, including subsequent certificate enrollment. The XML config instructs the device to use SCEP, and further includes settings appropriate to SCEP.

The goal with EST is not to define this entire process, since device configuration is not in the PKIX charter, but rather to define a profile of CMC so that vendors like Apple can use it instead of SCEP or a homegrown method. Some of the lessons learned have been incorporated though. Unfortunately nothing about the Apple implementation of SCEP informs us concerning the issue of this thread.

I applaud Ander's for keeping the big picture in mind.

- max

On May 20, 2012, at 1:05 PM, Anders Rundgren wrote:

> IMO, Apple has a better solution to certificate enrollment than PKIX:
> 
> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html
> 
> It works both for BYOD and consumers.   Unlike traditional certificate
> enrollment schemes, the Apple profile bootstrap can also provide VPN
> settings in the the same step as certificates are enrolled!
> 
> In my own adoption of Apple's system, a server-based enrollment object is
> created before the actual profile and SCEP-request kicks in.  The SCEP DN
> and challenge are only used for binding the SCEP request to the enrollment
> object.
> 
> Anders
> 
> 
> On 2012-04-27 15:46, Alexander Truskovsky wrote:
>> Max,
>> 
>> You are correct, the same problem exists if CMS is used.  I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only.  When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI.  In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security.
>> 
>> We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal).  I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage.
>> 
>> I don't have any other suggestions right now.  Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option.  It is certainly easier to override the key usage warning in the EST server implementation when using CMS.
>> 
>> Regards,
>> Alex
>> 
>> 
>> -----Original Message-----
>> From: Max Pritikin [mailto:[email-masked]] 
>> Sent: Wednesday, April 25, 2012 7:20 PM
>> To: Alexander Truskovsky
>> Cc: [email-masked]; Matthew Campagna; Chris Bender
>> Subject: Re: Some comments on draft-ietf-pkix-est-01
>> 
>> 
>> Thank you for the feedback on EST (and SCEP). 
>> 
>> In regards for your request for EST functionality:
>> 
>> I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? 
>> 
>> "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing.
>> 
>> Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. 
>> 
>> Do you have any suggestions? It is very possible I'm missing something,
>> 
>> - max
>> 
>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote:
>> 
>>> Max,
>>> 
>>> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically:
>>> 
>>> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP.  This is now a MUST requirement in EST (A3).
>>> 2) The GetCACaps response is not signed in SCEP.  This is not a problem in EST because of the TLS use.
>>> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations.  Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1).
>>> 
>>> EST is a specification we would also consider deploying.  There is an additional use case we would like to see supported by EST.  When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication.  Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST.  Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation.
>>> 
>>> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used.  We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases.
>>> 
>>> Thanks for your consideration,
>>>  Alex
>>> 
>>> 
>>> Alexander Truskovsky
>>> BlackBerry OS Security | Research In Motion
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>> 
>> 
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 05 Jun 2012 07:30:24 +0200

Hi Max,
Thank you for chiming in on this topic which in no way is limited to EST.

As a CA developer and deployer at customer premises, I see that the practical
consequences of not taking on the entire process is that systems get quite
complex, and that you really never can be sure that they work since quite a
big portion of the process is non-standard.  Testing is true a nightmare :-(

Cisco has solved this by having their own "standard" PKI client called AnyConnect.
However, AnyConnect is not a part of Android or iPhone and has limited external
documentation, making it fairly useless for other parties.  Since Cisco and similar
external vendors aren't allowed touching the mobile browser, AnyConnect (and its
likes) doesn't offer a cool web interface like Apple do.

Early adopters, like the Swedish banks, were forced creating their own enrollment "apps"
since the lack of standards otherwise makes mobile PKI out of reach for consumers.

Talking about standards, TrustedComputingGroup have (effectively) "outsourced" the
development of web-based enrollment systems to Microsoft.  Unfortunately Microsoft
refuses sharing any details of their plans even with TCG members like me.  Maybe
particularly with me :-) :-)

Regarding the web interface and the iOS solution, you might be interested in
"how I tied the not between the web and iOS SCEP": The assumption is that the user
is authenticated in the *web environment* and through that gets a session cookie.
After successful authentication the iOS profile is delivered to the client which
then "automagically" starts the enrollment process.  Since SCEP doesn't support
cookies (?), the SCEP URL provided in the XML profile is encoded like the following

   http://scephost/enroll;jsessionid=3D939427F4767E39E83F0BC43A370472

which enables the SCEP enrollment proxy to immediately reject SCEP requests not
coming from properly authenticated users.  Although working, it hopefully gives
you an idea of the difficulties using PKIX enrollment protocols in a web world!

AFAICT, NIST doesn't have any answers to this request from the Obama administration:
http://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government-strategy.pdf

Regards,
Anders

---

From: Sean Turner <[email-masked]>
Date: Tue, 05 Jun 2012 22:37:18 -0400

Interesting ...  In http://datatracker.ietf.org/doc/draft-turner-sodp/ 
there's a concept of Product Availability List (PAL).  It's an XML file 
that clients can use to walk through the products (keys, firmware, etc.) 
that are available for it to download.

spt

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 06 Jun 2012 07:14:17 +0200

Since I was CC:ed I guess I'm entitled commenting on this draft as well?
http://www.ietf.org/id/draft-turner-sodp-02.txt

I believe that comparing Apple's profile system (mentioned in the
referenced mail), to PAL would be wrong because Apple's system follows
the path that I have selected for my own work in this space, namely
*server-centric object provisioning and management*.

SCEP, EST, CMP, SODP etc. are all client-orchestrated solutions.

IMHO, the web is more suited to server-centric solutions because the
need for a new security object doesn't start at the client; it begins
with a human user wanting to do something new, which may require a
secure object like a virtual credit card.

Although skimming the SKS/KeyGen2 docs indeed shows that it is the
client that generates a key-pair, a deeper look will reveal that it
does that as a response to a *server request*.  That the scheme is
server-centric seems like a prerequisite for being able to perform
a sequence of secure operations in an atomic fashion (transaction),
aided by a session-key using light-weight cryptography.

Algorithm agility is also mainly a server (service) policy issue since
it is the payment network (here taking on the virtual credit card
example again...) that may prefer/require EC P-256 before RSA 2048.
The PKI client or human user can hardly have much saying here.

My gut-feeling is that the availability of embedded security hardware
and NFC will accelerate the trend towards end-to-end-secured
server-centric object-provisioning using session-keys.

regards,
Anders

---

From: Sean Turner <[email-masked]>
Date: Wed, 06 Jun 2012 07:27:49 -0400

Anders,

You're always welcome to comment.

Some more inline...

spt

> SCEP, EST, CMP, SODP etc. are all client-orchestrated solutions.

Hmm not entirely so.  In SODP, server-requested rekeys are supported. 
The idea is that the client comes preloaded with a cert that it uses to 
do mutual authentication with the server, and the first thing the client 
will see in the PAL is a notice from the server that says please rekey.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Jun 2012 17:41:26 -0700 (PDT)

What's needed isn't keys or firmware, it's data to configure a particular
protocol on the client to use the certificates it got from EST. For example,
if it's wifi, then the xml config would include something like what SSID to
connect to and what EAP method it should use (presumably EAP-TLS, but
who knows). For IPsec the config would say what gateway the client should
connect to, how often it should reauthenticate, it could maybe even provide
some data to add to the SPD. Upon receipt of the xml blob, the device
configures itself to use the certificates.

  Dan.

On Tue, June 5, 2012 7:37 pm, Sean Turner wrote:
>> The basics are that an XML configuration profile is provided over HTTPS
>> which includes the configuration settings for a number of iOS aspects,
>> including subsequent certificate enrollment. The XML config instructs
>> the device to use SCEP, and further includes settings appropriate to
>> SCEP.
>>
>> The goal with EST is not to define this entire process, since device
>> configuration is not in the PKIX charter, but rather to define a profile
>> of CMC so that vendors like Apple can use it instead of SCEP or a
>> homegrown method. Some of the lessons learned have been incorporated
>> though. Unfortunately nothing about the Apple implementation of SCEP
>> informs us concerning the issue of this thread.
>>
>>>> You are correct, the same problem exists if CMS is used.  I think an
>>>> exception to the RFC 5280 key usage restrictions is reasonable in the
>>>> case of certificate renewal only.  When verifying certificates you
>>>> have never seen before, I believe it is important to ensure the key
>>>> usage is appropriate and EST should perform full certificate
>>>> verification when authenticating the initial CSRs using certificates
>>>> issued by another PKI.  In the case of certificate renewal the EST
>>>> server will be verifying certificates that it issued, and I think
>>>> ignoring the key usage here does not really degrade security.
>>>>
>>>> We are interested in deploying a solution that will work for Client
>>>> Authentication and Email Protection certificates (enrollment and
>>>> renewal).  I don't think that mobile devices have the need to support
>>>> enrollment for certificates with any other extended key usage.
>>>>
>>>> I don't have any other suggestions right now.  Perhaps the TLS client
>>>> authentication can still be used if it is more convenient to some
>>>> clients and CMS can be used as a secondary option.  It is certainly
>>>> easier to override the key usage warning in the EST server
>>>> implementation when using CMS.
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>>
>>>> I agree that dealing with clients that can't use their certificates
>>>> for digitalSignature is a problem -- but doesn't the same problem
>>>> exist if the client's key usage is such that they shouldn't be signing
>>>> PKCS7/CMS either?
>>>>
>>>> "CMC provides a method to prove the client's identity based on a
>>>> client/server shared-secret" [RFC5272] ... but I don't believe it
>>>> provides an exception to the problem you're discussing.
>>>>
>>>> Is there general interest in finding another approach? I've hesitated
>>>> to suggest an exception to the RFC5280 key usage restrictions but
>>>> haven't been able to think of a different approach.
>>>>
>>>>> I have been implementing the current SCEP draft, and have come across
>>>>> several issues that we are glad to see addressed in EST,
>>>>> specifically:
>>>>>
>>>>> 1) The use of a certificate issued by another PKI to authenticate the
>>>>> initial request is optional in SCEP.  This is now a MUST requirement
>>>>> in EST (A3).
>>>>> 3) The SCEP draft mentions that RSA is the only algorithm supported
>>>>> by the current implementations.  Although there is no technical
>>>>> limitation that prevents the usage of ECC in SCEP and some
>>>>> implementations do support ECC, we are glad to see that algorithm
>>>>> agility is a MUST requirement in EST (K1).
>>>>>
>>>>> EST is a specification we would also consider deploying.  There is an
>>>>> additional use case we would like to see supported by EST.  When
>>>>> renewing an email protection certificate, it cannot be used to
>>>>> authenticate the request using the TLS client authentication.
>>>>> Although this can be achieved by using a full CMC operation, it would
>>>>> be better if it were handled by plain EST.  Wrapping the PKCS10 in
>>>>> PKCS7 and signing it with the email protection key would work without
>>>>> having to use a full CMC operation.
>>>>>
>>>>> We think the use of TLS client authentication, although elegant,
>>>>> makes it inconvenient to use in some cases because a full CMC
>>>>> operation needs to be used.  We propose to continue using PKCS7 to
>>>>> wrap the PKCS10 to support this and similar use cases.
>>>>>
>>>>> This transmission (including any attachments) may contain
>>>>> confidential information, privileged material (including material
>>>>> protected by the solicitor-client or other applicable privileges), or
>>>>> constitute non-public information. Any use of this information by
>>>>> anyone other than the intended recipient is prohibited. If you have
>>>>> received this transmission in error, please immediately reply to the
>>>>> sender and delete this information from your system. Use,
>>>>> dissemination, distribution, or reproduction of this transmission by
>>>>> unintended recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>> This transmission (including any attachments) may contain confidential
>>>> information, privileged material (including material protected by the
>>>> solicitor-client or other applicable privileges), or constitute
>>>> non-public information. Any use of this information by anyone other
>>>> than the intended recipient is prohibited. If you have received this
>>>> transmission in error, please immediately reply to the sender and
>>>> delete this information from your system. Use, dissemination,
>>>> distribution, or reproduction of this transmission by unintended
>>>> recipients is not authorized and may be unlawful.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 07 Jun 2012 07:17:21 +0200

> configures itself to use the certificates.

Yes.  That's pretty much what Apple's already implemented scheme does.  What's
more, you can perform this over the web.  The SCEP profile entry contains the
challenge as well which effectively moves the actual authentication to the invoking
web application which allows you to use any method from e-mail round-trip, to
AD/Kerberos, to passwords.  That is, in a web-centric enrollment system you do
not really want *user authentication* inside of the protocol.

Regarding Sean's SODP, it appears to be a universal security object management
system building on EST.

Going back to the core, Apple still doesn't support enrollment of two-factor
authentication tokens like keys protected by PIN-codes which is one of many
reasons why they some day will have to switch to another system.  Using PKIX
protocols isn't an option since these do not address two-factor authentication.
In addition, Apple probably needs to add support for end-to-end-security (w r t the
*cryptographic container*) which also is outside of the PKIX charter.

The cryptographic processor will most certainly be a part of the standard CPU
because the cost in terms of silicon is less than 0.1 mm2 and it is anyway a
prerequisite for thwarting "jail-breaking".

Anders