> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Monday, January 10, 2011 10:28 AM > To: Klaas Wierenga > Cc: [email protected] > Subject: Re: [abfab] draft-lear-abfab-arch-01 posted > > 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.'
Are we looking at SOAP as a message format or at SOAP as a transport ? I don't think that they are necessarily the same thing. > > 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. I am in favor of having some diagrams really early in the processes. I think this really helps to get understanding setup early. But I tend to be a very pictorial person. > > 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. The discussion may also need to include problems with matching names. If you have a TLS DNS name and you have some type of Kerbros realm name - they may not be the same name but still be the same entity. > 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
