[abfab] comments on draft-ietf-abfab-arch

[Mark Donnelly <[e-mail]>]

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