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

[Stephen Farrell <[e-mail]>]

Hi Jim,

On 12/17/2013 05:47 AM, Jim Schaad wrote:
> Try and get my thoughts down before my mind crashes today.

I hope it doesn't crash! :-)

The trust broker/router thing is fairly minor, but if you
can word it so that it reads less like the IETF are already
planning to do stuff there, that'd be good. I don't expect
that it'll be a deal for IETF LC (but who knows;-).

Otherwise your answers look fine, thanks.

I assume the plan will be to issue a new rev before IETF LC
given the corrections for point 1? FWIW, I'd be fine if you
just wanted to fix that and handle the rest of my comments
as IETF LC comments if that helps get the new rev out more
quickly.

S.

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