Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-07-20
|
15 | Stephen Farrell | Ballot writeup was changed |
2012-07-20
|
15 | Stephen Farrell | Ballot writeup was changed |
2012-06-01
|
15 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-06-01
|
15 | (System) | IANA Action state changed to No IC |
2012-05-31
|
15 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-05-31
|
15 | Amy Vezza | IESG has approved the document |
2012-05-31
|
15 | Amy Vezza | Closed "Approve" ballot |
2012-05-31
|
15 | Amy Vezza | Ballot approval text was generated |
2012-05-31
|
15 | Amy Vezza | Ballot writeup was changed |
2012-05-31
|
15 | Nicolás Williams | New version available: draft-ietf-kitten-gssapi-naming-exts-15.txt |
2012-05-10
|
14 | Stephen Farrell | Ballot approval text was changed |
2012-05-10
|
14 | Stephen Farrell | Ballot approval text was generated |
2012-04-26
|
14 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-04-25
|
14 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-04-25
|
14 | Pete Resnick | [Ballot comment] In section 5: Another aspect of context is encoding of the attribute information. An attribute containing an ASCII or UTF-8 version … [Ballot comment] In section 5: Another aspect of context is encoding of the attribute information. An attribute containing an ASCII or UTF-8 version of an e-mail address could not be interpreted the same as a ASN.1 Distinguished Encoding Rules e-mail address in a certificate. All of these contextual aspects of a name attribute affect whether two attributes can be treated the same by an application and thus whether they should be considered the same name attribute. In the GSS-API naming extensions, attributes that have different contexts MUST have different names so they can be distinguished by applications. As an unfortunate consequence of this requirement, multiple attribute names will exist for the same basic information. That is, there is no single attribute name for the e-mail address of an initiator. I don't have the expertise to evaluate this document thorougly, but something in the above seems weird, if not incorrect. It is certainly the case that an email address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address. But the words "could not be interpreted the same as" strike me as incorrect. You *can* interpret the two e-mail address as the same if, after doing the decoding, you compare the addresses to eachother. And it would, indeed, be very unfortunate for something that happens to use a different encoding to get a different name for each encoding and therefore have multiple non-comparable occurances of the item. It seems like you would want only one occurance of each item, marked with the encoding, and implementations would be responsible for the decoding. Maybe this is just a language issue. But something seems wrong about the above. |
2012-04-25
|
14 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-04-25
|
14 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document, and just three minor nits you may want to look at. Section 2 … [Ballot comment] I have no objection to the publication of this document, and just three minor nits you may want to look at. Section 2 This document proposes concrete GSS-API extensions. Should feel free to be more positive! s/proposes/defines/ --- Section 3 I suspect the RFC editor will ask you to expand "iff" --- Please consider replacing the reference text used here for [OASIS.saml-core-2.0-os] with the text used in RFC 6595 to include the stable URL. |
2012-04-25
|
14 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-04-24
|
14 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-04-24
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-04-24
|
14 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-04-24
|
14 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-04-24
|
14 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-04-24
|
14 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-04-24
|
14 | Russ Housley | [Ballot comment] Please consider the editorial comments from the Gen-ART Review by Pete McCann on 24-Apr-2012. The review can be found at: … [Ballot comment] Please consider the editorial comments from the Gen-ART Review by Pete McCann on 24-Apr-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07387.html |
2012-04-24
|
14 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-04-23
|
14 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-04-23
|
14 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-04-23
|
14 | Sean Turner | [Ballot comment] Only nits: s2: r/(eg an X509/(e.g., an X.509 s3/s5/s7.5/s7.6: r/iff/if X3 s5: Consider Kerberos PKINIT (RFC 4556). Isn't this an informative … |
2012-04-23
|
14 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-04-10
|
14 | Stephen Farrell | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-10
|
14 | Stephen Farrell | Placed on agenda for telechat - 2012-04-26 |
2012-04-10
|
14 | Stephen Farrell | Ballot has been issued |
2012-04-10
|
14 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2012-04-10
|
14 | Stephen Farrell | Ballot writeup was changed |
2012-04-10
|
14 | Stephen Farrell | Created "Approve" ballot |
2012-04-10
|
14 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-04-06
|
14 | Pearl Liang | IESG: IANA has reviewed draft-ietf-kitten-gssapi-naming-exts-14.txt, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, … IESG: IANA has reviewed draft-ietf-kitten-gssapi-naming-exts-14.txt, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there are no IANA Actions that need to be completed. |
2012-03-29
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete McCann |
2012-03-29
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete McCann |
2012-03-27
|
14 | Cindy Morgan | Last call sent |
2012-03-27
|
14 | Cindy Morgan | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (GSS-API Naming Extensions) to Proposed Standard The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'GSS-API Naming Extensions' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-27
|
14 | Cindy Morgan | Last call announcement was generated |
2012-03-27
|
14 | Stephen Farrell | Last call was requested |
2012-03-27
|
14 | Stephen Farrell | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-03-27
|
14 | Leif Johansson | New version available: draft-ietf-kitten-gssapi-naming-exts-14.txt |
2012-03-11
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-03-11
|
13 | Leif Johansson | New version available: draft-ietf-kitten-gssapi-naming-exts-13.txt |
2012-03-08
|
12 | Stephen Farrell | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-03-08
|
12 | Stephen Farrell | State changed to AD Evaluation from Publication Requested |
2012-03-08
|
12 | Stephen Farrell | Here's the PROTO write up I got. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Here's the PROTO write up I got. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. This draft defines standard interfaces. Yes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting regarding WG process. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This protocol has been implemented in the MIT 1.8 release. At least one other vendor has plans on implementing this in the future as well. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? |
2012-03-08
|
12 | Stephen Farrell | State changed to Publication Requested from AD is watching |
2011-12-16
|
12 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-12.txt |
2011-11-25
|
12 | (System) | Document has expired |
2011-11-25
|
12 | (System) | State changed to Dead from AD is watching. |
2011-05-24
|
11 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-11.txt |
2011-05-22
|
10 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-10.txt |
2011-03-31
|
12 | Cindy Morgan | Responsible AD has been changed to Stephen Farrell from Tim Polk |
2011-02-09
|
09 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-09.txt |
2010-12-26
|
12 | (System) | Document has expired |
2010-12-26
|
12 | (System) | State changed to Dead from AD is watching. |
2010-09-01
|
12 | Tim Polk | State Changes to AD is watching from Waiting for AD Go-Ahead by Tim Polk |
2010-09-01
|
12 | Tim Polk | This document is going back to the working group to address issues raised by Sam Hartman and confirmed in wg discussions. See wg emails: http://www.ietf.org/mail-archive/web/kitten/current/msg01872.html … This document is going back to the working group to address issues raised by Sam Hartman and confirmed in wg discussions. See wg emails: http://www.ietf.org/mail-archive/web/kitten/current/msg01872.html http://www.ietf.org/mail-archive/web/kitten/current/msg01892.html and http://www.ietf.org/mail-archive/web/kitten/current/msg01895.html and the kitten meeting summary for IETF 78: http://www.ietf.org/mail-archive/web/saag/current/msg02858.html |
2010-09-01
|
12 | Tim Polk | [Note]: 'Shawn Emery (shawn.emery@oracle.com) is the document shepherd.' added by Tim Polk |
2010-07-30
|
12 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Dan Harkins. |
2010-07-23
|
12 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-07-12
|
12 | Amanda Baber | IANA comments: IANA understands that this document creates a standardized namespace for GSS-API attributes. IANA understands that no registration is required now, but that a … IANA comments: IANA understands that this document creates a standardized namespace for GSS-API attributes. IANA understands that no registration is required now, but that a registry may be required in the future. IANA understands that this document does not require any IANA actions upon approval. |
2010-07-11
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2010-07-11
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2010-07-09
|
12 | Amy Vezza | Last call sent |
2010-07-09
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-07-09
|
12 | Tim Polk | State Changes to Last Call Requested from Publication Requested by Tim Polk |
2010-07-09
|
12 | Tim Polk | Last Call was requested by Tim Polk |
2010-07-09
|
12 | (System) | Ballot writeup text was added |
2010-07-09
|
12 | (System) | Last call text was added |
2010-07-09
|
12 | (System) | Ballot approval text was added |
2010-06-25
|
12 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Shawn Emery , yes, yes (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had adequate review from the WG members. The shepherd doesn't know of reviews by non WG members. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. No IPR disclosure is known to the author or the shepherd. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus to publish the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody threatened to appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? idnits 2.12.04 found one error in regards to a downward reference, but this was expected. See section 1.h. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There is a downward reference made to RFC3061. This does not set a precedence as other RFCs with standards track make references to this informational RFC, e.g.: RFC4088. However, this draft makes an informational reference to 3061 as a MUST. I believe that this should make a normative reference 3061. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, but reservations are not required as this document does not, nor should attempt to allocate name attribute URIs. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There is no specification of ABNF, MIB, XML, or ASN.1 in this document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document provides an extension to the Generic Security Services Application Programming Interface (GSS-API) to include the exchange of name attributes between peers. These attributes could be intern used for authorization by applications. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing worth noting regarding WG process. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This protocol has been implemented in the MIT 1.8 release. At least one other vendor has plans on implementing this in the future as well. |
2010-06-25
|
12 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-06-25
|
12 | Cindy Morgan | [Note]: 'Shawn Emery (shawn.emery@oracle.com) is the document shepherd.' added by Cindy Morgan |
2010-06-24
|
08 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-08.txt |
2010-05-18
|
07 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-07.txt |
2010-03-07
|
06 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-06.txt |
2009-07-30
|
05 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-05.txt |
2009-03-08
|
04 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-04.txt |
2008-07-13
|
03 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-03.txt |
2006-06-29
|
02 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-02.txt |
2005-10-17
|
01 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-01.txt |
2005-05-16
|
00 | (System) | New version available: draft-ietf-kitten-gssapi-naming-exts-00.txt |