Re: Was a smartcard used to get the ticket?

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

On Aug 8, 2007, at 7:39 AM, Douglas E. Engert wrote:

>
>
> Phil Fisher wrote:
>> Is it possible to find out if a smartcard was used to get a ticket?
>
> I too am interested in this issue, and this was brought up on the  
> ietf krb-wg
> mailing list, and a discussion on "levels of assurance" was held  
> after the
> working group meeting a few weeks ago in Chicago.
>
> There is a hw-authent bit in the TicketFlags, the the KDC should  
> set if a hardware
> device was used to authenticate. But for some this is not enought  
> information.
>
> Some people where interested in adding SAML assertions to the auth- 
> data.
>
> Others where interested in extending the PKINIT (RFC 4556) auth- 
> data to also
> include either the cert actually used or at least an  
> ExternalPrincipalIdentifier
> of the user certificate.
>
>> A ticket is obtained with kinit. This may be with or without the - 
>> C PKCS11:... option to use a smartcard.
>> My application then uses gss_init_sec_context() with  
>> GSS_C_NO_CREDENTIAL to get the default. It would be useful to know  
>> if a smartcard was used so that:
>>   1) an administrator can insist on smartcards being used.
>
>>   2) the application can adjust its response to a smartcard being  
>> removed.

If you are using kerberos then you can't know if the card has been  
removed from the reader subsequent to getting the tgt.  Also if you  
are using gssapi then you don't have access to the Kerberos-specific  
status bits and such without breaking the abstraction layer.  (Should  
we then call it the KSSAPI? ;-)

I believe that this renders pkinit/kerberos unsuitable for use with  
"high" security level applications (per NASA/FIPS requirements), but  
we have asked for clarification.  There is understanding that  
requiring the card be kept in the reader during all processing really  
stinks from a usability standpoint.

> Are you assuming the application is being run on the same machine? But
> it is the KDC that needs to make the call.
>
> The only way a KDC can know if a smart card was actually being use  
> is by
> trusting the CA that issued the certificate, that the private key  
> associated
> with the certificate is on a smartcard, and can not be read off the  
> card.
> (Other wise the user could have copied the cert and key and used  
> software.)
>
>> I've not found anything relevant in the documentation or with Google.
>> nm on libgssapi.so shows  
>> gsskrb5_extract_authz_data_from_sec_context() which looks  
>> promising, but I'm not sure what it gives or how to use it. I  
>> assume that it returns an AuthorizationData structure, but I'm not  
>> clear if this contains the information I need or what value the  
>> ad_type parameter should have.
>> Is what I want possible? Is  
>> gsskrb5_extract_authz_data_from_sec_context() the right way to get  
>> the information? Is its use documented somewhere?
>
> I know Windows AD will set the hw-authent bit, if you use a smart  
> card,
> but not sure if Heimdal KDC will set it, or if the Heimdal klist  
> will show it.
> (The hw-authent could also imply an OTP or other hardware device,  
> and not
> a smartcard.)

Heimdal 0.8-ish does not set the bit when a smart card is used.   
(After all the KDC only knows you have a PKI cert, it doesn't know  
where on the client it resides.)  Heimdal klist --verbose shows the  
flags.

> But is is also not clear if the KDC will only set the hw-authent  
> bit if
> if the KDC has the requires-hw-auth set on the user entry. (I don't  
> have
> a heimdal KDC.)
>
> So today your best bet is to look at the TicketFlags. It looks like  
> the Heimdal
> gsskrb5_inquire_sec_context_by_oid with the OID of  
> GSS_KRB5_GET_TKT_FLAGS_X
> will return them.
>
> If so, and your KDC's only hardware devices are smart cards from  
> CAs using
> only smartcard card, then this could be your bit.

I asked about adding a pkinit flag to parallel the hw-authent bit on  
the IETF list and was shot down.  It wasn't felt that every  
authentication method ought to have its own flag in general, and for  
pkinit in particular:

On Dec 7, 2006, at 4:21 PM, Jeffrey Hutzelman wrote:
>
> See RFC 4556 section 3.2.3.  If PKINIT is used, the KDC will  
> include the AD-INITIAL-VERIFIED-CAS authorization data element.
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>   Chair, IETF Kerberos Working Group
>   Carnegie Mellon University - Pittsburgh, PA
>  (630) 252-5444

------------------------------------------------------------------------
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