Hello all!
I work with Sam, who asked me to read the arch draft as background to
implementing some software around ABFAB.
* 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
