[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Was a smartcard used to get the ticket?



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

Right now it hard to determine what was used to get inital tickets,  
however
its very simple to add such flags/info.

The question is what interfaces people wants to have, SAML, PA-DATA
with LoA or just a flag. If I can avoid diversion is would be great,  
but I'm afraid
that wont be possible.

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

If the application knows smatcard was used, it could poll for the  
smartcard
and kill the remote connection when the smartcard was removed.

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

I re-added back gss_krb5_get_tkt_flags that used to exists, it fell  
out with the mech-glue.

> If so, and your KDC's only hardware devices are smart cards from  
> CAs using
> only smartcard card, then this could be your bit.

The simplest thing would be to add a hdb entry flags for each  
principal to tell if the
subjec is living on a smartcard or not, maybe I can extend the acl  
field for that.

Love