Differentiate the ServiceTicket issued from Kinit vs PKinit

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Differentiate the ServiceTicket issued from Kinit vs PKinit

Aravind Jerubandi
Hello,

Today we use password based authentication (kinit). And we want to
introduce PKinit. But while validating ServiceTicket we would like to know
if the service ticket issued through Kinit to PKinit

Is there a way to find this?

If not, the other solution is to use different realms for Kinit and Pkinit.
But then we will have duplicate all the user and service principals for the
two realms. Is there any other easier solution?

Any help would be much appreciated.


--
Thanks,
Aravind
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Aravind Jerubandi
Hello,

Could you please answer my query?

On Fri, May 22, 2015 at 11:03 AM, Aravind Jerubandi <
[hidden email]> wrote:

> Hello,
>
> Today we use password based authentication (kinit). And we want to
> introduce PKinit. But while validating ServiceTicket we would like to know
> if the service ticket issued through Kinit to PKinit
>
> Is there a way to find this?
>
> If not, the other solution is to use different realms for Kinit and
> Pkinit. But then we will have duplicate all the user and service principals
> for the two realms. Is there any other easier solution?
>
> Any help would be much appreciated.
>
>
> --
> Thanks,
> Aravind
>



--
Thanks & Regards,
J.Aravind
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Brandon Allbery
On Tue, 2015-06-02 at 11:13 -0700, Aravind Jerubandi wrote:
> Hello,
>
> Could you please answer my query?

Did you miss
http://mailman.mit.edu/pipermail/kerberos/2015-May/020765.html
?

--
brandon s allbery kf8nh                           sine nomine associates
[hidden email]                              [hidden email]
unix openafs kerberos infrastructure xmonad        http://sinenomine.net

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Nico Williams
On Tue, Jun 02, 2015 at 10:57:59PM +0000, Brandon Allbery wrote:
> On Tue, 2015-06-02 at 11:13 -0700, Aravind Jerubandi wrote:
> > Hello,
> >
> > Could you please answer my query?
>
> Did you miss
> http://mailman.mit.edu/pipermail/kerberos/2015-May/020765.html
> ?

You know, *gmail* isn't showing it in the browser interface, but it's
there in the IMAP interface; it was delivered.  And it's there in the
list archive, of course.  The OP posted via gmail.  It's likely that the
OP is using gmail to read this...

Now, what's with gmail?!

Nico
--
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Brandon Allbery
On Tue, 2015-06-02 at 18:26 -0500, Nico Williams wrote:

> On Tue, Jun 02, 2015 at 10:57:59PM +0000, Brandon Allbery wrote:
> > On Tue, 2015-06-02 at 11:13 -0700, Aravind Jerubandi wrote:
> > > Hello,
> > >
> > > Could you please answer my query?
> >
> > Did you miss
> > http://mailman.mit.edu/pipermail/kerberos/2015-May/020765.html
> > ?
>
> You know, *gmail* isn't showing it in the browser interface, but it's
> there in the IMAP interface; it was delivered.  And it's there in the
> list archive, of course.  The OP posted via gmail.  It's likely that the
> OP is using gmail to read this...
>
> Now, what's with gmail?!

I wonder if it somehow has a duplicate message ID. I know gmail
suppresses those (so for example I never see the copy of a list message
that I get back, when sending from my gmail account).

I did see that message, but I'm using my work email for this list.

--
brandon s allbery kf8nh                           sine nomine associates
[hidden email]                              [hidden email]
unix openafs kerberos infrastructure xmonad        http://sinenomine.net

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Nico Williams
On Tue, Jun 02, 2015 at 11:29:35PM +0000, Brandon Allbery wrote:
> I wonder if it somehow has a duplicate message ID. I know gmail
> suppresses those (so for example I never see the copy of a list message
> that I get back, when sending from my gmail account).

Gmail doesn't suppress duplicates, it just shows them in such a way that
it's easy to ignore them.

What's funny is that this is not specific to the recipient, but to the
posted message.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Aravind Jerubandi
In reply to this post by Brandon Allbery
Thanks for your prompt response. Somehow i didn't receive your response
earlier.

We want to use both Kinit and PKinit going forward.

Let's say we create a second REALM for PKinit, then as per your suggestion
we need to create all the User and Service principals on second realm as
well right?


On Tue, Jun 2, 2015 at 3:57 PM, Brandon Allbery <[hidden email]>
wrote:

> On Tue, 2015-06-02 at 11:13 -0700, Aravind Jerubandi wrote:
> > Hello,
> >
> > Could you please answer my query?
>
> Did you miss
> http://mailman.mit.edu/pipermail/kerberos/2015-May/020765.html
> ?
>
> --
> brandon s allbery kf8nh                           sine nomine associates
> [hidden email]                              [hidden email]
> unix openafs kerberos infrastructure xmonad        http://sinenomine.net
>



--
Thanks & Regards,
J.Aravind
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Ken Hornstein
In reply to this post by Aravind Jerubandi
> Today we use password based authentication (kinit). And we want to
> introduce PKinit. But while validating ServiceTicket we would like to know
> if the service ticket issued through Kinit to PKinit
>
> Is there a way to find this?

We sort-of do this, but it may not directly be applicable.

Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular
policy OID is found in the client certificate (in our case, the policy
OID we check for is if the certificate comes from a smartcard, so the
use of HW-AUTH is appropriate).  Flags set in a TGT get propagated to
service tickets, so we have code on application servers that checks to see
if the HW-AUTH flag exists for service tickets to make authorization
decisions.

So, you could do that (if your client-side certificates is issued from
a hardware device), or overload the HW-AUTH flag.  Checking that on the
application server side is easy.

But ... if you don't want to do that, you MAY be able to check the service
ticket for the AD_INITIAL_VERIFIED_CAS authorization data (although a quick
glance suggests to me that MIT Kerberos doesn't generate that data, but
I could be wrong about that).  That would require further investigation.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Simo Sorce-3
On Tue, 2015-06-02 at 21:11 -0400, Ken Hornstein wrote:

> > Today we use password based authentication (kinit). And we want to
> > introduce PKinit. But while validating ServiceTicket we would like to know
> > if the service ticket issued through Kinit to PKinit
> >
> > Is there a way to find this?
>
> We sort-of do this, but it may not directly be applicable.
>
> Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular
> policy OID is found in the client certificate (in our case, the policy
> OID we check for is if the certificate comes from a smartcard, so the
> use of HW-AUTH is appropriate).  Flags set in a TGT get propagated to
> service tickets, so we have code on application servers that checks to see
> if the HW-AUTH flag exists for service tickets to make authorization
> decisions.
>
> So, you could do that (if your client-side certificates is issued from
> a hardware device), or overload the HW-AUTH flag.  Checking that on the
> application server side is easy.
>
> But ... if you don't want to do that, you MAY be able to check the service
> ticket for the AD_INITIAL_VERIFIED_CAS authorization data (although a quick
> glance suggests to me that MIT Kerberos doesn't generate that data, but
> I could be wrong about that).  That would require further investigation.

There is work to actually provide this kind of information here:
https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-00

Hopefully this will be approved soon, implementation is underway.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Jim Shi

>> We sort-of do this, but it may not directly be applicable.
>>
>> Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular
>> policy OID is found in the client certificate (in our case, the policy
>> OID we check for is if the certificate comes from a smartcard, so the
>> use of HW-AUTH is appropriate).  Flags set in a TGT get propagated to
>> service tickets, so we have code on application servers that checks to see
>> if the HW-AUTH flag exists for service tickets to make authorization
>> decisions.


Hi, Simo,
  Does this require to modify MIT KDC source code?

Thanks
Jim





