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

Re: Was a smartcard used to get the ticket?

On Aug 9, 2007, at 1:19 AM, Love Hörnquist Åstrand wrote:

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

Wish I had been able to listen in to the IETF discussion.  The  
meeting notes are a bit skimpy.

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

That's only a "voluntary" solution.

The service can't have any hard guarantees and that's what might be  
needed.  Only way I can see to guarantee that on a remote machine is  
if an ssl connection is used with the client cert on the card and  
frequent re-keying is required.  Lousy user experience, but then  
requiring the card be in the reader the whole time is lousy user  
experience to begin with.

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

But I want subjects that live on smartcard *or* OTP (as fallback on  
incapable clients, like a machine you've rented in an internet cafe),  
but not ordinary password.

If we're talking wish list here:  I'd say first that the hw-authent  
bit should be set if a hardware OTP token was used, or if an x509  
cert that lives on a smart card was used.  Second, I'd say that the  
ACL entry defining the X509 cert for a user ought to have a flag that  
says if the cert lives on a smart card.  (Did you allow multiple  
certs/acl?  If so then flag should be per-cert.)  Finally the  
attribute that says hw-pa required should be enforced i.a.w. the above.

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