[abfab] AD review of draft-ietf-abfab-arch-09

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 16 December 2013 16:29 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C741AE351 for <abfab@ietfa.amsl.com>; Mon, 16 Dec 2013 08:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw9Xc0yBOMU7 for <abfab@ietfa.amsl.com>; Mon, 16 Dec 2013 08:29:02 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D5A281AE2F5 for <abfab@ietf.org>; Mon, 16 Dec 2013 08:29:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E99A9BE61 for <abfab@ietf.org>; Mon, 16 Dec 2013 16:29:00 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31MFbnGHYy1f for <abfab@ietf.org>; Mon, 16 Dec 2013 16:29:00 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6F0CBE5F for <abfab@ietf.org>; Mon, 16 Dec 2013 16:29:00 +0000 (GMT)
Message-ID: <52AF2A4C.5000304@cs.tcd.ie>
Date: Mon, 16 Dec 2013 16:29:00 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "<abfab@ietf.org>" <abfab@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [abfab] AD review of draft-ietf-abfab-arch-09
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2013 16:29:04 -0000

Hiya,

Thanks for a useful document!

I have a few things I'd like to check with the WG before
starting IETF LC and a bunch of nits (which can be fixed
whenever).

I'm not sure if the non-nits will result in changes being
needed before IETF LC, but wanted to raise them and will
follow the WG chairs' conclusions as to whether a new
draft is better or not.

Thanks,
S.

non-nits:

(1) Am I reading this right? 4.2.2 says: "The EAP MSK is
transported between the IdP and the RP over the AAA
infrastructure, for example through RADIUS headers.  This
is a particularly important privacy consideration, as any
AAA Proxy that has access to the EAP MSK is able to
decrypt and eavesdrop on any traffic encrypted using that
EAP MSK (i.e. all communications between the Client and
IdP)." Does that mean that if a client authenticates with
a password say, then that password could be read after
the fact by any RP or AAA proxy involved in the
transaction.  Wouldn't that be unacceptable, if e.g.  the
equivalent of web-bugs or trackers could be inserted into
a UI so as to get first-shot before a user has
authenticated?  And that seems to contradict step 7 in
1.4 unless those messages also go via the RP, which is
not shown in the diagram in 1.4.  What am I missing?

(2) Aside from (1) above, do you need to highlight the
issue with MSK leakage more prominently? 6614 is
experimental and probably not that widely deployed, so
this may be a significant issue.  While it will be ok for
some applications and will be better than not getting
access whilst e.g. roaming, an eduroam user or
institution might or might not be happy that a given
application (say exam marking) could be vulnerable in
this way. And if ABFAB were to be adopted by telcos, then
given their history, and the reported lack of deployment
of Diameter security, (for which I wish I had a good
reference), I think the potential issues with pervasive
monitoring that this could create might then be
problematic.  In 2.1.5, modifying proxies seem to be
given similar powers to someone to whom the MSK leaks,
and so are probably similarly relevant here. The
definition of mutual auth in 3.1 also seems to skirt
around this by saying that the initiator and acceptor
have the same key but by not saying that nobody else
(except an IdP or key server) should know that key.
However, I'm not sure where or how handling this would
best be done. Has the WG considered that?  (I'm not
insisting on a super-great answer here, just checking and
wondering if more needs to be said.)

(3) How should this portray the ABFAB work on Diameter?
It seems like that is not going to happen, but 2.1 refers
to it as a work-in-progress (without an I-D to
reference).  I think it'd be better if this document said
that Diameter could be used and would work with this
architecture but that RADIUS is what is being used. Then
you'd tweak the references to Diameter a bit.

(4) ABFAB puts together a bunch of generic technologies
in a way that can work to allow cool new stuff to be
done, which is great.  However, it also creates concerns
that if I put that same bunch of technologies together in
other ways, which is possible, the results might be less
good, security-wise or interop-wise.  Reading the 3rd
last para on page 22 ("The RAIDUS SAML RFC...")
highlights this for me.  Should something be said about
how robust or brittle a system conforming to the ABFAB
architecture might be when other variations of these
technologies are chosen or considered? If you say, "nope,
its fine," I'll buy that and if someone thinks its not
fine they can make an IETF LC comment.

(5) You mention "the trust router" protocol in various
places (some noted as nits, but e.g. 1.2). We don't know
if there will be zero or one or more of those (and
there's no citation). I think you should maybe fix those
so as not to create an apparent dependency on something
that's not an agreed piece of IETF work.

(6) 1.2: "legal rules" seems wrong, I think you mean
non-technical contractual agreements. I'd prefer if the
word "legal" was never used as it might be interpreted
very differently by different readers in different
jurisdictions. In some places, it might have a
connotation that the Government say its illegal to not do
this, or that its illegal to try access an RP to which
you're not authorized or something. Better to avoid that.
(This is almost, but not quite, a nit.)

(7) 4.x - is there a missing section here about the
relationships between different RPs in the same or
different realms?  To what extent can they cheat on one
another, with the various options that exist?

nits:

abstract: "work has occurred" is passive voice

abstract: "common building blocks in common" is odd

abstract: Is "GSS" right? I've seen GS2 and GSS-API
before but not GSS.

intro: "Internet uses ... mechanisms" seems wrong, the
IETF (and others) define mechanisms and operators deploy
those

intro: "This delegation requires technical signaling,
trust and a common understanding of semantics between the
RP and IdP." I hate to see unqualified uses of the term
"trust" but it might be ok here I guess. If its possible
to say more about who's trusting whom for what here
that'd be better though.

intro: Doesn't federated anything really require there to
be >1 IdP? If so, why not say so?

intro: "Simplified Sign-On" is a new one to me and sounds
like a marketing term, if so, it'd be better left out

intro: Is the indentation right for "Data minimization.."

intro: The last para before 1.1 claims that this will
scale to large numbers of everything - is there evidence
of that? If not, then better to not make the unfounded
claim.

1.1: Predicting problems readers will have is odd.

1.1.1: "provide" naming semantics seems wrong

1.1.1: typos: "mutualtion" "confiduatal"

1.1.1 last para: so I don't get this description.  That's
not helped by a couple of odd typos, but I think it'd be
worth another look at this to try make it clearer.

1.2: "There is a direct relationship between the Client
and the Identity Provider by which the entities trust and
can securely authenticate each other." reads oddly to me.

1.3: "proliferating" federations seems a bit exaggerated.

1.3: "the use of SMTP and IMAP protocols do not have the
ability for the server to get additional information"
seems badly phrased.

1.4: step 2 - passive voice - who selects GSS-EAP? Or is
that negotiated between client and RP?

1.4: step 5 - the RP only knows which IdP is claimed at
this point, not which it "is" - better to clarify?

1.4: it'd be better if the figures were all numbered, the
ladder diagram here is not

1.4: ladder diagram (11) spacing is broken

1.5, 1st bullet: s/of a transaction/in a transaction/
maybe better?

1.5, 2nd bullet: decoupled from what?

1.5, 3rd bullet: s/servers/RPs/ more accurate?

1.5, s/excitement/trend/ would be more neutral

section 2, 3rd para: wording is not great, maybe s/for
encapsulating/to encapsulate/ and s/the usage of// and
s/a description of// would be better

2.1: May as well use IdP here and not "Identity Provider"

2.1, last sentence before 2.1.1: better to omit this or
add a reference to something (doesn't have to be an I-D,
a workshop paper or similar would be fine).

2.1.1: why "Interestingly"? I don't know why you told me
that and it makes me wonder if some would claim that this
was not successful.

2.1.1: "mileage" is an odd term here, smacks of
sales-talk

2.1.1: s/a future document would/a future document could/

2.1.2: s/criteria/criterion/g in 1st para after 1st
bullet list

2.1.4, 1st para: Its mostly yukkie to end a sentence with
a preposition like "of" :-)

2.1.4: s/have designed in/include/

2.1.5: You say that it won't always be possible for an RP
to verify a signature on an assertion. I think that was
the subject of list discussion, but don't see that
reflected here.  Should you explain some more about why
this is likely to be the case?  The reader may wonder
otherwise.

2.1.5: Saying "different namespaces assigned to the same
name" reads oddly if you don't have SAML stuff at the
front of your brain - maybe this could do with some more
explanation for those who've forgotten SAML terminology?
And maybe a reference to something that goes into the
detail would be good too.

2.1.5: modifying proxies - why is it "obvious" that
they'd remove signatures - wasn't that also the result of
a list discussion that was not obvious? (And in principle
the proxies could add to the assertion or add a new
assertion or something, leaving the original verifiable.)

2.2.1: I don't get what "where Individuals can correctly
identify the entire mechanism on the fly" might mean -
can you explain or make it clear?

2.3.1: Wouldn't it be better to distinguish between those
GSS-API using applications that are real vs. those where
how to use GSS-API is well-defined, but never used? I
think for example that 3645 is not really deployed (but
correct me if I'm wrong).

2.3.1: Is "no required modifications" really true? While
I might not have to modify application layer code, won't
I probably have to write new packaging, do new testing
and management etc? That's not free either.

2.3.2: s/privacy/confidentiality/ would be better

2.3.3: would s/server/RP/ be right here? If not, then
maybe you

3.1, 2nd para: maybe s/it/mutual authentication/ would be
better just before the bullets

3.1, last sentence: Be good to add a reference to the
anonymous return flag so someone can go figure out what
that means in more detail. I just mean a section number
of whatever RFC defines this.

3.2: I guess add a ref to 5246 somewhere

3.3: I'm not sure if there are missing references here or
if they've all been given earlier - be good to check e.g.
are all the RFCs for GSS-API for foo somewhere? And maybe
DNSSEC and NAPTR etc are missing refs.

3.3: Is RFC 1964 right for kerberos/GSS or 4121?

3.4: Be nice to add refs for the non-IETF protocols that
will use stuff in the near future.

4.1: s/can reside on any/can reside on any or all/ might
be better, given recent news. You should also note that
nodes might collude or be coerced into colluding.

4.1: Another missing ref to Trust Router. Maybe add ref
or delete that.

section 7: I wish we could get more comments from Bob
Morgan.  Makes me sad that we cannot.