Kerberos KRB_AP_REQ message - Server name verification required ?

[Simo Sorce]

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 at 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