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

[Anders Rundgren <[e-mail]>]

On 2012-06-07 02:41, Dan Harkins wrote:
> 
>   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.

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

> 
>   Dan.
> 
> On Tue, June 5, 2012 7:37 pm, Sean Turner wrote:
>> 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
>>
>> On 6/4/12 6:09 PM, Max Pritikin wrote:
>>>
>>> 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:[e-mail]]
>>>>> Sent: Wednesday, April 25, 2012 7:20 PM
>>>>> To: Alexander Truskovsky
>>>>> Cc: [e-mail]; 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>>
>>>> _______________________________________________
>>>> pkix mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>>> _______________________________________________
>>> pkix mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>