On 09/05/2013 09:45 PM, Leif Johansson wrote: > 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?
poke... >> * 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
