[6:41 pm] * has changed the subject to: Identity Adhoc [6:56 pm]<> Mary: Normal IPR disclaimers apply.... [6:56 pm]<> Mary: This is an official DISPATCH WG Adhoc.... [6:59 pm]<> John: What I want to do quickly through what we've gone through up till now.... [7:00 pm]<> John: Various drafts published in 2008 time frame on this topic of e2e identity in SIP, the E.164 problem, identity to user agent. [7:00 pm]<> John: There was an informal design team that ended up developing a draft for IETF 74... At IETF 74 the draft got mixed feedback and there was a desire to see a requirements document. [7:01 pm]<> John: Since then things have slowed down. We produced draft-elwell-dispatch-identity-reqs-00, but wasn't at IETF 75. We got some comments, and then produced -01. [7:02 pm]<> John: Goal is "e2e identification"... needs to work in practical deployments. [7:02 pm]<> John: B2BUAs do modify signed parts of an RFC 4744 request, making it difficult to deploy. [7:03 pm]<> Cullen: Clearly RFC 4744 doesn't affect the second set (caller-ids, contacts, etc.). We were talking about requirements, no? [7:03 pm]<> Cullen: There are other ways of doing media steering, right? [7:04 pm]<> John: B2BUAs modify E.164 SIP URIs, and change the domain part, and break the e2e identification as defined in RFC 4744. This is a problem in meeting the requirements stated on the previous slide. [7:05 pm]<> We now have http://tools.ietf.org/id/draft-elwell-dispatch-identity-reqs-01.txt describing requirements, and we have solutions that either reduce the amount of information covered by the signature, signing a copy of the information, or to perform a return check... [7:05 pm]<> John: There are difficulties with E.164 in terms of whether the domain can assert ownership... E.164 SIP URIs are pretty dominant so solutions have to take this into account. [7:06 pm]<> John: We have consensus in the past that there is not much we can do with PSTN internetworking... other than authentication of the gateway. [7:06 pm]<> John: We can only trust what comes from PSTN and there are known holes with that. [7:07 pm]<> John: Where do we go from here? Are the requirements heading in the right direction? Should we try to map the solutions to the requirements? Is a generic solution possible? Or different solutions covering different use cases? [7:07 pm]<> John: I'd like to stop at this point. What do people think we should be doing? [7:07 pm]<> John: What is the interest in the subject? Have I captured the state of play? [7:08 pm]<> Jon Peterson: I think you captured fairly what has transpired.... In terms of the requirements, a lot of them seem right on, but requirement 9 is where I get into quibbles. [7:09 pm]<> Jon: The only fundamental issue is the distinction between caller identity and session identity (Section 3). If there is an interesting thing about the requirements it is which one is interesting for SIP... securing the INVITE or Offer/Answer isn't sufficient... if that's all you do you open yourself to problems. [7:09 pm]<> Jon: In terms of whether the rqeuirements are complete... it isn't enough to secure the INVITE transaction.. overall I think the document requirements are crisp and achievable though I have some issues. [7:10 pm]<> John: Please post your issues. We've had some useful comments. [7:10 pm]<> Robert sparks: I read the most recent document and found the requirements vague and incomplete. For me they don't inform the next discussion, which is to change mechanism. At the root of that is not talking about the Elephant in the Room. [7:11 pm]<> Robert: We should spell out what we are trying to solve. Surviving media steering is one small aspect... if we can write requirements that admit what we're doing, it will be easier to discuss the mechanics. [7:11 pm]<> John: We did go into more detail in the e2e enforcement draft... maybe something has been lost. [7:12 pm]<> John: If you can provide more details Robert, that would be helpful. [7:12 pm]<> Jim McCatrin, Nortel: In terms of Elephants in the Room, were you talking about B2BUAs? [7:13 pm]<> Robert: Yes. I am entering into a SIP dialog with a thing, and trying to pass my identity through that thing.... [7:13 pm]<> Jon Peterson: I hope other people have a lot to say... if the requirements were cast in that fashion my interest would decline.... if we casted them in terms of communicating an identity through a Man-in-the-Middle it would be less, not more interesting. [7:14 pm]<> John: Some people say the requirements are so vague and prefer the e2e enforcement draft... others like the ones we have in -01. [7:14 pm]<> Jon: If the requirements are casted in terms of how to enable a man-in-the-middle in the SIP architecture that isn't acceptable to me. [7:15 pm]<> John: The B2BUA can be a man-in-the-middle, but hopefully not in a harmful way.... [7:15 pm]<> Jon: If you remove enough protections so B2BUAs can do their job, then you are enabling bad guys to do things, too. [7:17 pm]<> Cullen: REQ4 - It MUST be possible for a called user to receive caller identification that includes the calling user's domain and the calling user's name or telephone number within that domain. [7:17 pm]<> Cullen: Are we saying that there is no requirement for this to work with PSTN? [7:17 pm]<> John: Yes. [7:17 pm]<> Cullen: We don't have a way of describing that -- you had said "the name of my Bank". [7:17 pm]<> Jon: We carry a domain part in a URI [7:18 pm]<> Cullen: From a human factors point of view -- what is the domain of Bank of America? They may have hundreds? How do we know? It has been discussed in the certificate world. [7:18 pm]<> Cullen: I don't disagree with the requirement... but the domain is not what you meant, you want the domain of the bank. [7:18 pm]<> Jon: You have the issue with HTTPS... [7:19 pm]<> Cullen: In HTTPS they have certificates which include names, logos, etc. It's not a domain! [7:19 pm]<> (Someone is mumbling) [7:20 pm]<> Jari Kutan: A question to Cullen: how do we want to go with the example? About whether we shall require identification of an institution (like a bank) or a domain. What happens if I give you a name like "Bank of America" or a logo it might not be *the* Bank of America. [7:20 pm]<> Jari: What level of generality are we aiming at? [7:21 pm]<> Jon Peterson: It's an interesting question. In the RFC 4744 architecture the SIP URI has something it is supposed to correspond to. The point that Cullen is raising is that for telephone numbers you lack that. [7:22 pm]<> Jon: Should I be able to look up in the ENUM Oracle that this matches Bank of America? I don't think that's a solveable problem. [7:22 pm]<> Jon: There is no way to derive something from a telephone number. [7:22 pm]<> Jon: Even for E.164 numbers, RFC 4744 does tell you the domain that it comes from. [7:23 pm]<> John: It doesn't tell you what the number is for, but it does tell you the domain. [7:23 pm]<> John: Knowing it's from "yourbank.com" is useful. [7:23 pm]<> Jon: The telephone number is inert. [7:24 pm]<> Cullen: The right way to get these requirements right is to keep the assertions tied to the style of names... email style addresses and E.164 numbers... adding an organization concept expands the scope beyond what we can solve now. [7:24 pm]<> John: Even E.164 names do have a domain part, which can be useful. [7:25 pm]<> Cullen: Let's not confuse that with the name of the bank.... [7:25 pm]<> Cullen: One of the other requirements...REQ6... REQ6 - It MUST be possible for a called UA to verify such an [7:25 pm]<> assertion based on a trust anchor, such as a CA certificate. [7:26 pm]<> Cullen: This isn't a requirement, it's a solution. [7:26 pm]<> John: We can fix this. [7:27 pm]<> Dale Worley: Was just thinking about B2BUAs... the infamous bete noir... if I can start being philosophical... each router can be a man-in-the-middle.. the purpose of the security mechanism is to put the endpoints in the position that they don't have to trust the routers... it's the same requirement for B2BUAs... a mechanism so that we don't have to trust the B2BUAs and which will work with the B2BUAs that are deployed... there are tricks for tunneling through middle boxes that want to modify information. [7:28 pm]<> Dale: This gets us out of the problem of whether we love B2BUAs or not. If we capture the requirements in these terms, the dispute is largely eliminated. [7:29 pm]<> Jon: What you say is correct, Dale. If we could articulate a scope of agency for B2BUAs, we could describe a scope to handle it... if we could limit what they can do or not do... the purpose of these devices is to engage in behavior that is non-standard and non-constrained. Some B2BUAs may need to change the contact header... it is utterly unconstrained. The limitless agency makes this an intractable problem. [7:30 pm]<> Jon: An SBC vendor had said at IETF 74 that they would be willing to delimit the things that can and can't be done by a B2BUA. The reality is that a B2BUA could discard whatever you try to tunnel through.... [7:31 pm]<> Dale Worley: Dale Worley again. As I love to say to people: "you are overlooking exactly what I said". I said "as they existed". The question isn't whether we can define what B2BUAs are permitted to do... it's about getting something that works with what B2BUAs do today... or what we can prod them into becoming. It's worth looking into. [7:32 pm]<> Jari Kutan: I am wondering if you think this is a feasible approach... I will give a specific example of running code. They violate SDP to steer media to them... it's easy because you don't have to implement TURN/ICE... [7:33 pm]<> Jari: For the sake of NAT traversal there is contact re-writing, SDP re-writing... this is "best current practice" though it may seem absurd to call it that. [7:34 pm]<> Jari: This is what is happening. Should we put our head in the sand? [7:36 pm]<> John: We picked on media steering as the key thing to solve... it might not be the only aspect that interferred with e2e identity. We're not sure whether we need the solution to work with other changes, too. [7:37 pm]<> Dale: If you construct a mechanism that starts being used enough... then the B2BUA vendors will discover it is a market requirement. [7:39 pm]<> Adam Roach: There are SBCs that are already deployed... people won't upgrade them. We went down this path with NATs... made naive assumptions... came out with STUN... then Cullen tested NATs and found we got it all wrong. [7:39 pm]<> Adam Roach: NATs didn't work the way we had naively thought they did... we need to learn from that! If we're going to put specifications in place that are trying to work around deployed behavior... we need to have buyins from vendors that this is what they actually do... rather than making naive assumptions and getting it wrong yet again. [7:40 pm]<> Jon: If we can identify the common core of behavior that we see in the field, to describe not prescribe, that would be sufficient to determine if new stuff would be retained by the SBCs. [7:41 pm]<> Jon: How many SBCs would regenerate the Identity behavior? What is their incentive to do this? SBCs are sold like firewalls (edge security, checking requests for validity). Any features we add are in effect competitors to SBC functions. [7:41 pm]<> SBCs are competitive to French Fry makers... they can be all things to all people. [7:42 pm]<> Jon: There are sane products that are scoped... there are things doing NAT traversal... if we can assume that the only things that SBCs modified were certain headers.... we'd be having a different discussion. But any mechanism we are adding is something they can modify. If we try to tunnel... that mechanism would be equally susceptible to modification! [7:43 pm]<> Jari Kutan: I am not interested in traversing SBCs as such.. since I don't know what it is. But I am interested in traversing NATs. [7:44 pm]<> Jon: if we scoped the problem to having identity survive what is done for NAT traversal it would be solveable.... [7:45 pm]<> Cullen: NAT traversal is handled via media relay in SBCs, where the phone is talking to the SBC (maybe even by using STUN), putting correct stuff in the SDP from phone's point of view. This works securely. There is also media latching, where the first packet that comes through causes you to discover something.... but if someone wrote that up it wouldn't pass through BCP 44, even though it has been deployed (though less so now than before). [7:45 pm]<> Cullen: I'm fine with a requirement saying that NAT traversal is a requirement. RFC 4744 thought that was a requirement, too. [7:46 pm]<> Jon: I hate to turn this into a "black helicopter" discussion... it is easy to cast the problem in a way that it's unsolveable. [7:47 pm]<> Jon: John Elwell has thanklessly carried this burden... it's been like pulling teeth... and has gone on for years... [7:47 pm]<> John: Can we characterize B2BUA problems we're trying to solve in a sufficient way so that we can create a solution that will get around them now and in the future, and whether this is a solveable problem. We still don't have consensus. [7:48 pm]<> Jon: We can make a standard that addresses standard set of behavior... but creating a standard to deal with non-standard behavior (SBCs) is much harder. [7:48 pm]<> John: We need to get more information about SBCs. [7:48 pm]<> Mary: let's give Hadriel the action item. [7:48 pm]<> Jon: We gave Hadriel the action at IETF 74! [7:49 pm]<> John Elwell: Are there SBC vendors ready to take this on? [7:49 pm]<> John Elwell: Do people agree we have a problem? [7:49 pm]<> John Elwell: Or do we need to state the problem another way? [7:49 pm]<> Mary: Let's do a hummm...... The question is: does anyone disagree that we have a problem? Noone disagrees. [7:50 pm]<> John Elwell: It has been suggested that we need to map solutions to requirements. Or is this premature? We've had some comments that suggest that. Maybe the next step is to work on requirements? [7:51 pm]<> Hannes: I think that the issue is that as previously elaborated on, we don't know what the underlying constraints are.... this is challenging. [7:52 pm]<> Hannes: Someone would have to expend the effort to describe what is done today... the other approach is to randomly standardize something... and hope that people will change their SBCs so it would work... this is less effort for us! [7:53 pm]<> Hannes: I can tell you from Identity Management, signature generation is hard... so they don't generate a signature and came up with B-Asserted-Id instead. [7:53 pm]<> John: Next step is to work more on requirements. [7:53 pm]<> Mary: Hopefully there will be more discussion on the list.