70 likes | 195 Views
draft-elwell-sip-e2e-identity-important-03. IETF 74 SIPPING WG meeting. What are we trying to achieve?. The ability for a participant in a communication to know with a high degree of certainty who the other party (caller or callee) is
E N D
draft-elwell-sip-e2e-identity-important-03 IETF 74 SIPPING WG meeting
What are we trying to achieve? • The ability for a participant in a communication to know with a high degree of certainty who the other party (caller or callee) is • That information (e.g., voice, text, video) is being sent to / received from that other party • “e2e authenticated identification” • To work in a large number of practical deployments
What is the problem that is preventing this? • Intermediate B2BUAs modify signed parts of request • Modify SDP for media steering • Modify call-ID, contact, etc for topology hiding • Intermediate B2BUAs modify E.164-based SIP URIs • Canonicalization • Both practices break e2e authenticated identification as currently defined
It’s just a flesh wound! Identity
Solution requirements? • Tolerance of intermediate domains changing IP address and port in SDP (e.g., for media steering)? • Yes? • Tolerance of intermediate domains changing Contact (addr-spec), Call-Id (call-id) and CSeq (digit) header fields (e.g., for topology hiding)? • Probably? • Tolerance of intermediate domains changing domain part of From and To header field E.164-based URIs? • Probably? • Tolerance of intermediate domains changing user part of From and To header field URIs? • No?
Should we be working in this problem space? • If yes, what are the next steps?