Dean, See below.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dean Willis > Sent: 13 March 2008 16:00 > To: IETF SIP List > Subject: [Sip] The thing we're missing in the RFC 4474 and > DTLS-SRTP discussion > > > We seem to agree that RFC 4474 assertions involving things that look > like phone numbers can not really be trusted, and probably therefore > should not be sent. > > However, DTLS-SRTP doesn't function without RFC 4474. > > So, if you need to use DTLS-SRTP to protect a phone call that > involves > a numeric identity (and that includes E.164, private phone numbers, > and numeric user parts of any kind), you end up having to > send an RFC > 4474 Identity header that is going to mislead people. > > So as things are currently written, one can never use > DTLS-SRTP with a > numeric userpart in the identity. > > That's the part that we absolutely have to sort out. > > We could fix this by having gateways encode their identity using a > reserved userpart. This has to have the property of saying "Do not > display this as caller-ID". Using "sip:domain" or > "sip:ipaddress" does > not work, as those might actually be valid URIs that be be displayed > as IDs. > > It might work to have the gateway use a reserved value, like > "sip:[EMAIL PROTECTED] > ". > > Or it might work to extend RFC 4474 to have a "strength of > assertion" > indicator. [JRE] If From contains something like sip:[EMAIL PROTECTED] (where mygateway is not a reserved name), that could be displayed to the user (along with a TEL URI PAI) and would indicate where the request comes from (within the SIP network). If DTLS-SRTP is used, it also indicates where media is secured from. The problem is, it lacks an explicit indicator that this is not the end domain, so it might lead a UA to make a wrong assessment of security and indicate it to the user. So there does indeed seem to be a need for some explicit indicator. I think I prefer a "strength of assertion" indicator rather than a reserved user value in the SIP URI. Maybe that could be an update of RFC 3261 to add a new parameter to SIP URI, rather than a change to RFC 4474. > > It's certainly easier to add guidance in DTLS-SRTP about what > gateways > should do and about how UASes should interpret various header fields > than it is to change RFC 4474. [JRE] Yes, but that guidance might be relevant in circumstances other than DTLS-SRTP, so we seem to have three possibilities: 1) Update RFC 4474 to include this guidance 2) Write an informative RFC to give this guidance 3) Include this guidance in DTLS-SRTP-framework. In cases 1) and 2) there could also be some discussion in DTLS-SRTP-framework, specific to that particular situation. > > However, we need to note that a standards-track document cannot say > "Use P-Asserted-Identity". That would be an unacceptable downref. It > could however say "If the identity encoded in the RFC 4474 Identity > header has the reserved userpart "pstngateway", then the UAS > MUST NOT > display this to the user as the calling party identifier. > Rather, the > UAS should use other indicators of calling party identity > that may be > available to it. [JRE] We could, of course, issue an RFC 3325bis making it standards track. I know this has been mentioned before and some people have said it would never get through IESG security scrutiny. However, the header field is in such common use, outside the initial walled garden for which it was specified, that it might make sense. > > -- > 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 > _______________________________________________ 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
