Klaas, thanks so much for your comments. I'm responding as an individual not on behalf of the authors as a group.
I agree that we need to do a better job of discussing federation selection; the current text does not do much about that. This is definitely a good comment and something for us to work on. You ask whether we intend to preclude SOAP. I think that's for you to tell us: we've had a WG discussion on this topic and I think we have enough of a discussion to approach a consensus. My reading is that we are going to focus on AAA transport but nothing will preclude soap. However it would be useful to get a consensus call from the chairs on this. I agree that the specific protocol flows could be moved later in the document and that would improve things. I think it's a little complicated where you want this information: there is some value in having the diagrams fairly early. You propose introducing more abstraction: having an abstract discussion of the aspects of the system and then discussing specific technology choices. Definitely for the application integration, where we've acknowledged in our charter that other options are possible, we should do this. Also, we should separate the abstract discussion of AAA from RADIUS and Diameter. However, the use of AAA, EAP, and to some extent SAML is baked in at a fairly deep level. So, we're not obligated to treat things abstractly. We can if it makes the document flow better. However sometimes it is easier to understand one concrete system than a bunch of abstractions. So, can we explore how valuable that will actually be? 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the sub-operations of the initial context exchange? No, not really. I thought it might, but it didn't end up being useful. 4 p17 It seems that part of this discussion belongs higher up in the document (design goals?) and part is implementation choices It's hard to discuss this abstractly. I don't think we have enough community experience for that discussion nor do I think we understand what this would mean abstractly well enough to have this discussion before the discussions of concrete technologies. So, I'm sympathetic to the concern, but I'm not sure I know how to do what you ask. If you want to throw something together or have a chat, we could do that. 4.1 p17: explain better what is confusing about the mutual authentication terminology It's that to some people mutual authentication implies that the client's identity is being released. In GSS, that's not true. 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. Ah, a typeo. s:if the trust:the trust 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? Note here we're talking about a physical electronic LCD whiteboard in a room, not some shared conference whiteboard software.Typically a presenter can validate the content of their own presentation. How do we deal with attacks that give different users different content? I claim that an attack that presents different content to people in the same physical room looking at the same LCD is outside of the scope of ABFAB:-) If we make the context clear--that we're talking about a networked LCD--is this example more clear? 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to explain EAP CB I agree that this document needs to discuss EAP channel binding. We propose to do that in the unwritten section 6.1 as part of the deployment discussion. I guess we could briefly discuss in section 3 as well. 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this approach? We need to adopt this approach if we want ABFAB to work with IMAP, SMTP, LDAP, SSH, NFS or a variety of other protocols that use this naming approach. We could alternatively update all those specifications and update all the implementations that use generic frameworks such as SSPI or Cyrus SASL. This is a case where following the existing standards makes deploymentand implementation easier. Can you suggest additional text for the last paragraph of this section to better clarify? _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
