Re: [PATCH] Enforce EKU requirements for client tokens during PKINIT

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Jan 28, 2008, at 2:18 PM, Love Hörnquist Åstrand wrote:

>
> 28 jan 2008 kl. 15.44 skrev Timothy J. Miller:
>
>> On Jan 27, 2008, at 7:09 AM, Love Hörnquist Åstrand wrote:
>>
>>> For the krb5_pk_create_sign(), how about the code searches for  
>>> IETF EKU, the mssmartcard-login eku and then w/o an eku instead.  
>>> Would that no allow no change to the API ?
>>
>> I debated this but thought the additional cost of passing through  
>> the cert list multiple times would be a waste.  I've also started  
>> thinking along the lines of generalizing the selection process so  
>> that arbitrary criteria could be set (much like MIT) and it seems  
>> to me that the less special-case code there is in  
>> _krb5_pk_create_sign() the better it will be in pursuing this.
>
> Right, it would be better is there was a selection/acl language i  
> hx509 that could be used. But I've not gone down that road since  
> the need have not been there.
>
> The cert list is in memory, and the lookups can be cached if its  
> shown to be slow.

I expect to need to do pkinit with PIV card certs which contain a the  
Microsoft attributes.  However I will need to ignore those attributes.

I'm not convinced the usage context for the cards is so performance  
sensitive that re-searching the card is unacceptable.  If our use  
case is always the second or third check, then it's nice the cert's  
are cached though.

>> Another option would be to read the config file again for  
>> pkinit_win2k or pkinit_require_eku inside _krb5_pk_create_sign();  
>> that would accomplish the same thing without changing the API.  I  
>> thought about this after I got the patch working so I haven't  
>> tried it yet.  I'm still figuring out the code.
>>
>> A last option would be to pass the current context to  
>> _krb5_pk_create_sign()--a smaller API change but a change  
>> nonetheless--but when I tried this I couldn't get it to work.  I  
>> don't remember what the problem was; most likely just inattention  
>> to detail on my part.
>>
>> Is changing the API of an internal, non-exported function a big  
>> deal?  (I ask for future reference :)
>
> The function is secretly exported to the kdc, and that why  
> chainging into a context function might be good to make it ABI stable.
>
> Love

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu