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 <ka...@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
