|
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@xxxxxxxxxx] 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://trac.tools.ietf.org/area/ops/trac/wiki/Directorates Thank you, Tina |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf