Srinivas Kakde wrote:
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.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 decryptednonce would match what the client supplied in the KDC-REQ?
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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED]". 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
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
