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.