[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.
- [abfab] AD review of draft-ietf-abfab-arch-09 Stephen Farrell
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Sam Hartman
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Stephen Farrell
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Sam Hartman
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Stephen Farrell
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Jim Schaad
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Stephen Farrell
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Sam Hartman
- Re: [abfab] AD review of draft-ietf-abfab-arch-09 Stephen Farrell