Is "SPN advertisement" or well-known SPNs a security hole?
Jeffrey Altman
jaltman at secure-endpoints.com
Mon Jan 14 20:36:13 EST 2008
Srinivas Kakde wrote:
>
> Jeffrey Altman wrote:
>> The security of the authentication is based upon the name. By asking
>> you to authenticate to a name selected by the attacker, you can be
>> tricked into using a KDC that is in fact under the control of the
>> attacker.
>
>
> Are you sure this is right? I think in Kerberos, knowledge of a
> shared secret (not knowledge of the principal name) is the foundation
> for trust? In the case of a AS-REQ/AS-REP exchange, what would the malicious KDC
> use to encrypt the EncKDCRepPart of the KDC-REP such that the decrypted
> nonce would match what the client supplied in the KDC-REQ?
Knowledge of a shared secret is how you prove the identity but the
shared secret comes from a third party and which secret the third party
is going to give you depends upon the name that you request.
For example, if you are trying to authenticate to the ftp server at
ftp.secure-endpoints.com you should be asking for the shared secret for
host/ftp.secure-endpoints.com at SECURE-ENDPOINTS.COM. But what if you
didn't ask for that but instead waited for the server to give you a
name. Let's say that there is a user "john" who has a personal machine
keyed by the SECURE-ENDPOINTS.COM realm and he is able to get you to
connect to his machine by spoofing DNS or some other means. You have
now connected to johns-machine.secure-endpoints.com but think you are
connected to ftp.secure-endpoints.com and john tells you to authenticate
to "host/johns-machine.secure-endpoints.com at SECURE-ENDPOINTS.COM". This
authentication is going to succeed but you are not connected to the host
you wanted to connect to.
There are other scenarios as well. Since the realm you contact is
determined by the domain name of the host, if the server tells you to
authenticate to ftp.compromised.com, the attacker can convince you to
authenticate using a compromised KDC that might be accessible via a
cross-realm relationship.
Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080114/c81fb1fd/attachment.bin
More information about the Kerberos
mailing list