- publish X (10 – 20) in favor, 1 opposed (not useful enough- Jonathan Rosenberg) Spencer Dawkins – needs guidance BJ ? a lot of stuff not in 3261- not worth WG time- but supports shared connection as “the logical thing” Jonathan – support long lived connection, opposed shared connection -
led by Robert Sparks Security directorate found a problem … Do people care 10
1-Max breadth -more than B O (10)
2-Whole tree –less O(5)
Robert-Is limiting rate OK Cullen - Not sure
Scott Lawrence- problem with original scenario- generates them all at once. This limits rate at which messages arrive at victim
Cullen Acid test-single DSL, can I bring down Verizon
Robert-Volume of traffic you can generate is the same with both options. Volume is the same, option 1 runs longer.
Cullen – can’t really say at this point.
Allan H- option limits the total number of messages
Robert -Option 2 with O (120) ok? O(10) in favor . none opposed
Dean-Go to security with option 1- if pushback,, go to 2.
Is thisapproiach wrong
Chris ? Should not just replace just paragraphs, should replace full section. Too hard to read.
Robert- 3261 could be 20 pages Danger of replacing whole section is that it will bring up other changes/clarifications, not just “essential”
Jonathan Rosenberg- do same way we do extensions. Tell people what they need to change.. Current approach is worst of both IETF and 3GPP
Robert – has led to arguments with implementers. Maybe new normative text with section at end that point to exactly what changed in spec, needs to be changed by implementers
Cullen- only solution to Jonathan is a completely new version of 3261.
Cullen- talking about bug fixes. Last time came t o the conclusion that all solutions are awful.
Jonathan- read invfix, couldn’t follow it.
Rohan – important to put normative and non-normative changes together. – put something in the leftmost character in test, also have appendix point in got changes
Francois – agree with Jonathan – need prose, but all so need diffs. Can we do an actual Diff?
Eric Burger- this is for people implementing SIP, not for “us”. Implementers do not care about motivation, just what THEY have to do.
? Best thing for implementers to do it all in pictures
? Need cumulative Diff- need to be applied in correct order
Dale Whorley- current approach has superior error checking properties- hard to make the same error in both.
Led by Jeff Hodges
Ambiguous sentence- what does “this spec” refer to?
Jon Peterson – background Slightly tortuous. Wanted to be sure we didn’t say this is the “only format” wanted to permit CID. Wanted to say If you use http uri, this is the only format.
Say we are using non-2585 uris. Still http uris.
Jeff – 2 questions- what do we do with SIP SAML draft? Do we need to clarify something about all drafts that refer to 4474??
Jon- This is good enough for THIS ID.
?-Will normatively update 4474 on cover page, in database. …
Jeff - Assertion by reference or by value.
Hannes SI UAC adds SAML assertion to SIP body. Should permit adding by end host?
Cullen – do “both”, not “either” If every new application need a new profile, then we did the profile wrong
Hannes- every new class of applications needs anew profile.
Jeff reply to cullen conveyance is use case specific, may not be possible to have one size fits all profile. Short answer add “by value”.
Keith – needs to be WG decision, not author decision
Jeff- should editors jam in “by value” profile and binding?
Hannes- req document gave guidance on the type of solution- do not need to come back to WG to verify each req.
Keith- WG still needs to review, because the view of the reqs may change.
In favor of by value -0 Opposed to by value -1 Don’t know what we are talking about-many
Jeff – “redirection” rather than “proxy mode”. Is there an essential difference
Juri Big difference header fields and token fields
Rohan - security section does not address privacy, which is one of the motivations for SAML
Jeff- more work to do on the draft.
Led by Aki Niemi
Mainly editorial changes.
Jonathan, sent comments 10 minutes ago. What is motivation for wild cards for if suppressed match. No stated use case.
Aki - Two uses – heartbeat and metadata headers without body, e.g. subscription state
Jonathan OK, make clearer. Why do you need option tag?
Aki – agree, don’t know why we have it
Jonathan – response code 204 – no semantic for want a UA does if it gets 204.
Aki – reason for 204. User can kill the handle
? - Important for lost messages
Aki will check for description
Rohan - talked about suppression of bodies, not notification itself – only application is hear beat. U2UBA, ? still bothers me.
What if there is something in the middle executing subscribe, notify?
Aki- assume end to end- don’t have to care about stuff in the middle
Jonathan- Need to check with ??. another motivation is refresh. Is subscription state part of state we are transferring
Aki- could go either way
Jonathan – don’t think it is, need to be clear
Aki - Don’t think we can take the expires ot be aprt of
Adam Roach – wild card cases look like notify pause- addresses problem better. Different problem, might want to work on separately.
Aki – need to address asterix.
Ld by Mayumi Munakata
Jonathan withdrew his concerns with Issue 3
Rohan – issue 1 3 options
Don’t want to use proxy-require.
Using new ?ID would be my preference.
John Elwell - is UAS allowed to receive the info that it is private? Don’t really see a solution – new header or new value- depends on having a proxy that supports
Jonathan – bug in 3323? – how do you deal with aproxy that inserts additional info in the request after it has left the privacy service. Nothing that says proxy should not insert user identifying info. Proxy require all the sway neo practical. New extensions should know to honor privacy. Best you can do is have privacy request all the way.
Change in semantics for old proxies - new proxies and new specs need to not add.info
Jon – Jonathan arguing for 1 Once it has been through the privacy server, what can add
Jonathan -3325 can add
Jon - Jonathan is saying that later proxy can add based on P-asserted.
Jonathan – credible that it will add additional information derived form P-asserted identity. Don’t put anything new in, or if you do, take it out Bug in 3325. Reason I like option 1 is because that addresses what people are actually doing
Dean – I need closure. Is there a problem this WG needs to work on Yes- faint hum No – bigger hum
Recalled with show of hands
This is second presentation of this draft . Sip (not sipping) addresses privacy
Adam Roach- protocol extension plus BCP on additional annonomization. Two separate problems
Jonathan – problems with current approach – assumes annonomizer exists, but does not check to see if it does.
Rohan- transition problem from what people are using to day and what we would like ot get to. This draft points out a lot of these problems.
Spencer Dawkins – what are you seeing
Dean – shall we add solving UA initiated privacy problem in this WG Yes ( 15) No O (1)
DO we want to use this doc as starting point Yes O (15 – 20) No 0
led by Scott Lawrence
Extended key usage
Rohan - most of certs issued today have it.
Ekr – Steve thinks that every cert you have seen in your whole life is screwed up.
Cullen – treaty between ? and ? .unlikely to change
Scott - Small delta from what most people have been doing in SIPIT
Scott – believe nearly complete Does this fit into the charter item “clarify security”
Dean- Does WG think this is for this WG
Ekr –this is appropriate Yes O (20) No 0?
This draft as baseline Yes O (20) No (1) Cullen - need to work with pkix to coordinate review.
Scott – will resubmit with changes.
by Steve Dotson
3261 digest user name password Shared long term secret
Strong authentication needed beyond username password
Rohan – variety of problems addressed. Req not intuitive. Do need to solve some of these problems but would be better to break them up- do it in sipping first
Dean- all security work including reqs is supposed to be in SIP.
Rohan –
Steve -Use cases or reqs need to be better defined
Jonathan - Use cases define req. Object to the idea that we need to do end-to-end auth. Reinvent TLS over SIP. Use cases are fundamental reqs. Need to be crisp on which we are addressing.
Dean – how to authenticate when proxy is on other side of trust domain.
Jonathan – flawed use case
Cullen - not deployable
Jonathan -use case needs to be concrete
Rohan –two different use cases with diff reqs. Might have same or different solution. What is oermitted wrt intermediate proxies
Ekr – use case not clear. Has been attacked once .?? addresses it. Objections to S/Mmime – parse properly – replay attack problem- no way for server to ask If people cared they would not mangle it.
Jon- authenticate yourself to something more than one hop away. Difference is whether or not you have an existing relationship. Not clear why current techniques can’t handle it
Cullen – Think you are interested in device authentication rather than user authentication. Need use cases that do not imply a solution.
Rohan - S/Mime, end-to-middle, small. How do they compare
Hannes – earlier work on device authentication
Dean – consensus – somewhere in there is a problem worth working on – but not described clearly. Why don’t current mechanisms address?
Jonathan – need higher level use cases.
Steve - Intentional left vague
Jonathan, - don’t leave vague
Francois- I was completely confused about what you were trying to do- need to make clearer.
Dean- not telling you not to bring it here. Discuss it on the list
Hannes- for device certificates, most people don’t understand.
Eric Burger
Various uses - This (ed: Info) works
Rohan - By some definition of “works”
Jon – we specified 3372, 3304 INFO for IMF and IMR concurrent with session negotiation. It was a bad idea even then
Adam – I was young and naïve. Current situation is untenable. Too many ways of representing DTMF used by vendors, other than 2833.
Jonathan – People who have used INFO- tell us what problems they have with other methods, why using INFO?
Spencer Dawkins – I was so much older then, I’m younger than that now. This is ?? of 21st century. INFO is the UDP of SIP signaling. Easy to do but wrong.
Rohan – don’t think we need a document that says “don’t do Info” in SIP wg wont do any good because we are the only ones that will do it. Move it to BLISS.
Francois – also one of the guilty parties and represent a vendor that has been abusing. Need a document like this. If we don’t have this, it will encourage other sdo to use INFO.
Hadrial Kaplan – agree that we are telling the wrong people. Had to use it for DTMP for compatibility with another vendor.
Ronnie ? 2 reasons for this document. “IETF says you shouldn’t use it”. I ws force to use INFO because I couldn’t get anything else approved
Spencer Do we need to use SIP for this
Brian Stucker – damage has been done. Need to address architecture not method.
Mary
?? reason we have 5-6 ways of doing DTMF is because we told people “don’t do it here”
Dean - Do we need to do anything about INFO DO nothing in this group – (few) DO something – O (20+)
A Describe current uses and says anything else is not supportable, and describes why bad
B Negotiation framework.
?? third choice discourage other uses Dean Still need architectural discussion
?? –if you say all mechanisms that are UA to UA are bad they will invent something just a s bad Dean – need to be parts of architectural considerations
Dave – if you have some new thing to do, create new method. No justification for anything other than cram the lid back on.
Dean - do we need different subscribe/notify for each application
A O (20 – 30) B O (5)
Dean – two to one, no clear consensus
led by Dan Wing
Cisco IPR 4474 doesn’t work through SBC
Rohan – Don’t understand use case of why it is broken. How does end domain know what it means. Have trust relationship with service provider- can you delegate them the signing trust? Not in Speemint use cases. What is the use case for this?
Jon - Already overtime – Premise does work. Very interesting. But still don’t like it. Don’t like problem it is solving. Won’t be able to back away from 4474. SBCs change lots of other things. 4474 provides overall integrity. Some SIP messages (e.g. NOTFY) need overall integrity. Don’t want to get into “yahoo or google stronger security?”.
Francois – unconvinced that we need to do this
Dan - Not merely to address NAT traversal- no NATs involved.
Francois – originating domain should do this.
Hadrial Kaplan - there are use cases. caller id identity protection.
Keith For the record consensus was … (???)
Back to SIP Notes and Minutes at IETF 69