-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/21/10 7:31 PM, Eliot Lear wrote:
Hi Eliot, all, Thanks for this great stab at an architecture document! I have read the document and have a bunch of remarks, questions etc. Some of those are a matter of taste I guess, so feel free to ignore (with arguments ;-) I looked at the document from different angles: overall organization, addressing of the key issues and specific content. In general I have assumed that readers of this document are probably intimately familiar with only part of the used components, so it is better to err at the more explanation rather than less side. Overall organization - -------------------- I see roughly an organization along the lines of: - - introduction - - problem description - - design goals - - component choices - - architecture description - - deployment considerations However, in the text the various parts are not always well separated. As an example, in the introduction (p6) the steps in the AuthN/AuthZ exchange are very much focused on the particular component choices that have been made, whereas those have not been introduced yet. And also, 1.3 is about the use of RADIUS, whereas in my mind there is no reason to specifically address RADIUS in the introduction and not SAML, GSS-API etc. I would like to have the separation between problem, design goals, implementation choices etc. much more clear because that allows us to have a 'cleaner' discussion. In particular, I would prefer to see an abstract description of the paragraphs of chapter 3 (which I think do an excellent job of stating the components) and have them instantiated in Chapter 3. Adressing of the key issues - --------------------------- The one issue that is imo only very limited addressed is that of multiple federations. Will the NAI also serve for federation selection? Does the principal need to be made aware of what federations are vaialble for a particular service? Does the IdP get to choose what federation a users is 'wielding'? depending on the answer to these questions, can we implement that in the current frameworks? Are we going to address the multiple federation problem? If not, how can that bite us later? 3.1 states that statements about the subject by the IdP are transported through AAA, is this meant to state that they will be transported *only* through AAA, or can they also be transported outside AAA (f.e. using SOAP) Detailed comments - ----------------- 1, p4 capitalize RADIUS (and throughout the doc) 1, p4: should "different roles" and "various authentication mechanisms" be bullit points too? 1, p4 "but particulary acute for the latter ans": ans -> as 1, p4: the paragraph starting with "Similarly" starts with talking about IdP selection and switches to federation selection. Which one (or both) is intended? 1, p5: the paragraph starting with "Figure 1 also shows...", I don't believe a policy is agreed upon by "some sort of administrative management", I think the adminstartive processes are rather to implement the policies that have been agreed upon oob. 1, p5: "real world entity", is this in this example not just a "natural person" instead? The "often" leaves imo enough space to also include non-human. 1, p6: so we assume different adminstrative domains but the same federation? 1, p6: steps are too implementation specific 1, p7 step 10: does the IdP authenticate or authorize the principal to the RP? How about "Once the IdP made a decision of whether and how to authorize the principal to use the service offered by the RP it will assert this to the RP" 1.2 p8: how does the no sharing of long term private keys follow from the need for multiple authentication protocols? 1.2 p8: "large number of IdPs, RPs, users" ... and federations? 1.2 p9: "The system will build upon.." -> "The system will build as much as possible build upon..." 1.3 p9: This paragraph here makes only sense for those of us entrenched in SAML federations, people coming from the AAA side may equally be interested in a paragraph about SAML here. I propose moving this to chapter 3. 3.1 p12 2nd paragraph: "is authorized to make assertions" -> "is authorized to make assertions about the principal and to that particular RP" 3.1 p12 2nd paragraph: "any old provider" -> "any RP" 3.1 p12 Federation Dynamic Referral: the identity of the principal is unknown, but the realm, isn't it? Is that not sufficient for authorizing an IdP? 3.1 p12 Federation Dynamic Referral: What is the difference between the proxy mentioned here and the one in Federation Proxy (next paragraph)? 3.1 p12 "The astute reader...", do you want to say something about RadSec here? 3.1 p13 last paragraph: So does this mean that all statements are transported through AAA, i.e. no room for SOAP interactions? 3.2 p13 "Experience has taught us...." -> "Experience has taught ...." 3.2 p13 "Experience has taught....": The authentication framework must also allow for the selection of authentication mechanisms per application, i.e. for certain applications u/p may be enough while for others hardware tokens are needed. I don't want to be forced to wield a cumbersome authentication method for low value transactions. 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the sub-operations of the initial context exchange? 3.5 p16: I don't immediately see how to improve figure 2, but I think it is not easy to understand 4 p17 It seems that part of this discussion belongs higher up in the document (design goals?) and part is implementation choices 4.1 p17: explain better what is confusing about the mutual authentication terminology 4.1 p17 "If a target name is supplied...": can the initiator only supply a target name if "the appropriate cryptographic exchanges took place"? Is it not possible that the initiator just states the target name as supplied by the acceptor and uses information from the IdP to validate this name? 4.2 p18 first paragraph: the sentence starting with "Even when it is checked" is not a well-formed sentence, and I don't understand what it should read. 4.2 p19: I don't really understand the whiteboard example, how is the user able to validate the content that is being displayed? What if some users get (slightly) different content than others? 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to explain EAP CB 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this approach? 4.3 p19 "Host-based service names...": I think a few more sentences of explanation would help. Hope this is of use, Klaas > We give to you the holiday present of reading ;-) The authors have > updated The ABFAB Architecture Draft. It contains a number of changes > since -00: > > * A high level step by step description of the process. > * A "swimming lane" diagram visually demonstrating that process. > * A discussion about channel binding and appropriate EAP methods. > * A discussion about discovery. > > This document is not complete, and will need to be a "living document" > as decisions are made in this working group. There are still a number > of XXXs in it, that indicate where at least some work is needed. It > would not be fair to say that the authors agree on everything that the > document contains, but rather we agree that it's important to show at > least one view and receive comment on direction at this point. > > As to this author, please do not be alarmed if I don't respond quickly. > I will be off from tomorrow until the 4th, and I wish you happy holidays > if you also are taking time off (and even if you are not). > > Eliot > > > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0q7ioACgkQH2Wy/p4XeFLOewCeOOXh5dftA/wySbURIuTdKmaz SjEAoJ6RVpFPTmlQSPFfUq2zmtAG0T2+ =Kcm8 -----END PGP SIGNATURE----- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
