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

From: Mark Donnelly <[email-masked]>
Date: Wed, 04 Sep 2013 17:09:31 -0400

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 05 Sep 2013 21:45:28 +0200

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

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Sep 2013 08:37:15 +0200

> As usual its preferable to get good reviews *before* WGLC but I guess

poke...

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 Sep 2013 14:39:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Donnelly
> Sent: Wednesday, September 04, 2013 2:10 PM
> To: [email-masked]
> Subject: [abfab] comments on draft-ietf-abfab-arch
> 
> Hello all!
> 

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

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.

>    different things, then the difference is entirely unclear, and it

Yeah - I have deleted the second sentence

>    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.)

>    "TLS" doesn't make sense to me here at all.

Should be TLS server

>    thing after a lead-in of "Even when."

The sentence now starts

When the TLS authentication is checked, ...

Does that address your concern?

> * The last sentence of section 3.4 has a typo - 'probably' should be

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