Connected: An Internet Encyclopedia
3.1.5. Receipt of KRB_AS_REP message

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1510
Up: 3. Message Exchanges
Up: 3.1. The Authentication Service Exchange
Prev: 3.1.4. Generation of KRB_ERROR message
Next: 3.1.6. Receipt of KRB_ERROR message

3.1.5. Receipt of KRB_AS_REP message

3.1.5. Receipt of KRB_AS_REP message

If the reply message type is KRB_AS_REP, then the client verifies that the cname and crealm fields in the cleartext portion of the reply match what it requested. If any padata fields are present, they may be used to derive the proper secret key to decrypt the message. The client decrypts the encrypted part of the response using its secret key, verifies that the nonce in the encrypted part matches the nonce it supplied in its request (to detect replays). It also verifies that the sname and srealm in the response match those in the request, and that the host address field is also correct. It then stores the ticket, session key, start and expiration times, and other information for later use. The key-expiration field from the encrypted part of the response may be checked to notify the user of impending key expiration (the client program could then suggest remedial action, such as a password change). See section A.3 for pseudocode.

Proper decryption of the KRB_AS_REP message is not sufficient to verify the identity of the user; the user and an attacker could cooperate to generate a KRB_AS_REP format message which decrypts properly but is not from the proper KDC. If the host wishes to verify the identity of the user, it must require the user to present application credentials which can be verified using a securely-stored secret key. If those credentials can be verified, then the identity of the user can be assured.


Next: 3.1.6. Receipt of KRB_ERROR message

Connected: An Internet Encyclopedia
3.1.5. Receipt of KRB_AS_REP message