-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/10/11 7:27 PM, Sam Hartman wrote:
Hi Sam, > 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. sure, I was wondering if it was your intent to put a stake in the ground in this doc or not. > > 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. true... perhaps kick of 3 with it and then start explaining it as you go in 3? > > 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. No, I understand what you say, I was pondering the same before I typed my comment. But I think it would be good for the reader to understand what *functionality* we need to provide versus *how* we provide that functionality. I like the separation of concerns in 3, perhaps good to state them in the introduction and link them to the technology choice we made without further explanation in this chapter? > 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? sure, this was really a discussion topic. > > > 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. hmm yes, I'll have a look and see if I can come up with a proposal > > 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. ok, I think it is fine to just say that then. > > > 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? absolutely! I was indeed thinking of a conference WB > 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. right, that makes sense, and should be stated > Can you suggest additional text for the last paragraph of this section > to better clarify? I'll try Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0rfA0ACgkQH2Wy/p4XeFKmfQCfd+rw+BGXoYsbRlf+qN60nUb/ aaUAmwT3f0mbrQgXmevyYk1rQhFziK/o =etSd -----END PGP SIGNATURE----- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
