Current Meeting Report
Slides
2.7.20 Session Initiation Protocol (sip)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
11-Feb-02
Chair(s):
Joerg Ott <jo@ipdialog.com>
Brian Rosen <brian.rosen@marconi.com>
Dean Willis <dean.willis@softarmor.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:sip@ietf.org
To Subscribe: sip-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/sip/current/maillist.html
Description of Working Group:
Note: There is another SIP email list for general information and
implementations:
Discussion of existing sip: sip-implementors@cs.columbia.edu
To Subscribe: sip-implementors-request@cs.columbia.edu
In Body: subscribe Archive:
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
=======================================================================
The Session Initiation Protocol (SIP) working group is chartered to
continue the development of SIP, currently specified as proposed
standard RFC 2543. SIP is a text-based protocol, similar to HTTP and
SMTP, for initiating interactive communication sessions between users.
Such sessions include voice, video, chat, interactive games, and
virtual reality. The main work of the group involves bringing SIP from
proposed to draft standard, in addition to specifying and developing
proposed extensions that arise out of strong requirements. The SIP
working group will concentrate on the specification of SIP and its
extensions, and will not explore the use of SIP for specific
environments or applications. It will, however respond to
general-purpose requirements for changes to SIP provided by other
working groups, including the SIPPING working group, when those
requirements are within the scope and charter of SIP.
Throughout its work, the group will strive to maintain the basic model
and architecture defined by SIP. In particular:
1. Services and features are provided end-to-end whenever possible.
2. Extensions and new features must be generally applicable, and not
applicable only to a specific set of session types.
3. Simplicity is key.
4. Reuse of existing IP protocols and architectures, and integrating
with other IP applications, is crucial.
SIP was first developed within the Multiparty Multimedia Session
Control (MMUSIC) working group, and the SIP working group will continue
to maintain active communications with MMUSIC. This is particularly
important since the main MIME type carried in SIP messages, the Session
Description Protocol (SDP), specified in RFC 2327, is developed by
MMUSIC and because MMUSIC is developing a successor to SDP which SIP
will also use.
The group will work very closely with the (proposed) SIPPING WG, which
is expected to analyze the requirements for application of SIP to
several different tasks, and with the SIMPLE WG, which is using SIP for
messaging and presence.
The group will also maintain open dialogues with the IP telephony
(IPTEL) WG, whose Call Processing Language (CPL) relates to many
features of SIP; will continue to consider the requirements and
specifications previously established by the PSTN and Internet
Internetworking (PINT) working group;: and will consider input from the
Distributed Call Signaling (DCS) Group of the PacketCable Consortium
for distributed telephony services, and from 3GPP, 3GPP2, and MWIF for
third-generation wireless network requirements.
The specific deliverables of the group are:
1. bis: A draft standard version of SIP.
2. callcontrol: Completion of the SIP call control specifications,
which enables multiparty services, such as transfer and bridged
sessions.
3. callerpref: Completion of the SIP caller preferences extensions,
which enables intelligent call routing services.
4. mib: Define a MIB for SIP nodes.
5. precon: Completion of the SIP
extensions needed to assure satisfaction of external preconditions
such as QoS establishment.
6. state: Completion of the SIP extensions needed to manage state
within signaling, aka SIP "cookies".
7. priv: Completion of SIP extensions for security and privacy.
8. security: Assuring generally adequate security and privacy
mechanisms within SIP.
9. provrel: Completion of the SIP extensions needed for reliability of
provisional messages.
10. servfeat: Completion of the SIP extensions needed for negotiation
ofserver features.
11. sesstimer: Completion of the SIP Session Timer extension.
12. events: Completion of the SIP Events extensions (Subscribe/Notify).
13. security: Requirements for Privacy and Security.
14. natfriend: Extensions for making SIP a NAT-friendly protocol.
Other deliverables may be agreed upon as extensions are proposed. New
deliverables must be approved by the Transport Area Directors before
inclusion on the agenda.
NOTE: milestones within the same month are shown in order of planned
completion.
Goals and Milestones:
| Done | | Server Features Negotiation submitted to IESG |
| Done | | Complete IESG requested fixes to provrel and servfeat |
| Feb 02 | | Session Timer spec to IESG |
| Feb 02 | | Caller preferences specification submitted to IESG |
| Mar 02 | | Revised proposed standard version of SIP (2543bis) submitted to IESG |
| Mar 02 | | SIP Events specification to IESG |
| Apr 02 | | Preconditions extensions (manyfolks) spec to IESG |
| Apr 02 | | SIP Privacy specification (from DCS) to IESG |
| May 02 | | MIB spec to IESG |
| May 02 | | Refer spec to IESG |
| Jun 02 | | NAT-awareness extension on REGISTER submitted to IESG. |
| Jun 02 | | SIP Privacy and Security Requirements to IESG |
| Jul 02 | | SIP over SCTP specification and applicability statement |
| Jul 02 | | Review WG status (consider closing) and/or submit a future milestones plan to IESG |
Internet-Drafts:
Request For Comments:
| RFC | Status | Title |
|
| RFC2976 | PS | The SIP INFO Method |
| RFC3204 | PS | MIME media types for ISUP and QSIG Objects |
Current Meeting Report
Minutes edited by Dean Willis from notes taken by Vijay Gurbani, Joerg Ott, and Renee Cohen.
Session 1
19:30 CST meeting started
Agenda accepted
Chairs discuss "Note Well" 2026 notice
Work Plan update:
We have revised the SIP spec; went to IESG; resulted in a "Yea" from IESG. SIP events spec is done
Session timer is back to haunt us -- goes back to authors for bis update.
Caller pref - pending from author for bis.
Precondition extensions -- in WGLC now; in IESG by April SIP
Privacy spec from DCS in WGLC now, IESG by April
REFER Method; needs bis, security updates. IESG by May? No complaints from authors. More important since there are many implementations already.
MESSAGE method ready for WG LC -- have not done it yet.
PATH method needs rev from editor. Call for volunteers.
NAT awareness: rev pending from author.
SIP Privacy and Security reqs to IESG? There is a feeling that the SIP extensions for privacy wrt to 3GPP is not achievable -- Jon P: some privacy (user provided privacy vs. network provided privacy) nuances have not been captured as of today. Henning: that would make a lot of sense if we know what we wanted -- another req document is not in and of itself useful. Dean: SIP privacy and security reqs predate the SIPPING WG -- IESG felt that it is such a critical piece that it should stay in SIP WG.
SIP over SCTP? Gonzalo: we are ready for WG LC for SIP/SCTP. Dean: Also in July timeframe -- have a draft standard version of SIP -- #1 goal in July of 2003. Original SIP spec was 2543, we want to claim new number of 3543 :-)
State: Charter item of pushing certain things off the SIP signaling state -- state or cookies specification translated to SIP. Did we ever come to a consensus on how to go forward? Rohan: Cookies I-D is good for doing what you want to do with the state I-D and is more general. I support it. Dean: Anyone know of implementations? [No implementations yet] Jonathan Rosenberg: The reason no one has implemented it is because everyone is using R-R and Contact. It is not entirely clear to me that this is even needed. Flemming: The difference is that R-R requires the proxy to be in all signaling. Andrew Zmolek: We looked at R-R issue and it seemed that we were going to have some trouble -- either the state or the cookies would do fine JDR: R-R was not sufficient since there was no reliable way to put something and get it back. With the new R-R update, this is no longer an issue. rjsparks: You cannot change the state in a dialog, you can only push and get the state. JDR: Okay, if that is the requirement, then fine -- if the req is to just push state for the purpose of a dialog, we have a mechanism already in R-R, Contact. Brian Rosen: we may work on a requirement document offline, assuming that it is useful.
General Scheduling: Henning: meta scheduling aspect -- can you get people involved long enough to remember what the issue was? Brian: Our goal is to get a lot of stuff out that has been hanging around for a long time -- but we do not want to get out 12 LC I-Ds at the same time. We will revive the LC schedule we had going. Henning: Do other I-Ds that are not on your list wait until re- chartering? Brian: No. There are some things that are hanging around for a long time; as long as the ADs do not breath down on us, we will work on them as we go along. Henning: Need a priority list. Jonathan: Learn from successes -- Bundle 1 was a success delivery to 3GPP. With the current mechanism we were randomly LC'ing. One of the thing the Bundle did is to focus people's energy on that. Brian: We can consider that; Bundle 1's advantage was that the drafts were related to one another. These do not.
What do we do with: sipping-conferencing-models? sip-3pcc? app-components? sip-vxml? Jonathan: need to finish bis update; but done as far as I know. Rohan: 3PCC is a very pure usage draft describing the usage of baseline bis offer answer model. Most of the stuff above is usage or framework, we should get it done in SIPPING. Brian Rosen: You are basically saying what Jonathan said: Put it in Bundles. Rohan: Sure.
SIP Change process, Allison Mankin:
This is not a SIP draft; it is an individual transport area draft. People have said that there is a need to control SIP information. The Replaces header was done in a freeform manner -- this is not good. WG discipline needed over extensions of SIP. RFC 3261 (new bis) has an IANA consideration which is very different then what you have seen before. You need a standards track RFC for headers, method, response codes, warning codes. One place you do not need to do this is for the Events RFC -- just need WG yes for these. serverfeatures did not go too far with IESG since it offered unbridled extensions. We now have P-header (not X-header, more constrained). Still need a RFC, but you do not have to have the buy in of SIPPING or SIP. The string with P- is reserved if they are to have a future life. Henning: while I agree with the notion, the naming has the same problems that X headers had. Attaching a meaning to "P-" is not good. Allison: They do not have option tags and have to have applicability statements. Henning: There are 2 issues: naming and process/applicability. If we have a header name which was registered (say, foo); that header has the property that as long as it is in the non-RFC track, it looks like a normal header. If it reaches standards track, it retains its name. Lets say P-bar header becomes popular and widely implemented. Now, if P-bar header goes to standards track, they will have to rename this header. Allison: can you make a P-header a standards track header -- add an option tag. Dean: The P- name will still be registered and be useful. Now you will basically have to track P- and non-P extension headers -- makes the symbol table little large -- that's okay. Dave Oran: feel uncomfortable in mixing naming conventions and algorithmic behavior. I do not like the idea of having to parse inside header string. Jonathan Rosenberg: The name of the option tag is unrelated to the name of the header. Henning: HTTP extension model is different then SIP extension model. There is no correlation in header names and option tags. Allison: If the I-D has any implications of this sort, we can fix it. Gonzalo: We have option tags that have no headers associated with them. Keith Drage: We need to make sure that this I-D does not contain any requirements on SIP implementation -- a SIP implementer must not have to read this I-D.
The UPDATE method - Jonathan Rosenberg :
Open issues
1) Glare with PRACK - UPDATE only specifies glare resolution with itself. You can have glare with PRACK. Rejecting PRACK is bad. Solution: can't send UPDATE if you have sent an answer in 18x for which you have not gotten a PRACK. Will put some words with general caveats.
2) Repairable response codes -- automata can fix these without human intervention. What about 493 Undecipherable? May require user intervention to fix it. Proposal: include it, add text saying it retries if it would otherwise retry with that response. [No one objected].
3) Generate 155 instead of 4xx MAY or SHOULD -- for backward compatibility. SHOULD is better if the UAS supports this capability, the proxy may not. This makes it work at proxies transparently. Comment: This text is screaming for a reason header, otherwise the UAC will have to infer what the problem is. JDR: I did not talk about reason header for a reason -- it is on a slower track. For the basic cases we are worried about immediately, the UAC can infer from the headers. Going forward, the reason header is the way to go. Gonzalo: The last review of the reason header already has this, so we can use it. Jonathan: Does the group agree that the message sip (or sip frag) is the appropriate approach? Or wait for the reason header (which is on a slower track). Rohan: Can we pull out 155 out of this, then? [No consensus on this]
Manyfolks open issues (Gonzalo Camarillo)
draft-ietf-sip-manyfolks...-05.txt
We are now defining a framework for preconditions of different types. We define the current status of the precond vs. desired status. We always know if current status is better or worse then desired status. Two status types: e2e -- always present in manyfolks (-04). Segmented status type introduced in -04.
Open issues: Meaning of Require: precondition -- 2 approaches: I refuse everything I don't understand. Or be liberal and accept the offer if the preconditions can be met without your intervention? Which is better? 1 or 2? Comment: you can have a thing called "criticality" which gives a hint on what to do. Gonzalo: I will decide after speaking to Mark.
Reason code, Gonzalo Camarillo.:
Requirements: same functionality needed in several WG items -- why is this request (or response) being sent?
Useful in many works: ISUP/SIP mapping, in manyfolks (precondition failure, unacceptable here), HERFP, 3pcc.
Jonathan: Throw in another use: in the event that you fork the request to a bunch of phones and one of them picks up. The proxy generates CANCEL. The reason for CANCEL is not because the user hung up, but because 1 of N answered.
Rohan: Lot of overlap in the reqs that generated this document and request history.
Eric Burger: This is H.450 all over again.
Jonathan R: Don't we have an enumerated list of response code in the bis already? This is exactly that, and then some.
Comment: we have one address space for responses, and we have just added one more with the Reason header. Has a kitchen-sink feeling to it.
Henning: The motivation was exactly to prevent reinventing the same thing every time. We are not adding new error classes that will have to be percolated to all existing implementation. This is a fine grained status code which is there if you need it. Example: Q.850 error code will not be pertinent to many implementations, but to the one that it is pertinent to, it can use it without too much perturbation.
Brian Rosen: What do we do now? 2 possibilities: crisp set of reqs, which are clear and this is a reasonable solution. Or we do not have a crisp set of reqs. We need to determine this first. Lot of discussion on if this does or does not solve the job. But do we know what the job is? Should we push this back into sipping and generate a req document? Those who think we have a sensible set of reqs and we can move forward? Those who need more reqs? [The hum level was 50-50, no consensus by humming on if we have the reqs captured right.]
Dave Oran: Need hum on slightly different -- do we get involved in reqs that requires identity (being able to communicate why you are sending it to this particular party).
Brian Rosen: That is a reasonable suggestion -- so considered. We will get the reqs out before Yokohama and bring the solution out before then. Those of you who hummed against it should participate in the list when we discuss this on it.
Flemming Andreasen, SIP Extensions for Media Authorization.
draft-ietf-sip-call-auth-04.txt :
Changes: Category is informational -- Header is now P-Media-Authorization. Applicability statement about appropriate use (SIP Proxy and Policy Server (PDP) must belong to the same domain) Updated rules about when to add a P-Media-Authorization header. Additional security considerations -- don't encrypt message bodies (proxies need to examine them).
Open issues: None known (authors list need to be trimmed), currently in WGLC.
Jonathan: I will send you some minor reviews. More look-see needed in the security section. This token is about media authorization -- authorization follows authentication. DOes the I-D point out this issue?
Flemming: You do not necessarily need to authenticate before authorization. Some entity has been given an authorization token to access some resource.
Jonathan: More discussion maybe needed on the security section -- you are giving a token to a party that you may not have authenticated. If that is your model, fine; a couple of sentences would probably suffice in the I-D.
Brian Rosen: The WGLC is going to get over, if anyone wants to raise more issues please do so. It fills the needs, even though it has a lot of limits. LC be it, we will move forward.
Ben Campbell, SIP Extensions for IM :
-05 draft; recent changes -- remove CPIM mapping to separate draft. Would like to include in 3rd bundle to IESG.
Highlights - sends IM; does not initiate a dialog, does not discuss message sessions; actual message in bodies.
Open issues: No recent discussions. Needs minor editorial changes (forking, threading -- couple of sentences). Anything else? Is it ready for LC? One more revision -- no change in substance, more editorial.
Brian Rosen: Ok, as soon as you have the revision, we will post it as LC.
Closing Remarks :
Brian Rosen: Administering this list is no fun -- people forward their email to accounts that consistently run over quota. The list is setup so that only subscribers can post.
21:29 CST - WG adjourned.
SIP Session 2, 53rd IETF
Start 13:06 CST
Added AKA Digest and Path discussion to the Agenda.
Agenda accepted.
Digest based authentication -- James Undery, Ubiquity
Quick run through of improvements to Digest authentication. UAC->UAS auth, UAC->Proxy authentication supported in the SIP spec. Our draft adds Proxy->UAS auth., bid-down protection, mutual auth., integrity. Added 3 new headers and 1 new response (492) for Proxy->UAS authentication Bid-down protection: prefix added to nonces, protects scheme and quality of detection.
Open issues: 1) No algorithm protection - if a hashing algo is broken, we need algo revocation. Proposal: make limitation explicit and rule that algo revocation is out of scope. 2) No negotiation of body integrity protection -- Proxies can't alter message bodies; Proposal : leave unchanged 3) No protection against weak passwords: Proposal - make limitation explicit, the solution is out of scope. 4) Client side can't initiate authentication 5) Forking and response collation issues - can't guarantee upstream entities see the challenges; response collation oriented towards success. Proposal: make limitations explicit.
Jon: What are you trying to accomplish as a UAS by authenticating your upstream proxy? James: You may trust the proxy but not the link between the proxy and the UAS (for example: a radio interface). Jon: So this is the integrity process, not an authentication one. James: Authentication and integrity are closely linked. Rohan: We need to think about if this is needed? Looks like it is solved by TLS anyway. We need to understand under what circumstances we will use this approach. Jonathan: With this you do not know which proxy -- one up or 2 up -- you want to authenticate.
Comment: You mention weak passwords; there are no strong passwords. You are unlikely to create a password that is not uncrackable, regardless of them appearing in the dictionary or not. Relying on a long random key is of no help. Christian: I would like to reinforce this point. Digest should be combined with strong authentication of the server, not on its own. Henning: when people talk about passwords, I wouldn't think that this is human generated; it is random string generated by some automata.
Dean: Are we going to close any of these today? If not, let's take this to the mailing list. Brian: This has been hanging on for a long time; are we going to extend digest or not fortify it anymore. I do not know how to go ahed. People are saying that digest is terrible, but others are saying that it is still useful. I do not see other alternatives on the floor. Christian: 2 forms with digest: 1 is if you are sending it as cleartext. 2 is when you are doing digest with a 3rd party you have not authenticated. Simple thing for us is to use digest only for REGISTER not anything else. Brian: But there is no other solution on the table. Allison: The security review for bis came out as digest being a very lightweight way to do user authentication is okay. There is a good possibility of taking some time over this and making it better; maybe we should say that this document is not a WG document. We should discuss for the charter document something that exploits S/MIME. Rohan: There is some stuff in James' draft we can get consensus quickly; others may take some time. Allison: There is a huge deployment of digest. MD5 digest is known weak, but is not going to be thrown out. The topic we have now is not extending digest, but supporting some other password (a la AKA). For this document, consider what requirements it is meeting? Henning: One thing desperately needed in digest is registrar authentication. If we do something with digest at all, it must be this. Authenticating previous hops is nice, but not a known vulnerability we need solve now. Steven (3GPP): We do have a basic need to protect last hop integrity. We need to know what the intentions of the WG are towards digest. We need the direction very soon otherwise we are in a bind. Allison: Maybe, as Steven said, IPSec could be used for the short duration -- could be the right way of meeting the requirement. Maybe we can have 5 minutes on some other agenda to talk about this. Brian: We are not getting anywhere -- let's move on and take it to list.
Digest AKA Authentication - Aki Nieme
AKA is a shared secret based auth that uses a smart card like device. Previous proposal (...-eap-01.txt) got good reception at SLC.
Digest AKA reuses the digest scheme and uses the AKA parameters as input to the digest mechanism. AKA generates "one-time" passwords for Digest.
Issues: 1) "Choke point" attack - similar to the weak password attack. 2) Should we adopt draf-niemi-sipping-digest-aka-00? It provides message integrity and is complementary to vanilla digest used today.
Future: Will this become a work item for SIP WG? RFC category? There is some time pressure since 3GPP R5 is coming up. Can draft-niemi-digest-aka-00.txt be adopted as a solution?
Allison: This does not involve any SIP extensions; just the extension of HTTP methods. It is good to get the SIP people's knowledge. There is no need for it to be a WG document; you can take it to RFC as an individual submission. Brian: Is there sufficient interest in the group to make it a WG item, or continue as an individual submission? [Took hum; the hum for people who want to make it a WG document prevailed]. Miguel Garcia: why use a 3G specific technology which has no broad impact on the Internet? Adam seconded. [The chairs agreed that we may have to revisit this issue again]
Security Negotiation open issues, Jari Akko
Presented issues, asked what to do next. Brian: Anyone object to NOT go forward with this? [No one objected; this is part of SIP WG]
SIP Extensions for Network Asserted Caller Identity and Privacy within trusted networks - Flemming Andreasen
Good list discussion 1 month ago; currently in WG LC. There have been some offline comment that have not been incorporated in the I-D yet.
Overview of changes: applicability statement (only suitable in the same admin domain, draft is for network-asserted identity, not user-asserted). Anonymity header got removed. Grammar fixes to be consistent with -09 bis.
Open issues: 1) Proxy handling of RP-ID received from untrusted entity (proxy or UA) 2 options:
1) if verifiable, set screen=yes
2) always remove untrusted RP-ID Option 1 seems more general then 2; Recommendation: Option 1.
This generated a lot of discussion, mostly revising around policies vs. protocols, network asserted identities vs. user asserted identities, (in)security of this I-D and why it will not be acceptable to IESG, and this being more for the benefit of 3GPP.
Randy Bush discussed current unacceptability of draft to operations directorate, and agreed to Send Text.
REFER Open Issues -- Robert Sparks
There was extended discussion about transitive security of the referral token (Referred-By) and its impact on the delivery schedule. Three-party problems are considered to be among the hardest of security problems to solve (Eric Rescorla). The authors recommend separating the problems, and doing REFER without Referred-By as a near term deliverable then tackle Referred-By as a separate task. The working group seems very interested in solving this problem and there was no clear consensus on separating it. However, it appears unlikely that this will be solved in the required May 30 timeframe, so we may need to administratively divide the problem space.
Several proposals to resolve the transitive security requirement were discussed, with consensus seeming to form around an S/MIME approach.
Slides
None received.