> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Mark Donnelly
> Sent: Wednesday, September 04, 2013 2:10 PM
> To: [email protected]
> Subject: [abfab] comments on draft-ietf-abfab-arch
>
> 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.
I have put EAP Authenticator into the table and inserted EAP in front of the
word authenticator in the four places it occurs
> * In section 1.2, it would be nice for a break to be inserted before
> the ASCII art graph.
Generally page breaks are dealt with during final editing by the RFC editor
- we will make sure that the image is on one page at that point in time.
> * 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.
Yeah - I have deleted the second sentence
> * 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.
Would this change fix the problem for you?
Old:
As a result, the client and the IdP hold two cryptographic
keys: a Master Session Key (MSK), and an Extended MSK (EMSK).
New:
The EAP authentication process also results in both the client and
the IdP having two cryptographic keys: a Master Session Key (MSK) and an
Extended MSK (EMSK). (EAP methods which do not derive an MSK cannot be used
with ABFAB.)
> * 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.
Should be TLS server
> * 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."
The sentence now starts
When the TLS authentication is checked, ...
Does that address your concern?
> * 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.'
Does the following replacement paragraph address your concerns?
Applications may retrieve information about providers of services
from DNS.
Service Records (SRV) and Naming Authority Pointer (NAPTR) records
are used to help find a host that provides a service, however the necessity
of having DNSSEC on the queries depends on how the information is going to
be used.
If the host name returned is not going to be validated by EAP
channel binding, because only the service is being validated, then DNSSEC is
not required.
However, if the host name is going to be validated by EAP channel
binding then DNSSEC needs to be used to ensure that the correct host name is
validated.
In general, if the information that is returned from the DNS query
is to be validated, then it needs to be obtained in a secure manner.
Jim
>
> 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
