[Sip] Proposal to Revise RFC 4474

[Dean Willis <dean.willis at softarmor.com>]

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip