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:[email protected]] Sent: Tuesday, November 17, 2009 4:47 AM To: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
