[Sip] Draft minutes, SIP WG, IETF 53

Please comment ASAP -- I've been lax in getting these circulated.
Finals are due tomorrow.

Revisions will be posted at:

http://www.softarmor.com/sipwg/meets/ietf53/notes/minutes.html

as they are made.

---------------------------------

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.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip