Telechat Review of draft-lha-gssapi-delegate-policy-
review-lha-gssapi-delegate-policy-secdir-telechat-orman-2010-03-03-00
| Request | Review of | draft-lha-gssapi-delegate-policy |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2010-03-02 | |
| Requested | 2010-02-20 | |
| Authors | Sam Hartman , Love Astrand | |
| Draft last updated | 2010-03-03 | |
| Completed reviews |
Secdir Last Call review of -??
by
Hilarie Orman
Secdir Telechat review of -?? by Hilarie Orman |
|
| Assignment | Reviewer | Hilarie Orman |
| State | Completed | |
| Review |
review-lha-gssapi-delegate-policy-secdir-telechat-orman-2010-03-03
|
|
| Completed | 2010-03-03 |
review-lha-gssapi-delegate-policy-secdir-telechat-orman-2010-03-03-00
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.