K5Wiki - User contributions [en]

Projects/Realm Crossover between KDCs

2018-02-14T11:08:36Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page. The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service (for school children).

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KXOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Our proposal for a TLS-KDH cipher suite, combining Kerberos authentication with ECDHE key agreement already withstands Quantum Computer attacks. It is an interesting pair with KXOVER, as the two allow Kerberos for many protocols across the Internet.

KXOVER can utterly destroy the resistence to Quantum Computing for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T11:06:07Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page. The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service (for school children).

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KXOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T11:05:06Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KXOVER''' as a name for the Kerberos Realm Crossover protocol proposed on this page. The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KXOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T11:04:07Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page. The Dutch may pronounce KXOVER als [https://commons.wikimedia.org/w/index.php?search=klaarover&title=Special:Search&go=Go&searchToken=bqm1p8pg5lgu1pqzrf7cbbqur klaar-over], after the street-crossing public service, especially around schools and near opening and closing times of these schools.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T11:02:40Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page. The Dutch may pronounce KXOVER als "Klaar-Over".

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T11:00:55Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [https://en.wikipedia.org/wiki/Grover%27s_algorithm Grover's algorithm] — but at least [https://en.wikipedia.org/wiki/Shor%27s_algorithm Shor's algorithm], which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T10:58:17Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) — but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted. But given that such trust does not usually come overnight in crypto, it is still a good idea to work on the gathering of entropy.

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T10:57:22Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) — but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

In addition to these defenses, it is a good idea to incorporate a key exchange algorithm that withstands Quantum Computing as soon as it can be trusted.

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-14T10:56:29Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge. We do need to make our twice twice as long as the customary 128 bit on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) — but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which is devastating for public key crypto, has no grip on it.

Using KXOVER can utterly destroy these advantages for any traffic between a different client realm and server realm. This problem is the same as what HTTPS and co have to face, but again Kerberos holds better cards, mostly because KXOVER is run between servers in a mutual relationship, rather than between a client and a server.

In practice, we might assume that passive observers cannot scan all traffic that passes between all systems. Based on this, if we can get only piece of salt across without it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. There are so many fresh keys floating around in any Kerberos system that we have a lot of material of good entropy staring at us. Using this cleverly to build up entropy for a fresh exchange may be useful, especially when manual keying is at the foundation of at least one of the entropy sources.

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-10T21:51:30Z

Vanrein: /* Beyond Quantum Computing */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that its key exchange infrastructure will hold up against quantum computers according to our current knowledge, as long as we double key sizes on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) — but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) has not grip on it.

Using KXOVER cat utterly destroy these advantages for any traffic between a differnet client realm and server realm. This problem cannot be fixed in general.

In practice though, it may be assumed that passive observers don't scan all traffic that passes between systems, and as a result, if we can get only piece of salt across withoug it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. This is easy because the parties involved in the exchange are interested in encryption, and would fend off anything immature or unstable.

The tickets provided to clients all hold an (encrypted) encryption key, which is KDC_geenrated and unique to the session at hand. It would be interesting to see cryptographer's response to reoccur, whether or not it i s ncidered useful :-)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2018-02-10T21:49:23Z

Vanrein: edits to sharpen the oproject describtion and poject status.

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Beyond Quantum Computing==

Kerberos has an important advantage over public-key schemes, namely that it will hold up against quantum computers according to our current knowledge, as long as we double key sizes on account of [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) — but at least [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) has not grip on it.

Using KXOVER cat utterly destroy these advantages for any traffic between a differnet client realm and server realm. This problem cannot be fixed in general.

In practice though, it may be assumed that passive observers don't scan all traffic that passes between systems, and as a result, if we can get only piece of salt across withoug it being stored, we can base our next key agreement on that, rather than just on the ECDH primitives. This is easy because the parties involved in the exchange are interested in encryption, and would fend off anything immature or unstable.

The tickets provided to clients all hold an (encrypted) encryption key, which is KDC_geenrated and unique to the session at hand. It would be interesting to see cryptographer's response to reoccur, whether or not it i s ncidered useful :-)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T15:17:11Z

Vanrein: /* Changes to Kerberos */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 19] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T09:20:16Z

Vanrein: /* Changes to Kerberos */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 18] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 17] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T08:28:05Z

Vanrein: /* Changes to Kerberos */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 17] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, the free tags being 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T08:27:41Z

Vanrein: /* Changes to Kerberos */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 17] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos, namely 17, 18, 19, 23, 24.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T08:26:33Z

Vanrein: /* Changes to Kerberos */

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION 17] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION 18] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework. (The tags were found free after looking for them in all RFCs that mention Kerberos.)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-03-08T08:13:03Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

We learnt that the AS-REP is unsuitable for communication between KDC's, and propose to use [APPLICATION XX] for it. To properly mirror the situation, as well as to get a better message routing to the backend, we propose to use [APPLICATION XX] for a message that replaces the AS-REQ between KDCs. These new messages also help us to be more to the point in the protocol specification than we could be within the PKINIT framework.

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-01-19T16:14:55Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a (KRB5_PRIV or local & unencrypted) message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/Realm Crossover between KDCs

2016-01-19T15:54:29Z

Vanrein:

''Realm Crossover is the ability to connect Kerberos realms under potentially different operational control. Although Kerberos supports mechanisms for connecting realms, this is based on manual key exchange in advance. We use the term Realm Crossover here to indicate an automated process that can incorporate any remote party on the Internet. The mechanism uses DNSSEC and DANE to secure a PKINIT process between KDCs that intend to collaborate; there is no need to change client code.''

{{project-early}}

External project links:
* [http://realm-xover.arpa2.net/kerberos.html Project working pages]
* [http://lists.arpa2.org/mailman/listinfo/realm-xover Project mailing list]

We use '''KREALM-XOVER''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

# A client requests a sevice from its local KDC
# The local KDC finds that it does not define the requested service
# The local KDC creates a KRB5_PRIV message with the TGS_REQ from the client and sends it to the local KXOVER deamon.
# The KXOVER deamon extracts the server name from the request, and looks in DNS.
# Demanding DNSSEC for security, the local KXOVER daemon extracts a [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 _kerberos TXT] record describing the remote realm for the server name
# If the remote realm is already known, and its key is still valid for long enough, the local KXOVER deamon returns the referral TGT to the client directly (or through the KDC)
# Demanding DNSSEC for security, the local KXOVER deamon extracts an SRV record describing the address and port of the remote KDC
# Demanding DNSSEC for security, the local KXOVER deamon extracts the TLSA records for the remote KDC
# The local KXOVER daemon initiates a PKINIT exchange with the remote KDC (using its own server certificate for PKINIT)
# The local KXOVER daemon validates the remote KDC through the TLSA record representing the remote KDC's PKINIT certificate
# The remote KDC receives the PKINIT request with a server certificate; the PKINIT received by the remote KDC contains the PA-KXOVER in its PA-DATA
# The remote KDC sends the PKINIT request to the remote KXOVER deamon
# The remote KXOVER deamon validates the local KDC's certificate through DNSSEC and SRV/TLSA records
# The local and remote KXOVER deamons agree on a symmetric key using Elliptic Curve Diffie-Hellman cryptography; they also agree on a timeout for this key and store it for that period of time
# The local KXOVER deamon returns a ticket referral to the client (directly or through the KDC) so a TGT for the remote realm; this ticket is not valid beyond the remote KDC's agreed key validity.
# The client understands the ticket referral as a hint to contact the remote realm
# The client looks up the SRV record for the remote KDC
# The client assumes that the KDC has established security, and therefore does not have to enforce DNSSEC validation
# The client requests a TGS from the remote KDC, using the remote realm name obtained from the ticket referral

The KDC code has to be modified in order to allow the redirection of cross-over requests to the KXOVER deamon, and if responses are passed back through the KDC, relay those back to the user.

The KDC admin must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process.
The KDC admin has to create a principal for the deamon in the database in order to allow secure communication between the KDC and the deamon.

Note that the above process is not symmetric; the local KDC contains a client and the remote KDC contains a service. The key exchanges is only setup for that direction; the opposite will often be supported as well, but would require a separate key exchange process.

The one thing the '''client''' must permit, is accept ticket referrals. This means that it should flag being open to those through the canonicalize(15) KDCOption flag. This is not new. -- ''but is it available in practice?''

The '''KDC code''' must implement the new flow, including strict reliance on DNSSEC without opt-out. See [http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec Insisting on DNSSEC] and [https://unbound.net/pipermail/unbound-users/2014-January/003113.html discussion].

The '''KDC admin''' must publish the KDC's server-side PKINIT certificate in a TLSA record before enabling this process in the '''KDC configuration''' settings.

==Policy Choices for this Mechanism==

* The client makes a policy decision to support ticket referral through the canonicalize(15) KDCOption.
* The KDC may require X.509 PKI infrastructure on the Kerberos certificate (for instance, to enforce a federation).
* Any KDC may support client remote operation, and connect to remote realms on behalf of a local client.
* Any KDC may support service remote operation, and welcome remote clients to connect to reach a local service.

==Changes to Kerberos==

KDCs must support the above procedure. They must accept servers accessing the PKINIT procedure.

Clients must send the canonicalize(15) KDCOption; which do that and which don't?

For AD/DC, a solution may be constructed with a trust relationship to an open source KDC and pointing to it with [https://technet.microsoft.com/en-us/library/cc784334(v=ws.10).aspx Name Suffix Routing] and using wildcard realm names. (Perhaps * or otherwise *.com, *.org, ...)

==Comparison to Other Work==

The current Kerberos infrastructure permits KDCs to link to one another, as well as assigning a KDC as a "certificate authority". The first construct provides a manually-secured method for ad-hoc links, the second permits larger structures such as federations to form. Neither is suitable for binding together KDCs that have not been in contact before, and are therefore unsuitable to create a Kerberos facility that spans the Internet at large. The fact that the method proposed here could not be formulated before has been the lack of a reliable, as in secure, DNS infrastructure. With the advent of DNSSEC, this is now very well possible.

Another proposal named PKCROSS exists to use the PKINIT exchange across realms, where a client uses an X.509 certificate to access a remote realm. This X.509 certificate would have been previously obtained from a local realm, using the kx509 mechanism. This approach therefore moves back and forth between X.509 and Kerberos, possibly more than once. It relies on modifications in client code.

==Related Projects==

We propose KREALM-XOVER as a mechanism underneath TLS-KDH. Using this combination, it would be possible to have interactions with web, mail, and many other services that are protected by Kerberos at the transport layer, so without interference from the application layer (the layer that includes JavaScript, and so, adverse advertisements).

==Specifications==

* [https://tools.ietf.org/html/rfc6806 RFC 6806] defines cross-realm referral tickets
* [http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 draft-vanrein-dnstxt-krb1] describes the KREALM record in DNS
* [https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross draft-williams-kitten-krb5-pkcross] describes the PKCROSS alternative

Projects/KREALM

2015-09-15T14:07:14Z

Vanrein: /* Past Controversy */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server or domain that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client that finds realms through KREALM records may treat them as overrides for anything else it would otherwise try -- when it finds KREALM records, that is
* The client that looks for KREALM records may (at some point in the future) decide to discard other methods, perhaps exempting the the client's login realm
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing] suggestions
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on all client networks)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T14:02:54Z

Vanrein: /* Policy Choices for this Mechanism */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client that finds realms through KREALM records may treat them as overrides for anything else it would otherwise try -- when it finds KREALM records, that is
* The client that looks for KREALM records may (at some point in the future) decide to discard other methods, perhaps exempting the the client's login realm
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing] suggestions
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on all client networks)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:50:54Z

Vanrein: /* Changes to Kerberos */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing] suggestions
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on all client networks)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:43:41Z

Vanrein: /* Policy Choices for this Mechanism */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing] suggestions
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:43:13Z

Vanrein: /* Policy Choices for this Mechanism */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and [https://tools.ietf.org/html/rfc6806#section-9 Cross-Realm Routing suggestions]
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:40:16Z

Vanrein: /* Policy Choices for this Mechanism */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The client, if it doesn't process KREALM records itself, may delegate to the KDC by accepting canonicalisation and Server Referrals
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:38:58Z

Vanrein: /* Mechanics of the Project */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the realm name
# When multiple KREALM records exist, then each suggests an alternative realm name to try

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:37:26Z

Vanrein: /* Changes to DNS */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records
* Until they do, [https://tools.ietf.org/html/rfc3597 Handling of Unknown DNS RRtypes] can be used

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:35:56Z

Vanrein: /* Past Controversy */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

These points kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:35:10Z

Vanrein: /* Changes to Kerberos */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

This point kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which may not be completely reliable on every network)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T08:20:28Z

Vanrein: /* Past Controversy */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

This point kept coming up, and so we have decided to not iterate upward along the DNS hierarchy at all. Every server that wants to specify a Kerberos realm should set it up alongside the servername.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T07:25:06Z

Vanrein: /* Mechanics of the Project */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points. Having said that, a client that loads its own libunbound or other secure resolver may still succeed on most networks.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

This has now been overcome by specifying a secure manner of upward iteration through the DNS hierarchy. When no KREALM record is found, then before iterating in upward direction, a test is made whether a SOA record exists at that point. This can be efficienty seen by looking at the NSEC/NSEC3 secure denial for the KREALM query, which holds a type bit map.

By not allowing the upward iteration to move beyond the zone apex for the zone holding the originally sought DNS name, we can assume that there is no change of operational control for the zone. There is a bit of impact administratively, when multiple DNS zones are covered by one Kerberos realm; all covered zones must then publish their own KREALM records.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-15T07:24:08Z

Vanrein: /* Mechanics of the Project */

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response or denial through DNSSEC.
# '''We dropped the following, as we couldn't agree on it:''' The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

The DNS client mentioned above will usually be the KDC, which may be assumed to be setup to validate DNSSEC properly. For clients, this is less likely, less reliable and may fail in various contexts due to mediocre DNS infrastructure at end points.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

This has now been overcome by specifying a secure manner of upward iteration through the DNS hierarchy. When no KREALM record is found, then before iterating in upward direction, a test is made whether a SOA record exists at that point. This can be efficienty seen by looking at the NSEC/NSEC3 secure denial for the KREALM query, which holds a type bit map.

By not allowing the upward iteration to move beyond the zone apex for the zone holding the originally sought DNS name, we can assume that there is no change of operational control for the zone. There is a bit of impact administratively, when multiple DNS zones are covered by one Kerberos realm; all covered zones must then publish their own KREALM records.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/Realm Crossover between KDCs

2015-09-11T10:08:51Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-11T10:08:26Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:52:58Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:51:38Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:50:49Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:49:42Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:48:54Z

Vanrein: /* Mechanics of the Project */

Projects/Realm Crossover between KDCs

2015-09-03T17:47:47Z

Vanrein: /* Mechanics of the Project */

Projects/KREALM

2015-09-03T15:02:03Z

Vanrein: Resolved past controversy with different mechanism (iteration, but being clever about SOA records)

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response through DNSSEC.
# The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

This has now been overcome by specifying a secure manner of upward iteration through the DNS hierarchy. When no KREALM record is found, then before iterating in upward direction, a test is made whether a SOA record exists at that point. This can be efficienty seen by looking at the NSEC/NSEC3 secure denial for the KREALM query, which holds a type bit map.

By not allowing the upward iteration to move beyond the zone apex for the zone holding the originally sought DNS name, we can assume that there is no change of operational control for the zone. There is a bit of impact administratively, when multiple DNS zones are covered by one Kerberos realm; all covered zones must then publish their own KREALM records.

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Projects/KREALM

2015-09-03T12:17:07Z

Vanrein: New page: ''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables s...

''This project introduces Kerberos description records in DNS. At present, there is no formally acceptable manner of deducing a realm name from a server name. The KREALM record enables such translations, and possibly more. The record's security hinges on DNSSEC.''

{{project-early}}

External project links:
* [https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1 Specification]

We use '''KREALM''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

Actors: The Kerberos actor wanting to establish the realm name for a given server name is called the DNS client. The server name is supported by a DNS zone run in a DNS server.

# The DNS client requests the KREALM record for the sought server name, or otherwise a denial by the DNS server.
# The DNS client validates the response through DNSSEC.
# The DNS client may retry at a default location (usually the apex of the DNS zone) based on the location for a DNSKEY signing a denial.
# The DNS client will validate any such default location to be the same or a higher-up name in the DNS hierarchy.
# The DNS client interprets the KREALM record to find the r=REALMNAME record

It should be pointed out that rogue intermediates might add RRSIG records of their own, pointing to parts outside the DNS hierarchy for the requested server name. This should be detected and ignored.

==Past Controversy==

The default location has been subject of some controversy. This was because:

* The DNS does not formally define where a zone apex lies;
* Iterating upward may land up in a DNS zone under different operational control;
* Iterating upward is not an efficient use of the DNS.

The solution is probably to not specify the zone apex as the fallback location, but the same location as where the DNSKEY records are. In both cases, the RRSIG record(s) provide the location without iteration. The choice for the same location as the DNSKEY for fallback is that
* It centralises spread-out parts of a zone into one place
* It is part of the same DNS zone
* The party controlling the DNSKEY records already has the ability to sabotage the KREALM setup, so no new dangers are introduced
* The party controlling the DNSKEY must also co-operate for KREALM records at the server name, doing that centrally for the zone is not different
* It can be verified to match the server name or lie upward from it

==Policy Choices for this Mechanism==

* The KDC may or may not want to find realms through KREALM records
* The client, provided that it can process DNSSEC, may want to find realms through KREALM records
* The server administrator may or may not choose to publish the realm, and possibly more, for the service and/or the realm

==Changes to Kerberos==

* The KDC may process KREALM records, and for that purpose, rely on DNSSEC
* The Kerberos client might process KREALM records, and for that purpose, require DNSSEC to be operational (which is not a solid thing to build on)

==Changes to DNS==

* DNS servers would need to support KREALM records, as they do any other records

==Comparison to Other Work==

None.

==Related Projects==

See KREALM-XOVER.

==Specifications==

None.

Project/TLS-KDH

2015-09-03T11:47:05Z

Vanrein:

Project/TLS-KDH

2015-09-03T11:43:10Z

Vanrein: Removing all content from page

Projects/TLS-KDH

2015-09-03T11:42:48Z

Vanrein: New page: ''This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.'' {{project-early}} External project links: * [http://tls-kdh.arpa2.net/tls-kdh.html Project working ...

''This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.''

{{project-early}}

External project links:
* [http://tls-kdh.arpa2.net/tls-kdh.html Project working pages]
* [http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html Specification]
* [http://lists.arpa2.org/mailman/listinfo/tls-kdh Discussion list]

We use '''TLS-KDH''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

The TLS-KDH CipherSuite is a special way of using TLS:

# The TLS client offers TLS-KDH CipherSuites in its ClientHello
# The TLS server selects a TLS-KDH CipherSuite in its ServerHello
# The TLS server sends no ServerCertificate
# The TLS server sends a ServerKeyExchange with a suitable Diffie-Hellman public key
# The TLS server may send a CertificateRequest to request a client identity (which the client may still refuse to supply)
# The TLS client chooses whether it will release its identity, or remain anonymous
# The TLS client looks for a service ticket in its local Kerberos infrastructure
# The TLS client sends a ClientKeyExchange holding a service ticket and a Diffie-Hellman public key response, encrypted to that ticket
# The TLS server accepts the service ticket and uses it to decrypt the Diffie-Hellman response
# Both now construct the shared secret, following normal Diffie-Hellman procedures for TLS
# Both now construct a proof of knowing the secret, thereby authentication to the other side
# Both now validate the other side before proceeding

==Policy Choices for this Mechanism==

* The server may or may not be equiped with a service ticket; this may depend on the server name
* The client may be willing to obtain a service ticket for all, some or no remote servers
* The client may be willing to provide its identity to all, some or no remote servers
* The KDC may be willing to provide service tickets for remote realms

==Changes to Kerberos==

* None. Although independent work on [Realm Crossover in the KDC] is bound to be useful.

==Changes to TLS==

* The changes to TLS do not disturb older TLS implementations
* The TLS-KDH CipherSuites require TLS version 1.2 or later
* Both TLS clients and servers must be extended to support the TLS-KDH CipherSuites

We expect to offer early support to [http://www.gnutls.org GnuTLS] soon. The [http://tlspool.arpa2.net TLS Pool] will also support TLS-KDH.

==Comparison to Other Work==

See [http://tls-kdh.arpa2.net/related.html http://tls-kdh.arpa2.net/related.html]

==Related Projects==

See KREALM-XOVER.

==Specifications==

* [https://tools.ietf.org/html/rfc6112 RFC 6112] defines anonymous client tickets

Project/TLS-KDH

2015-09-03T11:39:08Z

Vanrein:

Project/TLS-KDH

2015-09-03T11:38:04Z

''This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.''

{{project-early}}

External project links:
* [http://tls-kdh.arpa2.net/tls-kdh.html Project working pages]
* [http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html Specification]

We use '''TLS-KDH''' as a name for the protocol proposed on this page.

==Mechanics of the Project==

The TLS-KDH CipherSuite is a special way of using TLS:

# The TLS client offers TLS-KDH CipherSuites in its ClientHello
# The TLS server selects a TLS-KDH CipherSuite in its ServerHello
# The TLS server sends no ServerCertificate
# The TLS server sends a ServerKeyExchange with a suitable Diffie-Hellman public key
# The TLS server may send a CertificateRequest to request a client identity (which the client may still refuse to supply)
# The TLS client chooses whether it will release its identity, or remain anonymous
# The TLS client looks for a service ticket in its local Kerberos infrastructure
# The TLS client sends a ClientKeyExchange holding a service ticket and a Diffie-Hellman public key response, encrypted to that ticket
# The TLS server accepts the service ticket and uses it to decrypt the Diffie-Hellman response
# Both now construct the shared secret, following normal Diffie-Hellman procedures for TLS
# Both now construct a proof of knowing the secret, thereby authentication to the other side
# Both now validate the other side before proceeding

==Policy Choices for this Mechanism==

* The server may or may not be equiped with a service ticket; this may depend on the server name
* The client may be willing to obtain a service ticket for all, some or no remote servers
* The client may be willing to provide its identity to all, some or no remote servers
* The KDC may be willing to provide service tickets for remote realms

==Changes to Kerberos==

* None. Although independent work on [Realm Crossover in the KDC] is bound to be useful.

==Changes to TLS==

* The changes to TLS do not disturb older TLS implementations
* The TLS-KDH CipherSuites require TLS version 1.2 or later
* Both TLS clients and servers must be extended to support the TLS-KDH CipherSuites

We expect to offer early support to [http://www.gnutls.org GnuTLS] soon. The [http://tlspool.arpa2.net TLS Pool] will also support TLS-KDH.

==Comparison to Other Work==

See [http://tls-kdh.arpa2.net/related.html http://tls-kdh.arpa2.net/related.html]

==Related Projects==

See KREALM-XOVER.

==Specifications==

* [https://tools.ietf.org/html/rfc6112 RFC 6112] defines anonymous client tickets

Projects/Realm Crossover between KDCs

2015-09-03T08:46:41Z

Vanrein: /* Changes to Kerberos */

Projects/Realm Crossover between KDCs

2015-09-03T07:44:00Z

Vanrein:

Projects/Realm Crossover between KDCs

2015-09-03T07:42:41Z

Vanrein: /* Internet Drafts */