Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
draft-ietf-abfab-arch-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-05-05
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-03-31
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-03-31
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-03-23
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2016-03-09
|
13 | (System) | RFC Editor state changed to REF from AUTH |
2016-03-07
|
13 | (System) | RFC Editor state changed to AUTH from EDIT |
2016-01-11
|
13 | (System) | RFC Editor state changed to EDIT from MISSREF |
2015-10-14
|
13 | (System) | Notify list changed from abfab-chairs@ietf.org, draft-ietf-abfab-arch@ietf.org to (None) |
2014-08-25
|
13 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-08-25
|
13 | (System) | RFC Editor state changed to MISSREF |
2014-08-25
|
13 | (System) | Announcement was received by RFC Editor |
2014-08-25
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2014-08-25
|
13 | (System) | IANA Action state changed to In Progress |
2014-08-22
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2014-08-22
|
13 | Cindy Morgan | IESG has approved the document |
2014-08-22
|
13 | Cindy Morgan | Closed "Approve" ballot |
2014-08-22
|
13 | Cindy Morgan | Ballot approval text was generated |
2014-08-22
|
13 | Cindy Morgan | Ballot writeup was changed |
2014-08-22
|
13 | Stephen Farrell | Ballot writeup was changed |
2014-07-21
|
13 | Sam Hartman | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-07-21
|
13 | Sam Hartman | New version available: draft-ietf-abfab-arch-13.txt |
2014-04-03
|
12 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-03-27
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation - Defer |
2014-03-27
|
12 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Tom Yu. |
2014-03-27
|
12 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-03-27
|
12 | Benoît Claise | [Ballot comment] Here is the AAA-doctor thorough review by Alan DeKok: Here we go. In short, the document is good, but seems to assume … [Ballot comment] Here is the AAA-doctor thorough review by Alan DeKok: Here we go. In short, the document is good, but seems to assume a familiarity with the concepts being discussed. It talks about concepts without introducing them, leading to confusion on the part of the naive reader. Section 1 Numerous security mechanisms have been deployed on the Internet to manage access to various resources. - This is a bit vague. "Security does stuff". Some examples would help. A Relying Party (RP) is the entity that manages access to some resource - This sentence jumps discontinuously from the previous paragraph. Why are we talking about Relying parties? It's generally easier to talk about problems, and then to introduce solutions to those problems. ... The entity that is requesting access to that resource is often described as the Client. Why not use "Client" and "Server"? Jumping straight to new terminology is awkward. Some security mechanisms allow the RP to delegate aspects of the access management decision to an entity called the Identity Provider (IdP). This delegation requires technical signaling, trust and a common understanding of semantics between the RP and IdP. These aspects are generally managed within a relationship known as a 'federation'. - The "federation" doesn't follow from delegation. System A can delegate functionality to system B, but that's just delegation. I would expect to see motivation for federation. - e.g. when there are many people trying to authenticate, the Server may not have credentials for all of them. It may delegate the authentication to one or more secondary Servers. Any grouping of Servers to achieve a common purpose is called a "federation" - once we define the problem space in terms of *existing* terminology, it's then possible to introduce *new* terminology. Single or Simplified sign-on: An Internet service can delegate access management - what's an "Internet Service" ? That's the first use of the term in this document. Is it a Relying Party? A generic Server? Often a Relying Party does not need to know the identity of a Client to reach an access management decision. It is frequently only necessary for the Relying Party to know specific attributes about the client, - nitpick I'd use "properties" rather than "attributes". Attributes have a well-defined meaning in AAA space. The properties talked about above may not be transported in attributes, so they shouldn't be called attributes. Prior to the release of attributes to the RP from the IdP, the IdP will check configuration and policy to determine if the attributes are to be released. - Why is an IdP releasing attributes to the RP? This is the first mention of it. Sometimes a Relying Party needs, or would like, to know more about a client than an affiliation or a pseudonym. - Why? Because "it's Tuesday, and I want to know his shoe size"? Or are there problems whih are solved by asking for additional information? This memo describes the Application Bridging for Federated Access Beyond the Web (ABFAB) architecture. This architecture makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including RADIUS, the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP) and SAML. The architecture should be extended to use Diameter in the future. The architecture addresses the problem of federated access management primarily for non-web-based services. - the last sentence there should be moved to be the second one. i.e. What is ABFAB. Problem to be solved. Technology used to solve the problem. Section 1.1 This document uses identity management and privacy terminology from [RFC6973]. In particular, this document uses the terms identity provider, relying party, identifier, pseudonymity, unlinkability, and anonymity. - that sentence could be moved to earlier in the document. It gives a basis for the terminology used in Section 1. Or, re-word Section 1 to use less of the terminology introduced in Section 1.1. This document uses the term Network Access Identifier (NAI), as defined in [I-D.ietf-radext-nai]. An NAI consists of a realm identifier, which is associated with an IdP - Why is a realm associated with an IdP? Again, motivation. Does the *document* use the NAI, or does it assume that the *authentication it talks about* uses the NAI? - e.g. We assume that each authentication request in the ABFAB architecture includes an NAI. The realm portion of the NAI is used to distinguish and/or select an IdP. Each IdP may have one or more realms. One of the problems some people have found with reading this document is that the terminology sometimes appears to be inconsistent. This is due the fact that the terms used by the different standards we are referencing are not consistent with each other. In general the document uses either the ABFAB term or the term associated with the standard under discussion as appropriate. - nitpick: I would say that for general cases, this document uses the terminology from RFC 6973, as it is cross-standard. Where this document refers to actions of a particular protocol, the protocol-specific terms are used. e.g. "ABFAB relies on an IdP", versus "the RADIUS client ..." - doing so should make the document clearer Note that in some cases a cell has been left empty; in these cases there is no name that represents the entity. - nitpick: there is no name *within that standard* which defines the given term. This document uses the term channel binding with two different meanings. - I would say "in two different contexts". The later specification of "EAP channel bindings" and "GSS-API channel bindings" makes the distinction clear. The term "channel bindings" therefore does not have two different meanings, as it should be used only within the context of "EAP" or "GSS-API". Federation The Identity Provider and the Relying Parties are part of a Federation. The relationship may be direct (they have an explicit trust relationship) or transitive (the trust relationship is mediated by one or more entities). The federation relationship is governed by a federation agreement. Within a single federation, there may be multiple Identity Providers as well as multiple Relying Parties. - I find this confusing, and not in line with the other definitions. A definition should be of the form: FOO FOO is thing which does BAR, and used BAZ and BARK to do so. - e.g. A Federation is composed of a set of Identity Providers and Relying Parties. The IdPs and RPs may have explicit trust relationships with each other, or the trust may be mediated by one more more entities within that federation. The relationships between IdPs and RPs is governed by a federation agreement, which is outside of the scope of this specification. Authentication There is a direct relationship between the Client and the Identity Provider. This relationship provides the means by which they trust each other and can securely authenticate each other. - the same comment applies here. Authentication is *something*. The first sentence of the definition above seems to have no bearing on authentication Operational Specifications: - put the last sentence first, which motivates the rest of the paragraph. The Operational Specifications can demand the usage of a sophisticated technical infrastructure, - as opposed to a crappy technical infrastructure? I suggest just deleting the word "sophisticated" While a federation agreement is often discussed within the context of formal relationships, such as between an enterprise and an employee or a government and a citizen, - who is doing that discussion? I don't see it in this document. Some clarity would help here. For an IdP and a Client, it is sufficient for a relationship to be established by something as simple as using a web form and confirmation email. - are we suggesting implementation details? If so, why does it matter? The nature of federation dictates that there is some form of relationship between the identity provider and the relying party. This is particularly important when the relying party wants to use information obtained from the identity provider for access management decisions and when the identity provider does not want to release information to every relying party (or only under certain conditions). - Suggest capitalization of terms, to match the rest of the draft While it is possible to have a bilateral agreement between every IdP and every RP; on an Internet scale this setup requires the introduction of the multi-lateral federation concept, as the management of such pair-wise relationships would otherwise prove burdensome. - what is a "multi-lateral federation concept"? A concept? A real thing? The nature and quality of the relationship between the Client and the IdP is an important contributor to the level of trust that an RP may attribute to an assertion - "attribute" is used in other contexts here. I'd suggest using a synonym for "attribute" Federation does not require an a priori relationship or a long-term relationship between the RP and the Client; it is this property of federation that yields many of its benefits. - what does "its" refer to? The federation? The relationship? However, federation does not preclude the possibility of a pre-existing relationship between the RP and the Client, nor that they may use the introduction to create a new long-term relationship independent of the federation. - nitpick: I would say that the entities may have relationships outside of the federation, including ones prior and post to the federation As the number of federated IdPs and RPs (services) proliferats, - typo "proliferates". And why is (services) there? Are RPs just RPs, or are they now (services)? I suggest deleting it. As the number of federated IdPs and RPs (services) proliferats, the role of the individual - ... was not previously discussed. I suggest replacing that with something like "an individual may have multiple identities (NAIs), and choose the correct identity for network access" For instance, in the case of an email provider, the SMTP and IMAP protocols do not have the ability for the server to request information from the client, beyond the clients NAI, that the server would then use to decide between the multiple federations it is associated with. Section 1.4 - nitpick: that's a long sentence. Suggest breaking it up into smaller fragments. In this example, a client is attempting to connect to a server - nitpick: suggest passive voice. "a client attempts to connect ..." - many of the following paragraphs have "X is configured". OK, how? Maybe "we assume that configuration discussed below is out of band, e.g. via manual administrator action" Section 1.5 o Each party in a transaction will be authenticated, although perhaps not identified, - I'm not sure how that works. Can you authenticate an entity without identifying them? The rest of the document seems silent on this topic - Generally, there's a lot of lower-case use of "identity providers", "relying parties", etc. Please use consistent terms. IdPs and RPs is probably good enough, given the number of uses of those terms in the document o The system will be designed primarily for non-Web-based authentication. - Why exclude the Web? And if we're excluding the web, what kind of authentication *is* it designed for? o The system will build upon existing standards, components, and operational practices. - that's good, but I'm not sure it needs to be explicitly called out. A lot of attention on federated access has been devoted to the Web. This document instead focuses on a non-Web-based environment and focuses on those protocols where HTTP is not used. - it would be useful to say why web-based systems aren't useful here. i.e. OAUTH, etc. presumes that the user already has network access. OAUTH mediates access to *services* on an existing network. ABFAB mediates access to *networks*, especially visited networks. Section 2 The main theme of the work described in this document is focused on re-using existing building blocks that have been deployed already and to re-arrange them in a novel way. - the re-arrangement is not the goal, surely. Instead, it's "re-arrange them in a novel way to achieve global federated network access with minimal changes to existing systems" - that motivation also affects the first sentence of the next paragraph Section 2.1 Protocols that support the same framework, but do different routing are expected to be defined and used the future. One such effort call the Trust Router - nitpick: callED the Trust Router... Section 2.1.1 The usage of the AAA framework with RADIUS [RFC2865] and Diameter [RFC6733] for network access authentication has been successful from a deployment point of view. To map to the terminology used in Figure 1 to the AAA framework - it may be worth referring again to the table earlier in Section 1. But reminding the reader of it here is a good idea. Section 2.1.5 For the traditional use of AAA frameworks, network access, the only requirement that was necessary to grant access was an affirmative response from the IdP. - not completely true. An affirmative response is the minimal requirement. Very often, additional authorization attributes are needed (e.g. Service-Type). RFC 2865 Section 5.6 says this about Service-Type: A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. ... This means that the RP needs to map from the SAML issuer or federation name, type and semantic into the name, type and semantics that the policies of the RP are written in. - some guidance here would be useful. How is that mapping done? Or is it just "implementation defined" ? Some RPs need to ensure that specific criteria are met during the authentication process. This need is met by using Levels of Assurance. - This is the first mention of "Levels of Assurance". It's important enough to capitalize, so it's a apparently a key concept. But there's no corresponding definition anywhere. Section 2.3.1 So, we use GSS-API and SASL because a number of the application protocols we wish to federate support these strategies for security integration. What does this mean from a protocol standpoint and how does this relate to other layers? This means we need to design a concrete GSS-API mechanism. - while explanatory, asking && answering questions is a little odd in a standards document. I suggest trying to re-word this to be explanatory instead Section 4.2.2 ... (such as the use of TLS for RADIUS [I-D.ietf-radext-dtls]). - Maybe refer to RFC 6614 instead of the DTLS draft Also "mitigted" - mis-spelled Note that ABFAB has not specified any AAA accounting requirements. Implementations that use the accounting portion of AAA should consider privacy appropriately when designing this aspect. - specific suggestions would be useful here. e.g. use CUI for user identifiers, to give user anonymity. Ensure that the accounting packets contain no more information than what's in the Access-Request, etc. Section 4.4 - it may be worth moving the last paragraph of Section 4.2.2 (accounting) to this section. Section 5 ... In situations where the client is not yet on the net, ... - that situation wasn't clearly described earlier in the document. (or at least so far as I recall). Earlier text also talked about clients having IP addresses. It would be good to clarify just which situations will apply to ABFAB. Concrete examples would help. - it may be useful to add a section with concrete examples. Describe the scenarios (user visiting remote site), and then a short discussion of what happens, and what protocols are used. Show which portions are new to ABFAB, and which ones already exist. Despite my nits, the document is pretty good overall. My comments are largely related to clarifications, style, etc. The ABFAB architecture is a complex system which has a lot of moving pieces. The document does a good job of describing them. |
2014-03-27
|
12 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-03-21
|
12 | Vijay Gurbani | Request for Telechat review by GENART Completed: Ready. Reviewer: Vijay Gurbani. |
2014-03-21
|
12 | Adrian Farrel | [Ballot comment] Wondering whether there is any difference between URI reference [2] and [3]. Also wondering why [2] is not replaced with a pointer to … [Ballot comment] Wondering whether there is any difference between URI reference [2] and [3]. Also wondering why [2] is not replaced with a pointer to the I-D (https://datatracker.ietf.org/doc/draft-mrw-abfab-trust-router) But actually, the choice to refer to [2] from a papragraph in Section 1.2 that introduces the entity called the Individual seems odd An example of such an entity can be found in the trust routing protocol [2] where the routers use ABFAB to authenticate to each other. The referenced slides do talk about Clients, but not about Individuals. --- Ont the other hand, Section 4.1 has Specifications such as the Trust Router Protocol and RADIUS dynamic discovery [I-D.ietf-radext-dynamic-discovery] can be used to shorten the path between the AAA client and the AAA server (and thus stop these AAA Proxies from being Observers); however even in these circumstances there may be AAA Proxies in the path. with no reference for "Trust Router Protocol" |
2014-03-21
|
12 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-03-20
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2014-03-20
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2014-03-14
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-03-05
|
12 | Cindy Morgan | Telechat date has been changed to 2014-03-27 from 2014-03-20 |
2014-02-28
|
12 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-02-27
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tom Yu |
2014-02-27
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Tom Yu |
2014-02-20
|
12 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. |
2014-02-20
|
12 | Benoît Claise | Telechat date has been changed to 2014-03-20 from 2014-02-20 |
2014-02-20
|
12 | Benoît Claise | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2014-02-20
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-02-20
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-02-20
|
12 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2014-02-20
|
12 | Stephen Farrell | Ballot writeup was changed |
2014-02-20
|
12 | Stephen Farrell | Ballot writeup was changed |
2014-02-19
|
12 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2014-02-18
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-02-18
|
12 | Martin Stiemerling | [Ballot comment] I found this in Section 8.3: >Editorial Comments > >[CREF1] JLS: Should this be an EAP failure to the client as well? Is … [Ballot comment] I found this in Section 8.3: >Editorial Comments > >[CREF1] JLS: Should this be an EAP failure to the client as well? Is this a left over or still an open question? |
2014-02-18
|
12 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-02-17
|
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-02-17
|
12 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2014-02-14
|
12 | Stephen Farrell | Ballot writeup was changed |
2014-02-14
|
12 | Stephen Farrell | Placed on agenda for telechat - 2014-02-20 |
2014-02-14
|
12 | Stephen Farrell | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
2014-02-14
|
12 | Stephen Farrell | Ballot has been issued |
2014-02-14
|
12 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2014-02-14
|
12 | Stephen Farrell | Created "Approve" ballot |
2014-02-14
|
12 | Stephen Farrell | Ballot writeup was changed |
2014-02-13
|
12 | Jim Schaad | New version available: draft-ietf-abfab-arch-12.txt |
2014-02-11
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-02-11
|
11 | Jim Schaad | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-02-11
|
11 | Jim Schaad | New version available: draft-ietf-abfab-arch-11.txt |
2014-02-10
|
10 | Stephen Farrell | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2014-01-23
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tom Yu. |
2014-01-17
|
10 | (System) | State changed to Waiting for Writeup from In Last Call (ends 2014-01-17) |
2014-01-09
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2014-01-09
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2014-01-09
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2014-01-09
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Menachem Dodge |
2014-01-09
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2014-01-09
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tom Yu |
2014-01-06
|
10 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-01-06
|
10 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-abfab-arch, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-abfab-arch, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
2014-01-03
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-01-03
|
10 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Application Bridging for Federated Access … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Application Bridging for Federated Access Beyond Web (ABFAB) Architecture) to Informational RFC The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Application Bridging for Federated Access Beyond Web (ABFAB) Architecture' as Informational RFC 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 2014-01-17. 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 Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-01-03
|
10 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2014-01-03
|
10 | Stephen Farrell | Last call was requested |
2014-01-03
|
10 | Stephen Farrell | Ballot approval text was generated |
2014-01-03
|
10 | Stephen Farrell | Ballot writeup was generated |
2014-01-03
|
10 | Stephen Farrell | State changed to Last Call Requested from AD Evaluation::AD Followup |
2014-01-03
|
10 | Stephen Farrell | Last call announcement was generated |
2014-01-03
|
10 | Stephen Farrell | Last call announcement was generated |
2013-12-31
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-12-31
|
10 | Jim Schaad | New version available: draft-ietf-abfab-arch-10.txt |
2013-12-17
|
09 | Stephen Farrell | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::Point Raised - writeup needed |
2013-12-16
|
09 | Stephen Farrell | State changed to AD Evaluation::Point Raised - writeup needed from Publication Requested |
2013-12-06
|
09 | Leif Johansson | IETF WG state changed to Submitted to IESG for Publication |
2013-12-06
|
09 | Leif Johansson | IESG state changed to Publication Requested |
2013-12-06
|
09 | Leif Johansson | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Informational as indicated in the page header (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 This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. Working Group Summary The WG process, although it took some time, hasn't been particularly contentious. Instead there has been a lot of feedback from the core spec work and this specification which has necessarily delayed the work a bit. Document Quality This is an informational document that describes abfab architecture. The abfab suite of protocols has been implemented once by the moonshot project. Afaik there are no other implementations but the night is young. The work of Jim Schaad in particular has been excellent. His thoroughness and dedication to quality has meant a lot for getting this document done. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The document shepherded is Leif Johansson (WG chair). The responsible AD is Stephen Farrell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. There has been 2 WGLCs on this document - the first generated a few comments that were resolved by the WG. I reviewed this document and believe it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. It would be useful to get a security review of this document during the IESG process. (6) Describe any specific concerns or issues that the Document Shepherd has 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. I have no such concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. I have no reason to believe any IPR covers this document since no IPR covers core abfab technology. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) 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? The WG has a relatively small core of active participants. Among those the consensus is strong. (10) 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 publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits look fine. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? Yes, the reference section is in the standard 2-part form. (14) 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 plan for their completion? There are 4: [I-D.ietf-abfab-gss-eap] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", draft-ietf-abfab-gss- eap-09 (work in progress), August 2012. This document is in AUTH48 [I-D.ietf-abfab-aaa-saml] Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", draft-ietf-abfab-aaa-saml-05 (work in progress), February 2013. This document is nearing completion in the abfab WG [I-D.ietf-radext-nai] DeKok, A., "The Network Access Identifier", draft-ietf- radext-nai-02 (work in progress), January 2013. [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- ietf-radext-dtls-07 (work in progress), October 2013. These documents are in WG Last Call in RADEXT. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). No IANA requirements (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No IANA requirements (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No such sections exist |
2013-12-06
|
09 | Leif Johansson | State Change Notice email list changed to abfab-chairs@tools.ietf.org, draft-ietf-abfab-arch@tools.ietf.org |
2013-12-06
|
09 | Leif Johansson | Responsible AD changed to Stephen Farrell |
2013-12-06
|
09 | Leif Johansson | Working group state set to Submitted to IESG for Publication |
2013-12-06
|
09 | Leif Johansson | IESG state set to Publication Requested |
2013-12-06
|
09 | Leif Johansson | IESG process started in state Publication Requested |
2013-12-06
|
09 | Leif Johansson | Changed document writeup |
2013-12-06
|
09 | Jim Schaad | New version available: draft-ietf-abfab-arch-09.txt |
2013-12-01
|
08 | Leif Johansson | Document shepherd changed to Leif Johansson |
2013-12-01
|
08 | Leif Johansson | Intended Status changed to Informational from None |
2013-12-01
|
08 | Leif Johansson | Changed consensus to Yes from Unknown |
2013-12-01
|
08 | Leif Johansson | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2013-11-03
|
08 | Jim Schaad | New version available: draft-ietf-abfab-arch-08.txt |
2013-07-31
|
07 | Leif Johansson | IETF WG state changed to In WG Last Call from WG Document |
2013-07-30
|
07 | Jim Schaad | New version available: draft-ietf-abfab-arch-07.txt |
2013-04-18
|
06 | Jim Schaad | New version available: draft-ietf-abfab-arch-06.txt |
2013-02-25
|
05 | Jim Schaad | New version available: draft-ietf-abfab-arch-05.txt |
2012-10-22
|
04 | Jim Schaad | New version available: draft-ietf-abfab-arch-04.txt |
2012-07-09
|
03 | Jim Schaad | New version available: draft-ietf-abfab-arch-03.txt |
2012-05-24
|
02 | Jim Schaad | New version available: draft-ietf-abfab-arch-02.txt |
2012-03-10
|
01 | Hannes Tschofenig | New version available: draft-ietf-abfab-arch-01.txt |
2012-01-30
|
00 | (System) | Document has expired |
2011-07-29
|
00 | (System) | New version available: draft-ietf-abfab-arch-00.txt |