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

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
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab