I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document formalizes the unencrypted form of the KRB-CRED message. I am not a Kerberos expert (nor do I play one on TV) so this review is going to have limited value. I am unclear as to whether there is a need for this facility -- there could be additional explanation and justification for why this is needed. Assuming that there is a need for this, the document seems well written. The Security Considerations section outlines risks incurred by not having encryption, and specifies that this must only be used with a transport such as TLS that provides integrity and confidentiality. What is unclear from the security considerations section is that this transport must provide end to end security -- for example an IPSec VPN provides "a transport where sender and recipient identities can been established be known to each other and provides confidentiality and integrity.", but presumably the intent is that the encryption be between the applications -- IMO this should be clarified. I feel that there should advice provided regarding under what conditions use of this is appropriate -- but, than again, maybe this is obvious to someone who actually understands Kerberos :-P Nit: Section 3: s/MUST BE/MUST be/ W