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

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 16:29:00 +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.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Dec 2013 11:48:28 -0500

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

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

Fortunately, I think you're reading this slightly wrong.
Learning the MSK is not sufficient to snoop on traffic  between the
peer/client and IDP.
Only on traffic between the peer/client AND RP.

The issue is that if the peer-client use the MSK to encrypt traffic say
using the GSS per-message services or the GSS PRF, that an attacker who
learns the MSK can decrypt that traffic.  They should not (and with EAP
methods that are typically used are believed to be unable to) learn keys
needed to observe the authentication conversation between peer/client
and IDP.

honestly, I consider proxies being able to observe session traffic to be
quite bad from a perpass standpoint, thus my interest in adding DH
between client/peer and RP.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 17:31:32 +0000

Hi Sam,

> between client/peer and RP.

So when the text says "(i.e. all communications between the Client
and IdP)" I don't get what that means. Is it just a typo maybe?

S.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Dec 2013 12:39:20 -0500

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> So when the text says "(i.e. all communications between the
    Stephen> Client and IdP)" I don't get what that means. Is it just a
    Stephen> typo maybe?

O, I thought the I.E. was added by you.
Yes, that's just wrong.
Sorry I missed that on my review pass.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 17:40:44 +0000

> Sorry I missed that on my review pass.

Ah good. That sorts that one. Probably worth fixing
before IETF LC as it might also confuse others.

S

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 16 Dec 2013 21:47:30 -0800

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

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

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

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

> 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: 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.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: "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.5, 1st bullet: s/of a transaction/in a transaction/ maybe better?
> 
> 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, 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.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.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.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.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.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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 09:58:18 +0000

Hi Jim,

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Dec 2013 14:33:25 -0500

Couple of points.

Note that the MSK is encrypted even if you don't use RADIUS over TLS.
The encryption is questionable (md5 as a stream cipher) but might
randomly happen to be good enough for encrypting a randomly chosen key.
for myself I'll choose to deploy with TLS rather than trusting that:-)

I don't mind removing the trust router references, but I also don't
think it is problematic to leave them in.  This document points out
there are multiple ways of solving the trust router solves.  I think
it's fine to note that people are working on the trust router, one
specific manifestation of the trust broker approach for managing the
connection between RP and IDP.  Other approaches are discussed besides
the trust broker deployment pattern.
So, I don't think there's a dependency creater or implied.
On the other hand, I don't mind removing the reference either.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 21:03:18 +0000

> for myself I'll choose to deploy with TLS rather than trusting that:-)

Yep.

> On the other hand, I don't mind removing the reference either.

Fair enough. So long as its sorta consistent and doesn't over
promise it'll be fine.

S.