Is "SPN advertisement" or well-known SPNs a security hole?

[Jeffrey Altman]

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