I am having a problem understanding what is being said here. The case that we are in here is
1. The initiator knows the realm it wants the acceptor to be in, but it does not tell the acceptor that 2. The acceptor does not know which of multiple realms the initiator wants to connect to. If the initiator does not know the realm of the acceptor, then it does not matter what realm is returned by the acceptor. If the initiator tells the realm to the acceptor, then it should always know what to send back. If the acceptor returns a different realm that it gives to the IdP, then channel binding would fail or the initiator would fail. As long as the acceptor returns a consistent value then there should not be any problem. If the acceptor does not return a realm, but gives one to the channel binding, then a channel binding failure could be expected if it uses the wrong one. I don't know that there is any way to say that we should send multiple different realms to the IdP to say that I could be any of the following. What problem is being solved by your proposed errata? Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Friday, September 21, 2012 10:09 PM > To: [email protected] > Subject: [abfab] Implementation concern: acceptor name response in > extensions state and realm > > > Hi. > Luke discovered a bit of a problem. > Jim proposed that acceptors echo back their name rather than simply relying > on the name match in channel bindings. > The intent is to prevent a malicious actor from being able to connect one > GSS-EAP peer to another in a situation where channel binding is not > enforced properly. > That is, we want man-in-the-middle defense always even if we're not going > to get malicious NAS defense because channel binding is not happening. > > The issue is that the initiator and/or acceptor may not know the acceptor's > realm yet. > > My recommended implementation strategy is that if the realm name is > present on both the initiator and acceptor it must match. > Luke notes that it is easier to compare ignoring the realm. > I'm concerned that for some realm-based services that might allow > substitution of one realm for another. > > Either way, I think it's probably too late in the process to do anything about > this in terms of spec text. > This will probably be our first Erato. > However I'd like to get community input on what implementations should > do. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
