Possible enhancement request for extra krb5.conf parameter support for kinit

[Neng Xue]

Hi,

I am Neng Xue who works in Oracle Solaris Security group. Recently when
I was working on a kerberos related project I noticed that Solaris
kerberos has a quite handy krb5.conf [appdefaults] parameter support for
kinit command:

forwardable=[true | false]
Can forward tickets to a remote server.

renewable=[true | false]
Creates a TGT that can be renewed (prior to the ticket expiration time).

proxiable=[true | false]
Sets the proxiable flag in all tickets.

no_addresses=[true | false]
Creates tickets with no address bindings.

However, this solaris parameter support utilizes a set of solaris
specific profile interfaces, for that matter, I cannot create a pull
request directly using this changeset. I am wondering is it possible
that I can request for such an enhancement from MIT kerberos dev team?
Thanks a lot!

Best

[Greg Hudson]

Post by Neng Xue
I am Neng Xue who works in Oracle Solaris Security group. Recently when
I was working on a kerberos related project I noticed that Solaris
kerberos has a quite handy krb5.conf [appdefaults] parameter support for
forwardable=[true | false]
Can forward tickets to a remote server.
proxiable=[true | false]
Sets the proxiable flag in all tickets.
no_addresses=[true | false]
Creates tickets with no address bindings.

We already support forwardable, proxiable, and noaddresses options under
[libdefaults].

Post by Neng Xue
renewable=[true | false]
Creates a TGT that can be renewed (prior to the ticket expiration time).

We support a renew_lifetime option under [libdefaults]. I don't know
what it would mean to request a renewable ticket without a specific
renewable lifetime.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Neng Xue]

Hi Greg,

Thanks for the comments!

Post by Greg Hudson

Post by Neng Xue
I am Neng Xue who works in Oracle Solaris Security group. Recently when
I was working on a kerberos related project I noticed that Solaris
kerberos has a quite handy krb5.conf [appdefaults] parameter support for
forwardable=[true | false]
Can forward tickets to a remote server.
proxiable=[true | false]
Sets the proxiable flag in all tickets.
no_addresses=[true | false]
Creates tickets with no address bindings.

We already support forwardable, proxiable, and noaddresses options under
[libdefaults].

Yes, but we still think this per application parameter support might be
useful in some cases. If we can provide the implementation, do you think
MIT kerberos team will accept the pull request?

Post by Greg Hudson

Post by Neng Xue
renewable=[true | false]
Creates a TGT that can be renewed (prior to the ticket expiration time).

We support a renew_lifetime option under [libdefaults]. I don't know
what it would mean to request a renewable ticket without a specific
renewable lifetime.

As far as I can tell from Solaris kerberos, if there is no renewable
lifetime specified from kinit command line. It will then take the
maximum renewable lifetime (7 days by default).
Best

[Jeffrey Altman]

Post by Neng Xue
As far as I can tell from Solaris kerberos, if there is no renewable
lifetime specified from kinit command line. It will then take the
maximum renewable lifetime (7 days by default).

From a usability and configuration perspective if the krb5.conf does not
specify [libdefault] ticket and renew lifetimes,then the client library
should not impose a limit and should request the maximum value. The
ticket lifetime and the renew lifetime should be selected by the KDC
based upon the configured parameters for the client principal, krbtgt
principal or other service principal.

Jeffrey Altman

[Nico Williams]

Post by Jeffrey Altman

Post by Neng Xue
As far as I can tell from Solaris kerberos, if there is no renewable
lifetime specified from kinit command line. It will then take the
maximum renewable lifetime (7 days by default).

From a usability and configuration perspective if the krb5.conf does not
specify [libdefault] ticket and renew lifetimes,then the client library
should not impose a limit and should request the maximum value. The
ticket lifetime and the renew lifetime should be selected by the KDC
based upon the configured parameters for the client principal, krbtgt
principal or other service principal.

+1
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev