We've had a lot of recent discussions about issues relating to the use of RFC 4474, and I've had a bunch of side conversations with people this week on the same topic.
Here's where I think we're at: RFC 4474 is pretty good. Since it was published, we've learned more about the problem space. In the largest part, we've learned that the authors of RFC 4474 and the working group did an excellent job of analyzing the fundamental requirements for attaching forward authentication (as opposed to challenge-response) to SIP. We've also learned that the real world has some nastiness that isn't quite covered by RFC 4474, but it appears that very small adjustments to the specification could cover most or all of the cases we've discovered. I'd therefore like to propose that the working group consider the task of narrowly revising RFC 4474 to account for four specific points: 1) Revising the "what gets signed" aspect to allow modification of the SDP by the SBCs we seem to keep encountering. While it is important to verify the SDP, we now have the DTLS-SRTP framework to vouch for the authenticity of the media channel. I suggest that there not be any optionality to "what gets signed", but that the fixed set of items be revised so as to allow SBC operations, and to note the dependency on DTLS-SRTP for media authentication. 2) RFC 4474 did not consider the requirements of calls transiting gateways and the issues related to expressing identities that originate outside the Internet, specifically phone numbers delivered via caller ID. While RFC 4474 can say nothing authoritative about the phone number, it seems that it could quite reasonably say something authoritative about the gateway. We've seen several proposals for doing this using conventions for the expression of "phone" identities in the From header field. I believe that a revised RFC 4474 is the place to document such a convention and any needed extension parameters. 3) There seems to be a valid model for what I call "stacked" Identity header fields that express transitive assertions. Consider authentication domains A, B, and C, where B is a transit domain between A and C. B would be likely to trust assertions made by A, and might not know whether C is or is not equipped to evaluate assertions made by A. However,, it might be reasonable to expect that C would be able to validate assertions made by B. B might therefore choose to validate the Identity header inserted by A, and then (assuming the header authenticates) add another Identity header using its own credentials, saying in effect "B validated A's identity header and found it good". If C can validate A's Identity header directly, it would do so. If not, it could choose to rely on B's assertion. 4) There are cases, including authentication services in the UAS and authentication services in a proxy having an "outbound" relationship (pre-authenticated persistent TLS) with the UAS where, in the absence of retargeting, an Identity header field could reasonably be included in a response as an alternative to using the more cumbersome connected- identity approach with UPDATE. I expect this to be very useful in P2PSIP, but it has broader utility. So I would like to see RFC 4474 extended to allow its use in responses where it would work. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