> On Jun 2, 2015, at 7:36 PM, Simo Sorce <[hidden email]> wrote:
>
> On Tue, 2015-06-02 at 21:11 -0400, Ken Hornstein wrote:
>>> Today we use password based authentication (kinit). And we want to
>>> introduce PKinit. But while validating ServiceTicket we would like to know
>>> if the service ticket issued through Kinit to PKinit
>>>
>>> Is there a way to find this?
>>
>> We sort-of do this, but it may not directly be applicable.
>>
>> Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a particular
>> policy OID is found in the client certificate (in our case, the policy
>> OID we check for is if the certificate comes from a smartcard, so the
>> use of HW-AUTH is appropriate).  Flags set in a TGT get propagated to
>> service tickets, so we have code on application servers that checks to see
>> if the HW-AUTH flag exists for service tickets to make authorization
>> decisions.
>>
>> So, you could do that (if your client-side certificates is issued from
>> a hardware device), or overload the HW-AUTH flag.  Checking that on the
>> application server side is easy.
>>
>> But ... if you don't want to do that, you MAY be able to check the service
>> ticket for the AD_INITIAL_VERIFIED_CAS authorization data (although a quick
>> glance suggests to me that MIT Kerberos doesn't generate that data, but
>> I could be wrong about that).  That would require further investigation.
>
> There is work to actually provide this kind of information here:
> https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-00
>
> Hopefully this will be approved soon, implementation is underway.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Aravind Jerubandi
In reply to this post by Ken Hornstein
Hi Ken,

Thanks for your response. This really helps.




*Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a
particular          policy OID is found in the client certificate (in our
case, the policy          OID we check for is if the certificate comes from
a smartcard, so the          use of HW-AUTH is appropriate). *

Does this mean the client certificate should have the policy :
1.3.6.1.4.1.311.20.2.2
 (Smart Card Logon)?

Is it only the client certificate or CA cert should also have this policy?


On Tue, Jun 2, 2015 at 6:11 PM, Ken Hornstein <[hidden email]> wrote:

> > Today we use password based authentication (kinit). And we want to
> > introduce PKinit. But while validating ServiceTicket we would like to
> know
> > if the service ticket issued through Kinit to PKinit
> >
> > Is there a way to find this?
>
> We sort-of do this, but it may not directly be applicable.
>
> Our KDC-side PKINIT module will set HW-AUTH flag on the TGT _if_ a
> particular
> policy OID is found in the client certificate (in our case, the policy
> OID we check for is if the certificate comes from a smartcard, so the
> use of HW-AUTH is appropriate).  Flags set in a TGT get propagated to
> service tickets, so we have code on application servers that checks to see
> if the HW-AUTH flag exists for service tickets to make authorization
> decisions.
>
> So, you could do that (if your client-side certificates is issued from
> a hardware device), or overload the HW-AUTH flag.  Checking that on the
> application server side is easy.
>
> But ... if you don't want to do that, you MAY be able to check the service
> ticket for the AD_INITIAL_VERIFIED_CAS authorization data (although a quick
> glance suggests to me that MIT Kerberos doesn't generate that data, but
> I could be wrong about that).  That would require further investigation.
>
> --Ken
>



--
Thanks & Regards,
J.Aravind
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Simo Sorce-3
In reply to this post by Jim Shi
On Tue, 2015-06-02 at 21:29 -0700, Jim Shi wrote:
> Hi, Simo,
>   Does this require to modify MIT KDC source code?

Yes

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Ken Hornstein
In reply to this post by Aravind Jerubandi
>Does this mean the client certificate should have the policy :
>1.3.6.1.4.1.311.20.2.2
> (Smart Card Logon)?
>
>Is it only the client certificate or CA cert should also have this policy?

Well, we don't use that particular OID; we use another one defined by our
CA that indicates it comes from an approved Smart Card.  But that's the
basic idea.

I don't want to get into a whole discussion about certificate policy;
that's sort of outside of the scope of this thread.  I will say that in
our particlar case, it only matters that the client certificate has that
policy OID on it and that's all our implementation checks for.

