Attached find the notes of the last conference call of the interested parties on progressing the identity issues in SIP, held on 17th Feb 2009. Expect a revised version of draft-ietf-sip-e2e-identity-important shortly.
If anyone is interested in joining these discussions, send me a mail and I will include you in the details for the next call - we currently expect one more before the IETF meeting. regards Keith ------------------------------------------------------------------------------ Present: Keith Drage Hannes Tschofenig Dan Wing John Elwell Dan York >From the previous meeting notes: > Ihe call came up with some areas where the document should be revised > and John would attempt to capture those suggestions in a revised > version of the document. Target date for new version of the document > was 10th February so it could be discussed on our next call on 17th > February. John made a plea for input to the draft in the form of words > targetted at the draft. So far John had not issued the revised version (draft-ietf-sip-e2e-identity-important) as he had not yet had sufficient input for the revised version. A reminder on the mail list shortly before the call had produced some ideas. John presented the changes he had made so far to the draft, which had not yet been circulated. John had added a table at the end of the use cases part of the document as requested in the last call. The conclusion had also been split into a conclusion for email style identities and one for E164 style identities, also as requested in the last call. A statement would also be added that end-to-end identity is not achievable where the PSTN is involved. John commented that he had received comments from David Schartz relating to better trying to assign permitted operations on URIs to definitions of "convert", "translate" and "normalise". "translate" was understood to include adding a country code or conversion to alias. "normalise" was understood to include e.g. addition or deletion of whitespace. There was a requirement from the previous call to go into a greater detail of what could or could not be changed (posted 17 Feb 2009). This level of detail was thought to be what Jon Peterson had been requesting. The remainder of the call was spent reviewing the list that John had already posted to the participants. Hadrial had responded to this mail and his comments from this mail and prior mails were included in that review. It was noted that Hadriel had not yet conducted a full review of this text, merely suggested that some previous mails also addressed these issues. It was agreed that the focus was on fields signed by RFC 4474. This combined text is reproduced below (with interpolated discussion from the conference call): > From last week's call, there was an action on all of us: > "There was agreement that we should analyse in more detail specific > header fields and body types, and the impact of SBCs on the identity > characteristics of those elements. This will need to go into detail on > the contents, for example, rather than a blanket change of a URI to a > different URI, what is the impact of changing a URI to say an alias of > that URI, or adding a "+" where one currently does not exist. Hadriel > generally called these changes "protocol repair"." > > In the absence of any other contributions, I will try to kick this > off. I don't known whether this was the sort of thing expected. > > Only those fields signed by RFC 4474 are considered. > > addr-spec of From header field: > - Changing the host part means that the recipient loses information > about the domain the request originated in. > - Changing a non-E.164-based user-info part, or changing an > E.164-based user-info part in ways not covered below, means that the > recipient loses information about the particular user within the > domain. > - Changing digits within an E.164-based user part so to give a > different generally accepted form of an E.164 number does not in > principle remove the identification properties of From, although it > could cause difficulties with URI matching at the destination. In > generally, changing to a fully qualified, canonical form is less > problematic than other changes (e.g., adding a "+" to an international > number, removing dial string digits such as "00", adding country code. > - Adding or removing user=phone. In theory shouldn't be done, but in > practice it normally does not remove the identification properties of > From, since a the same user-part with/without user=phone generally > does identify different users. There is a need to cover the cases of changes from E164 based to email style addresses and vice versa. It was suggested that we could benefit here from David Schwartz's comments on categorising changes. *** Does this constitute the same terminology from Jonathan's RAI area document on numbering. It was also suggested that we should avoid the document getting into a discussion of when is an E.164 number not an E.164 number. > - Adding or removing other URI parameters. TODO. > SIP URI parameters have different characteristics to tel URI parameters in a number of ways and may need to be treated separately. > addr-spec of To header field: > - Not needed for identifying caller > - For identifying original callee, considerations are similar to those > for From > - In particular, a change of To when a call is forwarded would destroy > the identification properties of To. > Changing the To header field will break the RFC 4474 signature. It was pointed out that independent of this, we should not be changing the To header field anyway, as doing so breaks the purpose of the To header field as defined in RFC 3261. > call-id of Call-Id header field: > - This does not impact the identity characteristics of a request. > > digit of CSeq header field: > - This does not impact the identity characteristics of a request. [JRE] Although Call-Id and CSeq were apparently included in the signature for replay protection purposes, it is not clear that this would work. There are cases related to forking, redirection and retransmission over UDP transport where the verifier could legitimately receive repeated requests with the same Call-Id and CSeq values, perhaps with different values in the Request-URI. > > method of CSeq header field: > - This does not impact the identity characteristics of a request. It > seems very unlikely that an SBC would modify this field. > > Date header field: > - This does not impact the identity characteristics of a request, > although it is essential to provisions for preventing replay attacks. > > addr-spec of Contact header field: > - Substitution of the SBC's own contact URI does not impact the > identity characteristics of a request. [JRE] A man-in-the-middle can pervert the routing of subsequent mid-dialog requests by manipulating Record-Route rather than Contact, so signing the Contact header field has limited value in this respect. It may have some value for subsequent out-of-dialog requests (e.g., where the Contact URI is used in the Request-URI of a REFER request. In such cases, any B2BUA that modifies the Contact URI would need an algorithmic or stateful means of performing reverse modification even after the original dialog has terminated. It is not clear whether this works in practice. Note that one reason for changing the contact URI is to replace IP addresses, the use of which is bad practice anyway. > - Changes to the original contact URI without substitution of the > SBC's own contact URI is likely to be harmful for other reasons. > Some discussion is required of Contact header field parameters, e.g. the GRUU Contact header field parameter is the real identity for getting back to the user. > Body parts other than SDP: > - This does not impact the identity characteristics of a request, > although it certainly has other implications. > Unclear whether this happens in practice. > > SDP: > - Reformatting (e.g., addition or removal of whitespace). > This does not impact the identity characteristics of a request. > - IP address in c-line / port in m-line. This impacts the identity > characteristics of a request to the extent that it no longer > identifies binds the sink of media to the user identified in From. > However, SRTP with an appropriate key management system should achieve > that and a lot more. The RTP case is insecure anyway. > - a=fingerprint line. This prevents the binding of SRTP to signalling > and the user identified by the From URI. > - removal of m-lines and their attributes. This does not impact the > identity characteristics of a request It os imderstood that the RTP case is insecure anyway. It was commented that Jon Peterson does not want the identity to be dependent on SRTP. Dan Wing commented that even if SRTP is not secure, then identity is still useful even with RTP. We are frequently interested in who is calling and not necesssarily worried that some third party may have inserted an advert in the media stream. > - Changing m-line transport, e.g., from SAVP to AVP. This does not > impact the identity characteristics of a request, but constitutes a > bid-down attack. > - Removal of a=tcap, a=pcfg lines. Again this could constitute a > bid-down attack. > > There are lots more things in SDP that could be changed. I won't go > into that now. I first need some feedback on whether this is going in > the right direction, and also advice on what in practice is likely to > be changed for good reason at SBCs. > The document should cover the change of IP address. There was also discussion of the of the change from AVPF to AVP, and the potential impact of the use of capability negotiation to enable this. Suggested that feedback should be at the same level as the AVP. Changing SDP is not necessarily bad or harmful. It was understood that the area directors wanted to sign the SDP because IETF does not necesssarily understand what might be used in the future in the SDP. Therefore we sign the SDP except all those things we allow to change. > Although many of the fields can be changed without impacting the > identity characteristics of a request, the reason they are signed in > RFC 4474 is to do with providing a measure of integrity protection on > important parts of the message that are not expected to change. The > more of these we remove from the signature, the less integrity > protection we have (and in some case less playback protection). So we > need some sort of balance between allowing reasonable changes by SBCs > while still giving a reasonable measure of integrity and playback > protection. We also have to take into account that some requests do > not relate to media and do not contain SDP (e.g., MESSAGE, SUBSCRIBE, > NOTIFY), and therefore reducing the amount of signed information will > impact the integrity and playback protection of these requests more > than requests such as INVITE. There was a discussion of other information that also should be discussed. The following were suggested: - Geolocation and any associated PIDF LO body. - SAML assertion. Both would be signed by the XML signature. The document being produced needs to make sure we clearly identify what we discussed and excluded from the discussion. There is a need to justify what is left is the complete list that merits discussion, and that nothing has therefore been missed. This was the last of the currently scheduled calls. It was agreed to have a further call on Tuesday 3rd March 2009 at 7:00 a.m. Pacific time. ------------------------------------------------------------------------------ regards Keith _______________________________________________ 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
