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

[Leif Johansson <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/abfab
>
> _______________________________________________
> abfab mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/abfab