[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Was a smartcard used to get the ticket?
Henry B. Hotz wrote:
>
> 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? ;-)
That is always a problem. Could there be a generic routine to return
"Its was from a smart card"? Is this part of a generic "level of assurance"?
>
> 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.
>
That would require the application to be run on the same machine as the
reader! And the machine was secured from the user!! I have always looked
at the application being on a server, and the user has admin and
physical access to the reader and client machine.
(Microsoft login had an option to lock the screen if the card was removed,
but in this case the application *is* the local OS, which is on the same
machine but this is not the general case.)
>> 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 oFught 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.
In effect the presents of the AD_INITIAL_VERIFIED_CAS could be used as a flag
that PKINIT was used, but does not say if it was via smart card, other
then if the CA only issued certs for smartcards.
But the AD-INITIAL-VERIFIED-CAS contains the ExternalPrincipalIdentifier
But the way I read it, it only lists the CAs used, and not the user.
Thus the comment in my original response:
"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."
Without this the application only has the principal name, and not
any other info from the cert.
>>
>> -- 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
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444