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.
updated 12-Apr-2002 20:01 -0500