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

["Jim Schaad" <[e-mail]>]

Try and get my thoughts down before my mind crashes today.

> -----Original Message-----
> From: abfab [mailto:[e-mail]] On Behalf Of Stephen Farrell
> Sent: Monday, December 16, 2013 8:29 AM
> To: <[e-mail]>
> Subject: [abfab] AD review of draft-ietf-abfab-arch-09
> 
> 
> 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?

As noted by Sam, this is just wrong text.  

However to address the rest of the questions here:

All traffic between the client and the IdP are routed through the RP.  This
means that if you are using a password based EAP method without having a
tunnel as part of it, the password is going to be available to the RP and
all of the AAA routing structure to read.  If you look at Figure 2, then you
see all of the messages traveling via the RP.

>From the point of view of EAP and the MSK however, a password would never be
protected by the MSK as this is created after the password is validated and
thus could never protect the password to begin with.  It would be used to
protect data sent back and forth after the password has been validated.

Proposed changes:

1.  In the figure of section 1.4 - s/Between Client App and IdP/Between
Client App and IdP (via RP)/

2.  In section 4.2.2 s/(i.e. all communications between the Client and the
IdP)./(i.e., all communications between the Client and the RP).  This
problem can be mitigated by applications setting up a tunnel between the
Client and the RP and performing  a cryptographic binding between the tunnel
and the MSK./

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

6614 is experimental, but there are efforts to put it onto standards track.
>From my understanding, it is implemented in most of the major RADIUS
implementations.  I am not sure what the status of deployment is on this.
The fact that there is a draft to help with doing lookup in the RADEXT group
would indicate that there are some issues to getting it out for large
deployments.  However I am not sure that there is anything that we can
really say or do to address this issue directly.

I think that the mitigation text that I have suggested above will help in
addressing the MSK leak as it gives a way to avoid letting entities do the
eaves dropping, it is a much more active attack for an entity to decide to
replace the RP and get the information in that stream.  

The problem of monitoring what goes across the backbone is a larger problem
than we can address.  We have recommended that EAP-TLS be used to reduce the
amount of material that can be leaked in terms of the EAP conversations.
This would address both RADIUS and Diameter in terms of client/IdP but do
nothing about the RP/IdP data.  I don't know of any way to fix that except
to do point to point security on the backbone (or go direct with something
like a trust router).

I am not sure that there is anything to be added to the document at this
point.

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

I think that this makes sense to do.  It should be a couple of easy changes
- I'll try and look at this over the next day or two.

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

I would rather not try and do this.  To do it in a semi-exhaustive method
would be both time consuming and require that we basically describe other
ways the pieces could be fit together badly.


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

Currently the phrase "router" is used in two places. Section 1.2 and section
4.1.   Oddly enough, the same concept is called a Trust Broker in section
2.1.3.   Would you have the same feelings about the term Trust Router if it
was turned into Trust Broker (and pointed to section 2.1.3 then)?


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

I have no opinion one way or the other on this issue.

> 
> (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?

I have vague memories about thinking on this at the time I was trying to get
this section figured out.  However I don't think I came up with anything
that I thought was worth nothing.  I'll put it in the back of my brain for a
couple of days.

Jim

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