The draft, including typos, is unchanged since my review 3 months ago. Hilarie ------------ Do not be alarmed. 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. The document describes an augmentation of the semantics of the GSSAPI service delegation policy. It allows a client to ask a central server if there is a policy allowing delegation of the service. This is a something of a policy band-aid. The API currently supports only unconditional delegation. This change allows a client to learn if the local policy supports it. The decision might involve a tier of Kerberos inter-realm servers, and the API is charged with enforcing the policy of assuring that all tickets agree that delegation is permitted. The change is minimal, involving no over-the-wire changes, but I imagine it is only part of the tip of a policy iceberg. If clients are to make policy decisions about something as complex as delegation, ultimately they will need more specific information, I would imagine. The security of the mechanism depends on how wise the administrators are when configuring the delegation policy, but the clients have no insight into how the decision was reached. I recommend that the security considerations section make some comment about why a client would or would not make use of this new mechanism. Perhaps it should be avoided for security-critical services ("don't delegate, even if it is allowed")? Or should it always be used? Section 2. Typo --- "to allow and administrator" should be "to allow an administrator" Section 4. Grammar --- "If the initiator set both ... " should be "sets". Last paragraph "the the" should be "to the". "There state" should be "their state". Section 5. Grammar. When the initiator uses deleg_policy_req_flag, the GSS-API Kerberos mechanism, in addition to the service tickets' OK-AS- DELEGATE flag, the MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Suggested rewording If the initiator sets the deleg_policy_req_flag, the GSS-API Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the service ticket, and it MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Section 7. Failure to specify deleg_policy_req_flag on the part of the client can at worst result in NOT delegating credentials -- fails closed, a desirable security property. Suggested rewording. A client's failure to specify deleg_policy_req_flag can at worst result in NOT delegating credentials. This means that the client does not expand its trust, which is generally safer than the alternative.