On 09/04/2013 11:09 PM, Mark Donnelly wrote: > Hello all! > > I work with Sam, who asked me to read the arch draft as background to > implementing some software around ABFAB. As usual its preferable to get good reviews *before* WGLC but I guess we'll not stand on form.
Jim - your views? > > * Section 1.1.1 (Channel Binding) mentions "the authenticator" without > referencing that anywhere earlier. Sam tells me that is the EAP term > for what ABFAB calls the RP, but that's not included in the table in > section 1.1. > * In section 1.2, it would be nice for a break to be inserted before > the ASCII art graph. > * Also in section 1.2, in the section about Federation, there are two > almost identical sentences: > The federation relationship is governed by a federation agreement. > A federation is governed by a federation agreement. > If these say the same thing, one should be removed. If they say > different things, then the difference is entirely unclear, and it > should be explained. > * In section 1.4, points 8, 10, and 12 talk about the Master Session > Key. As someone new to this, the MSK was referenced here without any > text suggesting why it exists. Perhaps a forward reference to > Section 4.2.2 or 5 would help, but there really doesn't seem to be a > good explanation in the document. > * Section 3.2, in the fourth paragraph, has a sentence saying: > The client and the TLS need to share a common trust point for the > certificate used in validating the server. > "TLS" doesn't make sense to me here at all. > * Later in section 3.2 there's a sentence: > Even when it is checked, if the trust infrastructure behind > the TLS authentication is different from the trust infrastructure > behind the GSS-API mutual authentication then confirming the end- > points using both trust infrastructures is likely to enhance > security. > The lead-in to that sentence made me expect the opposite result. In > essence, this sentence says, "Even when we do the right thing, the > right thing happens." I was expecting one of them to be the wrong > thing after a lead-in of "Even when." > * Section 3.3, paragraph 8 contains a sentence: > When Service Records (SRV) and Naming > Authority Pointer (NAPTR) records are used to help find a host that > provides a service, the security requirements on the referrals is > going to interact with the information used in the service name. > The minor quibble here is that the subject (requirements) disagrees > in number with the verb (is). My larger difficulty is that I have no > idea how security requirements might interact with service name > information. > * The next sentence: > If a host name is returned from the DNS referrals, and the host > name is to be validated by GS-EAP, then it makes sense that the > referrals themselves should be secure. > This sentence establishes the need for secure referrals, but nothing > is said about how that is to be achieved. > Also, the typo of "GS-EAP" should be corrected to "GSS-EAP." > * The last sentence of section 3.4 has a typo - 'probably' should be > 'probable.' > > Thanks, > --Mark Donnelly > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
