I reviewed the document draft-lha-gssapi-delegate-policy-04 in general
and for its operational impact.
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their attention
and spend less time on the trouble-free ones.
Improving the documents is important, but clearly a secondary purpose.
A third purpose is to broaden the OpsDir reviewers' exposure to work going
on in other parts of the IETF.
Reviews from OpsDir members do not in and of themselves cause the IESG to
raise issue with a document. The reviews may, however, convince individual
IESG members to raise concern over a particular document requiring further
discussion. The reviews, particularly those conducted in last call and
earlier, may also help the document editors improve their documents.
--
Review Summary:
Intended status: Standards Track
Delegating user credentials to an insufficiently trusted party is
problematic.
Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator
of
a Kerberos realm to indicate that a particular service is trusted for
delegation.
This specificatinon adds support for this flag and similar facilities in
other
authentication mechanisms to GSS-API (RFC 2743).
1. Is the document readable?
Yes.
2. Does it contain nits?
Yes.
Some grammatical nits:
Section 2
"to allow and administrator" -> "to allow an administrator"
"It would is desirable" -> "It would be desirable"
Idnits complains of a potential boilerplate error:
idnits 2.11.15
tmp/draft-lha-gssapi-delegate-policy-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack an IETF Trust Provisions (12 Sep 2009)
Section 6.b License Notice -- however, there's a paragraph with a
matching beginning. Boilerplate error?
trust-12-sep-2009 Section 6.b paragraph 3 text:
"This document is subject to BCP 78 and the IETF Trust's Legal
Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the BSD License."
... text found in draft:
"This document is subject to BCP 78 and the IETF Trust's Legal
Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document."
................................................^
Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The document seems to lack a disclaimer for pre-RFC5378 work, but was
first submitted before 10 November 2008. Should you add the
disclaimer?
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.).
trust-12-sep-2009 Section 6.c.iii text:
"This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English."
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative
references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 1 error (**), 1 warning (==), 0 comments (--).
3. Is the document class appropriate?
Yes.
Given some of the content of Section 5, I wonder whether this
document should include Updates: RFC 4120 in the header:
[RFC4120] does not adequately describe the behavior of OK-AS-DELEGATE
flag in a cross realm environment. This document clarifies that
behavior. 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. If any of the intermediate cross realm TGTs do not
have the OK-AS-DELEGATE flag set, the mechanism MUST NOT delegate
credentials.
3. Is the problem well stated?
Yes.
4. Is the problem really a problem?
Yes.
5. Does the document consider existing solutions?
Yes. The Introduction describes the existing GSS-API [RFC2743], which
leaves the
determination of whether delegation is desired to the client. This requires
client
applications to know what services should be trusted for delegation. Since
in some
cases a central authority may be in a better position than the client
application to
know which services should receive delegation, this specification adds a new
input
flag which allows th client to request delegation when approved by central
policy.
6. Does the solution break existing technology?
No. Since this document defines a new flag rather than changing the
behavior of an
existing flag, this document does not affect existing applications written
to GSS-API.
Section 6 thoughtfully describes the rationale for using a new flag.
7. Does the solution preclude future activity?
No.
8. Is the solution sufficiently configurable?
Yes. The Kerberos realm administrator can decide whether a particular
service is an
appropriate target for delegation.
9. Can performance be measured? How?
This document should not affect performance.
10. Does the solution scale well?
This document should not create any scaling issues.
11. Is Security Management discussed?
Yes -- the document is all about security management.
From: Tina TSOU [mailto:tena(_at_)huawei(_dot_)com]
Sent: Tuesday, November 17, 2009 4:47 AM
To: Bernard_Aboba(_at_)hotmail(_dot_)com
Cc: Dan (Dan) Romascanu; Ron Bonica
Subject: Operations Directorate Review
Hello Aboba,
As a member of the Operations Directorate you are being asked to review the
IETF Last Call:
<http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-04.txt
http://www.ietf.org/internet-drafts/draft-lha-gssapi-delegate-policy-04.txt
http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates
Thank you,
Tina
<http://tinatsou.weebly.com/contact.html>
http://tinatsou.weebly.com/contact.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf