K5Wiki - User contributions [en]

Projects/KDC TGS Policy plugin

2017-05-01T17:14:22Z

Mrogers:

{{project-early}}

This project implements a plugin interface for the KDC to enable modification of service ticket attributes based on the Pre-authentication indicator.

==Problem==

As an administrator I would like to be able to define the lifetime or other attributes of a service ticket based on the strength of the pre-authentication used. We have high value services that require 2FA and as an added precaution we want to ensure that these service tickets have a shorter lifetime/renew time.

For example, it would be possible to configure:
* Client obtains a TGT using a password, sends TGS_REQ for service fileserver@REALM; returned ticket has a 8 hour lifetime
* Client obtains a TGT with PKINIT, sends TGS_REQ for service fileserver@REALM; returned ticket has a 2 hour lifetime

==Design==

A new plugin interface is defined with methods that are called during process_tgs_req(). These methods will take the auth indicators (from get_auth_indicators()) and the server db entry as inputs, and output the module-suggested value for an element of the policy (lifetime/renew-time/skey etype) that goes into creating the resulting ticket.

One design option is to convert the current behavior to be a built-in module that runs in addition to custom modules.
Currently, the ticket times are determined by kdc_get_ticket_endtime() and kdc_get_ticket_renewtime(), using options from the realm profile, request, and db entries. The session key encryption type is determined by select_session_keytype(), called by gen_session_key(). This is shared by the AS req code. The keytype is computed based on the request and what the KDC and KDB can support.

Another option is to leave the current functions alone, and have the plugin method(s) run separately afterwards, replacing the function provided values with the module provided ones. This might be less code and less complexity than option A, allowing for a single method without requiring that the plugin framework runs multiple modules.

==Open questions==

* If multiple modules are supported and each output their desired policy values, how do we decide which to use?
** For lifetime/renew time; If the plugins should only allow a time less than the built-in time, then use the shortest time from all modules?
** For session key type; Custom module overrides built-in?
* Is there anything else in the TGS policy that should be influenced by the AI and included in the interface?

Projects/KDC TGS Policy plugin

2017-04-24T22:09:01Z

Mrogers: Created page with "{{project-early}} This project implements a plugin interface for the KDC to enable modifying server ticket attributes based on the Pre-authentication indicator. ==Problem== ..."

{{project-early}}

This project implements a plugin interface for the KDC to enable modifying server ticket attributes based on the Pre-authentication indicator.

==Problem==

As an administrator I would like to be able to define the lifetime or other attributes of a service ticket based on the strength of the pre-authentication used. We have high value services that require 2FA and as an added precaution we want to ensure that these service tickets have a shorter lifetime/renew time, or a stronger session key type than the standard Kerberos ticket policy.

For example:
* User A got TGT with password authentication, asks for a TGS for service fileserver@REALM; returned ticket has a 30 minute lifetime
* User B got TGT with 2FA authentication, asks for a TGS for service fileserver@REALM; returned ticket has a 2 hour lifetime
* User C got TGT with PKINIT, asks for a TGS for service fileserver@REALM; returned ticket has a 8 hour lifetime

==Design==

A plugin interface used during process_tgs_req(), separately from the KDB check_policy_tgs, that will accept an indicator and server entry and output a ticket lifetime (renew time?) and/or session key etype. The resulting ticket lifetime can be no longer than the entry max_life (or header ticket lifetime) and the etype can be no weaker than the normally allowed etype.

==Open questions and Misc==
- http://mailman.mit.edu/pipermail/krbdev/2016-September/012664.html

Projects/KDC Discovery

2016-10-25T15:10:11Z

Mrogers:

{{project-rel|1.15}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following URI records:
* _kerberos-adm.REALM (Admin service)
* _krb5kdc.REALM (KDC)
* _kpasswd.REALM (Password service)

The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons.

* krb5srv:[flags]:transport:host[:port][/path]

The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.

The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.

The transport field indicates the transport type for the given host address. It can be either "tcp", "udp", or "kkdcp" for MS-KKDCP.

The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port extension. A host for the MS-KKDCP transport type uses a https:// URL, and can include a port and/or path extension.

Discovery using this new method should be attempted before searching SRV records.

==Examples==

* _krb5kdc IN URI 10 1 <nowiki>"krb5srv:M:kkdcp:https://kdc.example.com/path"</nowiki>
* _krb5kdc IN URI 20 1 <nowiki>"krb5srv::kkdcp:https://kdc2.example.com"</nowiki>
* _kerberos-adm IN URI 10 1 "krb5srv::tcp:192.168.1.20:1333"

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

* KDC Discovery may fail with URI entries served by RHEL7 bind: https://bugzilla.redhat.com/show_bug.cgi?id=1388534

Projects/KDC Discovery

2016-07-12T17:13:43Z

Mrogers: /* Design */

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following URI records:
* _kerberos-adm.REALM (Admin service)
* _krb5kdc.REALM (KDC)
* _kpasswd.REALM (Password service)

The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons.

* krb5srv:[flags]:transport:host[:port][/path]

The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.

The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.

The transport field indicates the transport type for the given host address. It can be either "tcp", "udp", or "kkdcp" for MS-KKDCP.

The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port extension. A host for the MS-KKDCP transport type uses a https:// URL, and can include a port and/or path extension.

Discovery using this new method should be attempted before searching SRV records.

==Examples==

* _krb5kdc IN URI 10 1 <nowiki>"krb5srv:M:kkdcp:https://kdc.example.com/path"</nowiki>
* _krb5kdc IN URI 20 1 <nowiki>"krb5srv::kkdcp:https://kdc2.example.com"</nowiki>
* _kerberos-adm IN URI 10 1 "krb5srv::tcp:192.168.1.20:1333"

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-07-08T17:00:31Z

Mrogers:

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following URI records:
* _kerberos-adm.REALM (Admin service)
* _krb5kdc.REALM (KDC)
* _kpasswd.REALM (Password service)

The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons.

* krb5srv:[flags]:transport:host[:port][/path]

The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.

The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.

The transport field indicates the transport type for the given host address. It can be either "tcp", "udp", or "kkdcp" for MS-KKDCP.

The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port. A host for the MS-KKDCP transport type uses a https:// URL, and can include a path extension.

Discovery using this new method should be attempted before searching SRV records.

==Examples==

* _krb5kdc IN URI 10 1 <nowiki>"krb5srv:M:kkdcp:https://kdc.example.com/path"</nowiki>
* _krb5kdc IN URI 20 1 <nowiki>"krb5srv::kkdcp:https://kdc2.example.com"</nowiki>
* _kerberos-adm IN URI 10 1 "krb5srv::tcp:192.168.1.20:1333"

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-06-01T16:30:11Z

Mrogers: /* Design */

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following TXT records:
* _kerberos-adm.REALM (Admin service)
* _krb5kdc.REALM (KDC)
* _kpasswd.REALM (Password service)

An entry will contain a string of priority, weight, flags, transport, and target (containing optional port and path) fields, separated by colons.

* priority:weight:[flags]:transport:host[:port][/path]

Priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.

The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.

The transport field indicates the transport type for the given host address. It can be either "tcp", "udp", or "kkdcp" for MS-KKDCP.

The host field can be an IPv4 or bracket-enclosed IPv6 address (k5_parse_host_string(), part of PR#380 will help with this). A host for the MS-KKDCP transport type uses a https:// address with an optional port and path.

Discovery using this new method should be attempted before searching SRV records.

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-06-01T14:44:02Z

Mrogers:

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following TXT records:
* _kerberos-adm.REALM (Admin service)
* _krb5kdc.REALM (KDC)
* _kpasswd.REALM (Password service)

An entry will contain a URI formatted string of priority, weight, flags, transport, and target (containing optional port and path), separated by colons. The host field can be an IPv4 or bracket-enclosed IPv6 address (k5_parse_host_string(), part of PR#380 will help with this). The MS-KKDCP transport type uses a http/https host address target with an optional port and path.

* priority:weight:[flags]:udp:host[:port]
* priority:weight:[flags]:tcp:host[:port]
* priority:weight:[flags]:tls:host[:port]
* priority:weight:[flags]:kkdcp:<nowiki>http://host</nowiki>[:port][/path]
* priority:weight:[flags]:kkdcp:<nowiki>https://host</nowiki>[:port][/path]

The flags field contains zero or more flag characters, and is ignored for admin and password service lookups. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.

Priority is the lowest number first. Weight will not be used for now. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.

Discovery using this new method should be attempted before searching SRV records.

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-05-31T20:10:45Z

Mrogers: /* Design */

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following TXT records:
* _kerberos-adm.REALM (Admin service)
* _kerberos.REALM (KDC)
* _kpasswd.REALM (Password service)

An entry will contain a URI formatted string of priority, weight, flags, transport, target, and optional port, separated by colons. The MS-KKDCP transport type uses a http/https host address target with an optional port and path.

* priority:weight:flags:udp:host[:port]
* priority:weight:flags:tcp:host[:port]
* priority:weight:flags:tls:host[:port]
* priority:weight:flags:kkdcp:<nowiki>http://host</nowiki>[:port][/path]
* priority:weight:flags:kkdcp:<nowiki>https://host</nowiki>[:port][/path]

The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is a master server.

Discovery using this new method should be attempted before searching SRV records.

The host field can be an IPv4 or IPv6 address (k5_parse_host_string(), part of PR#380 will help with this)

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-05-27T18:01:51Z

Mrogers:

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use

==Design==

The client performs a DNS lookup for one or more of the following TXT records:
* _kerberos-master.REALM (Master KDC)
* _kerberos-adm.REALM (Admin service)
* _kerberos.REALM (Normal KDC)
* _kpasswd.REALM (Password service)

An entry will contain a URI formatted string of priority, weight, transport, target, and optional port, separated by colons. The MS-KKDCP transport type uses a http/https host address target with an optional port and path.

* priority:weight:udp:host[:port]
* priority:weight:tcp:host[:port]
* priority:weight:tls:host[:port]
* priority:weight:kkdcp:<nowiki>http://host</nowiki>[:port][/path]
* priority:weight:kkdcp:<nowiki>https://host</nowiki>[:port][/path]

Discovery using this new method should be attempted before searching SRV records.

(Password service discovery)

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-05-27T18:00:31Z

Mrogers: /* Design */

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use
* Does not assist in locating password services

==Design==

The client performs a DNS lookup for one or more of the following TXT records:
* _kerberos-master.REALM (Master KDC)
* _kerberos-adm.REALM (Admin service)
* _kerberos.REALM (Normal KDC)
* _kpasswd.REALM (Password service)
* _krb524.REALM (K5 to K4 service)

An entry will contain a URI formatted string of priority, weight, transport, target, and optional port, separated by colons. The MS-KKDCP transport type uses a http/https host address target with an optional port and path.

* priority:weight:udp:host[:port]
* priority:weight:tcp:host[:port]
* priority:weight:tls:host[:port]
* priority:weight:kkdcp:<nowiki>http://host</nowiki>[:port][/path]
* priority:weight:kkdcp:<nowiki>https://host</nowiki>[:port][/path]

Discovery using this new method should be attempted before searching SRV records.

(Password service discovery)

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html

Projects/KDC Discovery

2016-05-27T15:58:31Z

Mrogers: Created page with "{{project-target|1.15}} {{project-early}} This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02..."

{{project-target|1.15}}
{{project-early}}

This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type, however it was decided that a TXT record will be used with a (currently non-standardized) URI payload format.

The current method of KDC discovery using DNS SRV records has the following drawbacks:

* Only UDP and TCP protocols can be specified
* Multiple queries are needed to discover both protocol records
* The DNS administrator has no influence on client protocol use
* Does not assist in locating password services

==Design==

The client performs a single DNS lookup for the _kerberos.REALM TXT record containing priority, weight, transport, target, and optional port, separated by colons. The MS-KKDCP transport type uses a http/https host address target with an optional port and path.

* priority:weight:udp:host[:port]
* priority:weight:tcp:host[:port]
* priority:weight:tls:host[:port]
* priority:weight:kkdcp:<nowiki>http://host</nowiki>[:port][/path]
* priority:weight:kkdcp:<nowiki>https://host</nowiki>[:port][/path]

Discovery using this new method should be attempted before searching SRV records.

(Password service discovery)

==Implementation==

src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format.

==Resources==

* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html