Identity (DISPATCH) Ad Hoc – Nov 9th, 12:00-13:00
Chairs: John Elwell, Mary Barnes
John reviewed the history of this activity.
What are we trying to achieve here? Want to have a reasonable level of confidence that you are actually talking to who you think you are talking to, and that you are in fact receiving media from them. This is further complicated by the fact that B2BUAs modify signed parts of the request, which can break the end to end authentication. Cullen objected to presenting this as consensus, and John clarified that it was a summary of what he had presented in the past. Objective today is requirements. These include:
Difficulties with E.164 numbers, cause the domain cannot assert ownership. Given the prevalence of E.164 numbers, any solution must include these.
The scope of this does not cover the PSTN, but only up to the PSTN interworking point.
John asked what we should do next? Try to combine the various partial solutions, or…?
Jon Peterson said that he thought John had fairly captured the status, and the requirements were reasonable. He was unsure the document clearly articulated the differentiation between securing the invite transaction and securing the entire user communication experience. But overall Jon thought it was a very good document and summary of the problem.
Robert Sparks thought disagreed, and thought the requirements were too vague, and therefore did not give us what we needed. He thought we needed to clearly talk about the Elephant in the room. For example, we need to talk more specifically about the problems created by things that create another instance of the communication, and then transfer it over to another instance (B2BUAs are an excellent example of something that does that.)
Jon Peterson strongly objected to this, and said that if we remove enough security mechanisms to allow good guys to function this way, then we will have also allowed the bad guys to do the same thing. Jon is arguing that E.164 numbers are completely out of sync with the entire Internet concept, so it inherently complicates and limits what you can do with them here. Jon did allow that as long as we scope what we are trying to do with this information, to keep it very narrow, then he might agree with John Ewell. But he said that the current wording does not do that, and so needs to be
Cullen gave an example where a solution was effectively embedded into the requirements, and he asked that all the requirements be rewritten so that they do not imply any solutions. Cullen will work with the authors offline to give some examples.
Dale Worley said that these mechanisms have been designed so that we do not need to trust the B2BUAs, and that if we recognize this in the requirements, then we will be ok.
Jon Peterson said that if the designers of B2BUAs would fully agree with what they were allowed to do, then he would agree with this. But the problem is that the inherent concept of a B2BUA is for it to by completely unbounded.
Jim McEachern asked if it was possible to turn the problem around and capture a specific list of B2BUA functions that our identity mechanism will work with, but that anything else will not be guaranteed to work.
Adam Roach pointed out that we need to learn from past mistakes. With STUN we defined a solution that worked for how we thought NATs worked, but then when Cullen went out and bought every NAT he could find, we discovered that we were incredibly naive. As a result, STUN is now being used for a completely different purpose.
Jon Peterson said that if we could even capture what SBCs do today and define a solution to work around that, it would might be plausible. But the problem is that there is no guarantee that they would stay with that functionality. In fact, their value proposition almost guarantees that they will not stay with it. In fact, any mechanism that we define will probably be modified by SBCs in the future.
Jon said that the problem is how to cast this in a problem statement that we can all agree with. This is a thankless problem that John has been trying to work for us.
John: Can we characterize B2BUAs in a way that allows us to solve the problem, and even if we do, will it survive in the face of ongoing things the B2BUAs will continue to do. So, given this, what do we want to do next?
Do we agree we have a problem?
Agreement that we do have a problem.
What should the next step be?
… no point in mapping solutions until we all agree on requirements. So the next step is to work the requirements until we have better agreement.
Who is willing to be involved?
Several people identified in the discussion.
Is it appropriate to keep this as a DISPATCH topic and try to take more positive steps in IETF77?