Subject: Review of draft-lha-gssapi-delegate-policy

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 17 Nov 2009 10:04:17 -0800

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-masked]] 
Sent: Tuesday, November 17, 2009 4:47 AM
To: [email-masked]
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