Hi,

Suppose there are two servers A and B running under different kerberos
service principals.
If both the service principals have same password and kvno then kerberos
long term encryption key will be same for both. Seems to be the case for windows KDC.

In such case, a client having service ticket for A tries to authenticate
with that ticket with server B, should it work ? It is working fine in JDK implementation.

https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear
whether server should validate server principal in the service ticket when KRB_AP_REQ message is received. Looks like just decryption with key is sufficient along with some other validations but i don't find server name validation explicitly mentioned.
--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:

Hi,

Suppose there are two servers A and B running under different kerberos service principals.
If both the service principals have same password and kvno then kerberos
long term encryption key will be same for both. Seems to be the case for windows KDC.

In such case, a client having service ticket for A tries to authenticate
with that ticket with server B, should it work ? It is working fine in JDK implementation.

https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear
whether server should validate server principal in the service ticket when KRB_AP_REQ message is received. Looks like just decryption with key is sufficient along with some other validations but i don't find server name validation explicitly mentioned.

I note that RFC 1510 has been obsoleted by RFC 4120 (but https://tools.ietf.org/html/rfc4120#section-3.2.3 contains essentially the
same text that you reference).

My understanding is that the RFC authors assumed that different services
would have different keys, so the scenario you describe would not occur (though, as you know, the situation does occur quite often in Active
Directory environments). Since the Ticket sname is in the unencrypted part
of the ticket, there is no value in validating its contents, as the Ticket could be re-encoded with an arbitrary sname value. It is, in essence, just
a hint for locating the proper key, in the same that the realm is (and the realm is explicitly discussed as serving this role in the referenced text).

-Ben

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

Got it. Even if sname is encrypted, it won't make any difference as it can
be modified and re-encrypted as the key is equal.
Signature also won't help for the same reason. So, it is clear that responsibility lies on AD admin to use unique passwords for accounts.

On Sun, Mar 21, 2021 at 10:29 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:

Hi,

Suppose there are two servers A and B running under different kerberos service principals.
If both the service principals have same password and kvno then kerberos long term encryption key will be same for both. Seems to be the case for windows KDC.

In such case, a client having service ticket for A tries to authenticate with that ticket with server B, should it work ? It is working fine in

JDK

implementation.

https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear whether server should validate server principal in the service ticket

when

KRB_AP_REQ message is received. Looks like just decryption with key is sufficient along with some other validations but i don't find server name validation explicitly mentioned.

I note that RFC 1510 has been obsoleted by RFC 4120 (but https://tools.ietf.org/html/rfc4120#section-3.2.3 contains essentially the same text that you reference).

My understanding is that the RFC authors assumed that different services would have different keys, so the scenario you describe would not occur (though, as you know, the situation does occur quite often in Active Directory environments). Since the Ticket sname is in the unencrypted part of the ticket, there is no value in validating its contents, as the Ticket could be re-encoded with an arbitrary sname value. It is, in essence, just
a hint for locating the proper key, in the same that the realm is (and the realm is explicitly discussed as serving this role in the referenced text).

-Ben

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, March 21, 2021 at 4:17:41 PM UTC-4, Vipul Mehta wrote:

Got it. Even if sname is encrypted, it won't make any difference as it can be modified and re-encrypted as the key is equal.
Signature also won't help for the same reason. So, it is clear that responsibility lies on AD admin to use unique passwords for accounts.

You are incorrect. Since every Kerberos service principal must have a unique name inside the KDC (to distinguish itself) it will therefore have a unique key as well, since that key is derived from several factors, two of which are the service principal
name "sname" and the password for the principal. This means that even if the AD admin makes the password the same on each said principal, it wouldn't matter, this is due to the concept of SALTing the sname and the password. Don't get hung up on the
passwords being made the same - as that does not technically matter - as the long term key will always be different due to the SALT process.

I need to point point out that you opened this thread by stating "If both the service principals have same password and kvno then kerberos long term encryption key will be same for both." That statement could not be more wrong. The long term key will *
always* be different.

I talk about this at length in one of my StackOverflow posts here: https://stackoverflow.com/questions/37744163/what-is-the-correct-format-to-specify-spn/40450538#40450538

-Best Regards,
Todd Heron

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: kaduk@mit.edu (Benjamin Kaduk)
Copy: kerberos@mit.edu

Note that this is true only for RC4-HMAC keys, because the RC4-HMAC key
is unsalted. AES keys are salted so two machines will have different
AES keys even if the "password" is the same.

HTH,
Simo.

On Mon, 2021-03-22 at 01:24 +0530, Vipul Mehta wrote:

Got it. Even if sname is encrypted, it won't make any difference as it can
be modified and re-encrypted as the key is equal.
Signature also won't help for the same reason. So, it is clear that responsibility lies on AD admin to use unique passwords for accounts.

On Sun, Mar 21, 2021 at 10:29 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:

Hi,

Suppose there are two servers A and B running under different kerberos service principals.
If both the service principals have same password and kvno then kerberos long term encryption key will be same for both. Seems to be the case for windows KDC.

In such case, a client having service ticket for A tries to authenticate with that ticket with server B, should it work ? It is working fine in

JDK

implementation.

https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear whether server should validate server principal in the service ticket

when

KRB_AP_REQ message is received. Looks like just decryption with key is sufficient along with some other validations but i don't find server name validation explicitly mentioned.

I note that RFC 1510 has been obsoleted by RFC 4120 (but https://tools.ietf.org/html/rfc4120#section-3.2.3 contains essentially the same text that you reference).

My understanding is that the RFC authors assumed that different services would have different keys, so the scenario you describe would not occur (though, as you know, the situation does occur quite often in Active Directory environments). Since the Ticket sname is in the unencrypted part of the ticket, there is no value in validating its contents, as the Ticket could be re-encoded with an arbitrary sname value. It is, in essence, just a hint for locating the proper key, in the same that the realm is (and the realm is explicitly discussed as serving this role in the referenced text).

-Ben

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

Thank you, I just verified it.
After enabling AES on accounts it does not work as key generated is
different.

Found the details:

For RC4-HMAC:
key = MD4(UNICODE(password))
https://tools.ietf.org/html/rfc4757#page-3

For AES:
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")
https://tools.ietf.org/html/rfc3962

salt = [realm.ToUpper()] + "host" + [samAccountNameWithoutDollarSign] + "." [realm.ToLower()] https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-KILE/%5bMS-KILE%5d.pdf

On Mon, Mar 22, 2021 at 11:13 PM Simo Sorce <simo@redhat.com> wrote:

Note that this is true only for RC4-HMAC keys, because the RC4-HMAC key
is unsalted. AES keys are salted so two machines will have different
AES keys even if the "password" is the same.

HTH,
Simo.

On Mon, 2021-03-22 at 01:24 +0530, Vipul Mehta wrote:

Got it. Even if sname is encrypted, it won't make any difference as it

can

be modified and re-encrypted as the key is equal.
Signature also won't help for the same reason. So, it is clear that responsibility lies on AD admin to use unique passwords for accounts.

On Sun, Mar 21, 2021 at 10:29 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

On Fri, Mar 19, 2021 at 11:47:49PM +0530, Vipul Mehta wrote:

Hi,

Suppose there are two servers A and B running under different

kerberos

service principals.
If both the service principals have same password and kvno then

kerberos

long term encryption key will be same for both. Seems to be the case

for

windows KDC.

In such case, a client having service ticket for A tries to

authenticate

with that ticket with server B, should it work ? It is working fine

in

JDK

implementation.

https://tools.ietf.org/html/rfc1510#page-21 : in RFC it is not clear whether server should validate server principal in the service ticket

when

KRB_AP_REQ message is received. Looks like just decryption with key

is

sufficient along with some other validations but i don't find server

name

validation explicitly mentioned.

I note that RFC 1510 has been obsoleted by RFC 4120 (but https://tools.ietf.org/html/rfc4120#section-3.2.3 contains

essentially the

same text that you reference).

My understanding is that the RFC authors assumed that different

services

would have different keys, so the scenario you describe would not occur (though, as you know, the situation does occur quite often in Active Directory environments). Since the Ticket sname is in the unencrypted

part

of the ticket, there is no value in validating its contents, as the

Ticket

could be re-encoded with an arbitrary sname value. It is, in essence,

just

a hint for locating the proper key, in the same that the realm is (and

the

realm is explicitly discussed as serving this role in the referenced

text).

-Ben

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)