And let me be clear; this is not something that exists in the supplied
MIT Kerberos pkinit module.  This is our own version of it.  I've
talked with MIT about incorporating our changes into their module,
and they have been receptive; I just haven't had time recently to
deal with it.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Jim Shi
Hi, Ken,
 The TGS ticket flag is set on KDC server.  When the client get TGS back from the server, he/she is able to see the flag set by the KDC. Looks klist commands will show flags.

However if the client passes the ticket to some service for verification, , the service will not be able  see the these flags. Is that right? My understanding is that  these flags are not  passed to service??



Thanks
Jim





> On Jun 3, 2015, at 6:39 AM, Ken Hornstein <[hidden email]> wrote:
>
>> Does this mean the client certificate should have the policy :
>> 1.3.6.1.4.1.311.20.2.2
>> (Smart Card Logon)?
>>
>> Is it only the client certificate or CA cert should also have this policy?
>
> Well, we don't use that particular OID; we use another one defined by our
> CA that indicates it comes from an approved Smart Card.  But that's the
> basic idea.
>
> I don't want to get into a whole discussion about certificate policy;
> that's sort of outside of the scope of this thread.  I will say that in
> our particlar case, it only matters that the client certificate has that
> policy OID on it and that's all our implementation checks for.
>
> And let me be clear; this is not something that exists in the supplied
> MIT Kerberos pkinit module.  This is our own version of it.  I've
> talked with MIT about incorporating our changes into their module,
> and they have been receptive; I just haven't had time recently to
> deal with it.
>
> --Ken
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Jim Shi
Never mind. I assume the flags is inside the ticket.


Thanks
Jim





> On Jun 3, 2015, at 3:52 PM, Jim Shi <[hidden email]> wrote:
>
> Hi, Ken,
>  The TGS ticket flag is set on KDC server.  When the client get TGS back from the server, he/she is able to see the flag set by the KDC. Looks klist commands will show flags.
>
> However if the client passes the ticket to some service for verification, , the service will not be able  see the these flags. Is that right? My understanding is that  these flags are not  passed to service??
>
>
>
> Thanks
> Jim
>
>
>
>
>
>> On Jun 3, 2015, at 6:39 AM, Ken Hornstein <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>> Does this mean the client certificate should have the policy :
>>> 1.3.6.1.4.1.311.20.2.2
>>> (Smart Card Logon)?
>>>
>>> Is it only the client certificate or CA cert should also have this policy?
>>
>> Well, we don't use that particular OID; we use another one defined by our
>> CA that indicates it comes from an approved Smart Card.  But that's the
>> basic idea.
>>
>> I don't want to get into a whole discussion about certificate policy;
>> that's sort of outside of the scope of this thread.  I will say that in
>> our particlar case, it only matters that the client certificate has that
>> policy OID on it and that's all our implementation checks for.
>>
>> And let me be clear; this is not something that exists in the supplied
>> MIT Kerberos pkinit module.  This is our own version of it.  I've
>> talked with MIT about incorporating our changes into their module,
>> and they have been receptive; I just haven't had time recently to
>> deal with it.
>>
>> --Ken
>> ________________________________________________
>> Kerberos mailing list           [hidden email] <mailto:[hidden email]>
>> https://mailman.mit.edu/mailman/listinfo/kerberos <https://mailman.mit.edu/mailman/listinfo/kerberos>
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Differentiate the ServiceTicket issued from Kinit vs PKinit

Ken Hornstein
>Never mind. I assume the flags is inside the ticket.

Yeah, exactly.  The KDC sets the flags, so you can trust their validity.

The one big issue is that if you're programming the GSSAPI, there's
not a standardized GSSAPI function you can call to retrieve those flags,
which is unfortunate; for MIT Kerberos, there is a function called
gss_krb5_get_ticket_flags() you can use and it looks like the same thing
exists for Heimdal.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos