Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

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

Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

Hostetler,Alex
Hey All,

We seem to be running into a bug and our team may have made some incorrect assumptions when we first rolled this out.  We have a few issues.  These are all performed on rhel 7.3 using packages 1.14.1-27.el7_3.

First
We are able to run “kinit –R” outside of the expiration time.  The man pages say this shouldn’t be able to occur.
Ex.

09:25:23 $ klist -ef
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net@realm

Valid starting       Expires              Service principal
10/16/2017 09:25:17  10/16/2017 09:27:17  krbtgt/realm@realm
                renew until 10/16/2017 09:31:17, Flags: FRI
                Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

09:25:25 $ sleep 140; date; kinit -R; klist
Mon Oct 16 09:27:59 CDT 2017
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net@realm

Valid starting       Expires              Service principal
10/16/2017 09:28:01  10/16/2017 09:30:01  krbtgt/realm@realm
                renew until 10/16/2017 09:31:17

Here the ticket lifetime is 2 mins, renew time is 6 mins.  We sleep for 140 seconds and are still able to renew the ticket anyway.  I believe this is a bug.

Second
This one may just be a misunderstanding on my part.
Similar situation.  Ticket lifetime is 2 mins, renewable for 6.  When we get to the 5th min of the renew until time, where if we were to kinit –R again the expiration date would be outside of that renew until time, should the ticket expire or should the valid starting time just be updated and the expiration time capped?  We had a patched package that did things the latter way and the regular 1.14 packages that do it the former.

Third
This may be answered in the above, but when we kinit –R in a situation like the second problem, at the end of the renew until time so the ticket lifetime would put it outside of that window.  We see the ticket expire in 1.14, but when doing a klist the ticket still looks valid since it shows it within the valid starting time and expiration date.  The ticket no longer functions – as expected from the output of kinit –R, is the expired ticket displayed in any way to klist?

Thank you for your time!

Alex H.


CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

Greg Hudson
On 10/16/2017 11:03 AM, Hostetler,Alex wrote:
> Here the ticket lifetime is 2 mins, renew time is 6 mins.  We sleep for 140 seconds and are still able to renew the ticket anyway.  I believe this is a bug.

Because the client and KDC clocks might drift, the KDC applies a grace
period to ticket expiration, defaulting to five minutes.  I think that's
what you are seeing here, as the ticket has only been expired for 20
seconds in this scenario.

> Similar situation.  Ticket lifetime is 2 mins, renewable for 6.  When we get to the 5th min of the renew until time, where if we were to kinit –R again the expiration date would be outside of that renew until time, should the ticket expire or should the valid starting time just be updated and the expiration time capped?  We had a patched package that did things the latter way and the regular 1.14 packages that do it the former.

I can't figure out what "5th min of the renew until time" means here.
Are you talking about five minutes after the initial ticket issuance
time, or seven?  When you say "lifetime is 2 mins, renewable for 6", is
the renewable end time six minutes after the initial ticket issuance
time (what I would expect), or eight?  I'm also not sure what you mean
by "should the ticket expire?"

Although I don't understand the question, I can say there have been some
changes in KDC behavior around this area.  Releases 1.12 through 1.15
will not issue "trivially renewable tickets", where renewable endtime
doesn't exceed ticket endtime; instead it will issue a non-renewable
ticket.  The forthcoming release 1.16 will go back to issuing trivially
renewable tickets.

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7661
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8609

> This may be answered in the above, but when we kinit –R in a situation like the second problem, at the end of the renew until time so the ticket lifetime would put it outside of that window.  We see the ticket expire in 1.14, but when doing a klist the ticket still looks valid since it shows it within the valid starting time and expiration date.  The ticket no longer functions – as expected from the output of kinit –R, is the expired ticket displayed in any way to klist?

I don't think the KDC should ever issue a ticket which is already
expired.  I'd like to see more specifics about this case.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

Hostetler,Alex
> Releases 1.12 through 1.15
    will not issue "trivially renewable tickets", where renewable endtime
    doesn't exceed ticket endtime; instead it will issue a non-renewable
    ticket.  The forthcoming release 1.16 will go back to issuing trivially
    renewable tickets.

I think this may answer all my questions, we were previously using 1.10.3-33.1.sf1257154.el6 and jumped up to 1.14.  But I’ll try to explain the issues a bit better just so I’m clear.


11:02:22 $ kinit test/bdatadevkdc01.northamerica.net@realm
Password for test/bdatadevkdc01.northamerica.net@realm:

11:02:40 $ sleep 140; kinit -R; klist -ef; sleep 140; kinit -R; klist -ef
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net@realm

Valid starting       Expires              Service principal
10/16/2017 11:05:05  10/16/2017 11:07:05  krbtgt/realm@realm
renew until 10/16/2017 11:08:39, Flags: FRIT
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net@realm


Valid starting       Expires              Service principal
10/16/2017 11:07:27  10/16/2017 11:08:39  krbtgt/realm@realm
Flags: FRIT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96


11:07:27 $ kinit -R
kinit: Ticket expired while renewing credentials

-----> Here is where our packages differ, with 1.14 we get a ticket expired, with 1.10.3-33.1.sf1257154.el6, we would just see the valid starting date get updated.
Another thing that is different between the two versions is the lack of a renew until time on the klist above this kinit –R. It still has a renewable flag, which confused me a bit.


11:07:51 $ klist -ef
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net@realm

Valid starting       Expires              Service principal
10/16/2017 11:07:27  10/16/2017 11:08:39  krbtgt/realm@realm
Flags: FRIT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

My third question was around the above, we still see the ticket and it looks like it’s within the valid times, but above the ticket expired on the above kinit –R.  This is reflected in our env and the ticket no longer functions, but has presented issues with our automation.  We’ve worked around those issues now, so this is mostly for my understanding.

I believe both of these questions are explained by the “trivially renewable tickets” and links you posted.

Thank you so much! I’ve had a support case open with redhat about these issues for 2+ months and it didn’t get anywhere.

Alex H.


On 10/16/17, 10:43 AM, "Greg Hudson" <[hidden email]> wrote:

    On 10/16/2017 11:03 AM, Hostetler,Alex wrote:
    > Here the ticket lifetime is 2 mins, renew time is 6 mins.  We sleep for 140 seconds and are still able to renew the ticket anyway.  I believe this is a bug.

    Because the client and KDC clocks might drift, the KDC applies a grace
    period to ticket expiration, defaulting to five minutes.  I think that's
    what you are seeing here, as the ticket has only been expired for 20
    seconds in this scenario.

    > Similar situation.  Ticket lifetime is 2 mins, renewable for 6.  When we get to the 5th min of the renew until time, where if we were to kinit –R again the expiration date would be outside of that renew until time, should the ticket expire or should the valid starting time just be updated and the expiration time capped?  We had a patched package that did things the latter way and the regular 1.14 packages that do it the former.

    I can't figure out what "5th min of the renew until time" means here.
    Are you talking about five minutes after the initial ticket issuance
    time, or seven?  When you say "lifetime is 2 mins, renewable for 6", is
    the renewable end time six minutes after the initial ticket issuance
    time (what I would expect), or eight?  I'm also not sure what you mean
    by "should the ticket expire?"

    Although I don't understand the question, I can say there have been some
    changes in KDC behavior around this area.  Releases 1.12 through 1.15
    will not issue "trivially renewable tickets", where renewable endtime
    doesn't exceed ticket endtime; instead it will issue a non-renewable
    ticket.  The forthcoming release 1.16 will go back to issuing trivially
    renewable tickets.

    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkrbdev.mit.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D7661&data=02%7C01%7CAlex.Hostetler%40cerner.com%7Cff7d917014ca4fb6e1ba08d514aac68a%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C0%7C636437646064443994&sdata=Pir0pynTpeB%2FgDsqNEkBAYCBaJszf%2BJaEHS6T30FvdU%3D&reserved=0
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkrbdev.mit.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D8609&data=02%7C01%7CAlex.Hostetler%40cerner.com%7Cff7d917014ca4fb6e1ba08d514aac68a%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C0%7C636437646064443994&sdata=MaLgwzd%2BgGyu0MFraiejQFdQtIYv3xeyPTIDqxK2uUM%3D&reserved=0

    > This may be answered in the above, but when we kinit –R in a situation like the second problem, at the end of the renew until time so the ticket lifetime would put it outside of that window.  We see the ticket expire in 1.14, but when doing a klist the ticket still looks valid since it shows it within the valid starting time and expiration date.  The ticket no longer functions – as expected from the output of kinit –R, is the expired ticket displayed in any way to klist?

    I don't think the KDC should ever issue a ticket which is already
    expired.  I'd like to see more specifics about this case.




CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.

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

Re: Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

Greg Hudson
On 10/16/2017 12:28 PM, Hostetler,Alex wrote:
> Another thing that is different between the two versions is the lack of a renew until time on the klist above this kinit –R. It still has a renewable flag, which confused me a bit.

That is a known bug.  The intent of the 1.12-1.15 KDC code was to issue
a non-renewable ticket in this case, but due to an oversight, a ticket
is issued with the renewable flag but no renewable end time.  When you
try to renew such a ticket, you see a "Ticket expired" error because,
while the ticket isn't expired in the normal sense, the KDC sees the
ticket renewable end time as 0, and there is no separate error code for
renewable-time-expired.  If the ticket were actually not renewable as
intended, you would instead see a "KDC can't fulfill requested option"
error (which admittedly isn't very descriptive either).

This bug is fixed for 1.16 by #8609, alongside the change to issue
trivially renewable tickets again.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos