Reported by Mary Barnes
Detailed Meeting notes mbarnes Monday 5/6/02
SIP/SIPPING WG Agenda, Interim Meeting, May 6 and 7, 2002
Room S225 (2nd Floor of South Hall)
Las Vegas Convention Center
3150 Paradise Road at Convention Center Drive
Las Vegas, Nevada, USA
--------------------------------------------------------------------------------
Monday, May 6
08:30 Welcome, Logistics, Agenda Bashing -- Rohan Mahy
09:00 Multiparty Apps Framework and Conferencing Requirements -- Dan
Petrie or Orit Levin
draft-ietf-sipping-cc-framework-00.txt
draft-levin-sipping-conferencing-requirements-00.txt
10:30 REFER / Replaces / cc-transfer / service examples -- Robert Sparks,
Rohan Mahy, Alan Johnston
draft-ietf-sip-refer-02.txt
draft-sparks-sip-refer-split-00.txt
draft-sparks-sip-referredby-split-00.txt
draft-sparks-sip-sec-options-00.txt
draft-sparks-sip-mimetypes-03.txt
draft-ietf-sip-replaces-01.txt
draft-ietf-sip-cc-transfer-05.txt
draft-ietf-sipping-service-examples-01.txt
13:00 Lunch
14:00 The call-info and conference-info packages -- Jonathan Rosenberg
draft-rosenberg-sip-call-package-01.txt
15:30 Request History (Requirements) -- Mary Barnes and Mark Watson
draft-watson-sipping-req-history-01.txt
16:15 URI as service indicator -- Eric Burger
RFC 3087 - Service Context using SIP URIs
17:00 Binding Published data to SIP -- Ben Campbell
very long mailing list thread
18:00 Wrap
Tuesday, May 7
08:30 AAA requirements (Requirements) -- John Loughney and Gonzalo
Camarillo
draft-calhoun-sip-aaa-reqs-04.txt
draft-loughney-sip-aaa-req-00.txt
10:30 Content Indirection
draft-olson-sipping-content-indirect-00.txt
11:15 Key Events/ Stimulus Markup -- Jonathan Rosenberg
draft-culpepper-sipping-app-interact-reqs-01.txt
draft-rosenberg-sipping-markup-00.txt
12:00 Lunch
13:00 Privacy and Network Asserted Identity (Direction Forward) -- Cullen
Jennings
draft-watson-sipping-nai-reqs-00.txt
draft-ietf-sip-privacy-04.txt
draft-peterson-sip-privacy-longterm-00.txt
draft-peterson-sip-identity-00.txt
16:30 Future Security Needs (Discussion)
draft-ietf-sip-sec-agree-00.txt
draft-undery-sip-auth-00.txt
draft-thomas-sip-sec-req-00.txt
18:00 Wrap
draft-ietf-sipping-cc-framework-00.txt (Dan Petrie)
http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-00.txt
Is the draft useful?
Ø General feeling is yes.
Should conferencing be split?
Ø Mixed discussion: some believe that this would be useful, others believe that conferencing should be an integral part of this.
Ø Agreement that conferencing requirements should be moved into conferencing requirements draft.
General agreement that URL stuff should be split.
Why define a model?
Ø Needed terminology before requirements
Ø Needed model to define terminology
Ø Model is not intended to be normative, absolute or revolutionary
Ø Model is just a framework for terminology.
draft-levin-sipping-conferencing-requirements-00.txt (Orit Levin)
http://www.softarmor.com/sipping/drafts/draft-levin-sipping-conferencing-requirements-00.txt
Ø Draft overview
o Hierarchical application (signaling) model
o SIP Star conferencing application
o SIP Star real time multimedia conferencing application
Ø Reasons for hierarchical model
o Basis for terminology definition
o Means to understand requirements
o Means to describe and classify the requirements
Ø Discussion:
o In general, folks don’t understand Meta application level
o Orit: trying to define “What conference is”
o
Ø RT Multimedia conferencing is defined to be the Media aspect.
o RT Media = RTP, but did say that media could be non-RTP (i.e. T-120)
o Media processor itself is outside the scope (could follow any model – MEGACO, H.xxx, etc.)
o Media plane contains zero or more media processors
o Media processors contain zero or more media planes
Henning – Conferencing Requirements
Ø General philosophy:
o Strictly separate media and session signaling
Ø Support central-controller conferences
Ø Allow re-use of SIMPLE approaches
o Subscription permission -> conference join permission
o Buddy list -> pre-stored participant list
Ø Tease out conferencing specific needs
Ø Avoid conferencing specific profiles
Ø No T.120 special case (except through gateways)
Ø No need to define requirements for things that we already have:
o Conference creation
o Conference joining and leaving
o Participant muting
o Renegotiation of leg codecs
Ø Believe that meta-app model is misguided -> seems to call for another signaling protocol, identifier, etc.
o If no protocol or identifer, invisible
o Don’t want uninstantiated relationships
Ø We can setup sessions (including T.120 …) via SIP
General Model:
Ø Divide into request and notifications
o Requests = do something
o Notification = something happened
Ø Requests may trigger notifications if action may be delayed or partial
o Human approval
o Group invite
Discussion:
Ø JR: believe it still might be useful to step Back and look at requirements
Ø Brian R: there are still too many choices. Need interoperability.
Motherhood and Apple Pie:
Ø Simplicity
Ø Bandwidth-frugal (mobile
o Incremental notifications and command
o Selectable notification granularity
o Templates (mass invitation lists) for privileges
Components:
Ø Identified by object manipulated:
Ø Conferences -> conference management
Ø Participants within conferences -> user…
…
Conference management:
Ø Create conference
Ø Delete conference
o Name vs. resources
Ø Conference properties:
Ø Description (subject)
Ø Visibility to searching and directories
Ø Policies ?
Open issues:
Ø Separate conference name existence from resource allocation
o Want to keep name, but not mixing and bandwidth resources
Ø Template management
o User lists
o Privilege levels (chairs, etc.)
Discussion:
Ø Brian Rosen: Wants to solve smaller problem.
Ø Henning: We’ve been working on this, just can’t get agreement on what’s in scope.
Ø Orit: Need to separate SIP conferencing from Multimedia conferencing. (this point is not clear to everyone)
Conclusion: Continue discussion on the list – folks are leaning towards working from the existing cc-framework and conference-models drafts.
REFER / Replaces / cc-transfer / service examples -- Robert Sparks,
Rohan Mahy, Alan Johnston
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-02.txt
Ø Ready to go thru WGLC (with SIPFRAG)
http://www.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.txt
any deltas to refer-split will be done as draft-ietf-sip-refer-03.txt as WG document
http://www.ietf.org/internet-drafts/draft-sparks-sip-referredby-split-00.txt
Ø No changes in text from refer-02.
Ø Plan is to take S/MIME tunneling in 3261 and apply this to SIPFRAG.
Discussion:
Ø Jon P: Should follow the model being put in privacy draft. Propose use of an Auth Service.
Ø General discussion around this new proposal and “Legacy” implementations that have used Referred-by and have another means for auth.
Ø Henning: seeing pattern of headers AND signed versions inserted in SIPFRAG. See value in being specific.
Ø JR: how would a 3rd party server deal with this.
Ø Jon P: additional information provided by 3rd pty service.
Ø Allison: proposing a token model, whereby 3rd pty server doesn’t provide identity, but gives a token.
Conclusion: General agreement about the approach to allow Referred-by as a separate (and only) header in addition to Authed form in SIPFRAG.
Ø Henning: this is proposing that you need synchronized clocks.
http://www.ietf.org/internet-drafts/draft-sparks-sip-sec-options-00.txt
http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-01.txt (Rohan)
Ø Last remaining problem: using replaces to match early dialogs.
Ø Proposing options tag for Replaces (Require header)
Ø Using replaces for “Semi-attended” call transfer:
Conclusion: Proposing to remove the matching stuff for forking proxies (defer to later). Document limitations, therewith. It’s for specific established dialogs and doesn’t solve early dialogs.
On topic of security:
Ø JR: There Must be the capability for authorizing the REPLACES.
Agreement should be in UA section. In addition, this should also be in the Security section.
http://www.softarmor.com/sipping/drafts/draft-ietf-sip-cc-transfer-05.txt
Ø Just needs to updated based upon changes to REFER and REPLACES.
Ø Needs additional security considerations.
http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-service-examples-01.txt
Ø Changes:
o Added Subscribe/Notify using Dialog event package.
o Added single line extension flow
o Added auto callback flow
o Changed to Require: replaces instead of Accept-contact for attended transfer
Ø Open issues:
o Single Line extension
Ø One subscription relying on forking to N UAs vs. n-1 subscriptions without forking
Ø Requires INVITE with “Join” primitive
o Call Park
Ø Park Server returns extended sigfrag so that Subscribe/Notify not needed
Discussion (related to INVITE with “Join”):
Ø Somehow got off on discussion of “Globally” routeable URL. There was general agreement that this requires configuration, but some believes this is a complex problem.
Ø Jon P: What do you need beyond what’s already defined to get to a user/device – using Contact hdr.
Ø Rohan: You’re looking for a call at a user.
The call-info and conference-info packages -- Jonathan Rosenberg
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-call-package-01.txt
Ø Current draft to be split into 2.
Ø Dialog:
Ø Only issue is scope of data conveyed.
Ø Currently:
o Dialog attributes
o ID and version
o Dialog ID:called and tags
o URIs of participants
o Direction
o Status of dialog (as a reponse code)
o Proposing:
§ Local and remote SDP
§ Route set and remote target URI
§ Local and remote CSEQ
Discussion:
Ø Rohan: thought this was only for INVITE instantiated dialogs.
Ø JR: Clarification: Target of this is a URI, thus you would get this for all the dialogs associated with that URI.
Conclusion: Agreed for INVITEs only, NOT adding proposed items.
Discussion:
Ø Folks wanting to monitor state of media stream. But, proposal was that this was out of scope.
Ø Henning: covering some of this in Floor control work
Ø Lots of rathole discussion on conferencing package as fundamental disagreements on how this should work. Appears to be 3 models. Discussion will continue on the list.
Request History (Requirements) -- Mary Barnes and Mark Watson
http://www.ietf.org/internet-drafts/draft-watson-sipping-req-history-01.txt
Conclusion: Appeared to be general support, however, want privacy and security requirements to be identified.
URI as service indicator – Eric Burger
RFC 3087
Examples of Network Service SIP Request-URIs
Ø Join leg to a mixer (conference)
o Sip:conf=asj4040j@ms.provider.net
Ø Start an IVR sessions
o Sip:ivr@ms.provider.net
Ø Start a script
o Sip:annc@ms.provider.net;voicexml=\http%3f//as.provider.net/prepaid.vxml
Requirements for Network services
Ø Applications must be able to address services
Ø Services must be REGISTER-friendly
Ø Network must be able to proxy services
Ø Mapping to Service must happen “in Machine Time” (1ms-20ms):
o Often part of multiple interactions with user
o User expects “responsive service”
o Cannot have many round-trips
Discussion:
Ø Ben Campbell: Doesn’t think you can easily separate Network services from Applications
Ø JR: believes that the set of things that are being interoperated is quite small for these Network Services. Can bring in a new box and have things configured and up and running in a week.
Ø Brian Rosen: Doesn’t see the difference between Network and Appl servers
Ø JR: 2 things: syntax how to name these things and the parms that need to be passed
Conclusion: Not general agreement that this problem needs to be solved.
Eric’s proposal:
Ø Naming Services is the name binding problem:
o End user/proxy/application needs to direct call to application service entity
o Many ways to address application service entity
o No single “right way”, as in history discussion
Ø Problem Is bigger than SIP
o Appropriate technologies may be service registries, etc.
o PhD topic…
Discussion:
Ø Henning: rather than try to come up with a whiteline definition, propose that come up with a set of services that apply to this.
Ø Allison: Since this is a bigger than SIP problem, need to consider other application work areas.
Ø
Binding Published data to SIP -- Ben Campbell
very long mailing list thread beginning with:
http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg01544.html
Potentially many protocols
Ø Assume all use URI addressing
Ø All have own rules for URI interpretation and routing.
Ø Are schema sufficient protocol discriminators.
Client only
Ø Assumption that only my client needs to know bindings for my AoR.
Ø Is there any situation where callers need to learn bindings?
Publication Points
Ø Separable from service elements
Ø Pub URI may even have different domain than service URI
How often do bindings change?
Ø Rarely?
o Client infers algorithmically?
o DNS?
Ø Occassionally?
o Discovery at client startup?
Ø Often
o Discovery at every use?
Ø Need lifespan management
Client vs. Server Binding
Ø Server says “publish to this URI”
Ø Client says “read data from this URI”
Ø Do we need both?
Ø Second (client) may be aspect of first, with content-indirection.
Security
Ø False bindings could be dangerous
Ø Need to authenticate source of binding
Ø Need to prevent tampering with bindings
Ø Is the binding sensitive information
Ø Do we need auth/ auth on binding operation itself?
Ø Should publication URIs be hard to guess?
Ø Assume publication method has its_own_auth/auth model.
Discussion:
Ø Henning: there is no privacy implication of the URI itself. Anything we do seems to discourage this.
Ø In general, need auth when the data is “published”, not when the URI for the publish is “learned”.
Ø Acceptable to assume that client knows the type of things it will be publishing, thus don’t want the model where the client has to get knowledge (ala SLP).
Ø
Detailed Meeting notes mbarnes Tuesday 5/7/02
Mary is notetakerfor this session:
AAA requirements (Requirements) -- John Loughney and Gonzalo
Camarillo
http://www.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-04.txt
http://www.softarmor.com/sipping/drafts/draft-loughney-sip-aaa-req-00.txt
Discussion:
Ø Mary B: Is this a generic SIP AAA requirements doc or 3GPP or 3GPP2 specific. John L: Should be generic.
Ø Unlikely to update Calhoun draft.
Ø John L: Battle for AAA has been decided to be Diameter. Radius is deemed insufficient.
Ø Henry S: Does not agree.
Ø John L: IETF will not be doing RADIUS extensions.
Ø Allison: Solutions draft could be applied to RADIUS (due to DIAMETER compatibility with RADIUS). Propose RADIUS compatible AVPs for SIP work. This WG is not picking the technology.
Ø John L: There may be a general draft for using DIAMETER in a RADIUS compatibility role.
Ø Henry: It seems that we are throwing this approach (RADIUS) out.
Ø Allison: Problems with using RADIUS on a large scale. A lot of functionality should be transitional.
Ø Rohan: There’s nothing about this that says this is DIAMETER or RADIUS. Could use whatever protocol.
Ø Henry: Present version as it reads seems to restrict it to DIAMETER.
Ø Rohan: Would like to see Web services work (as referenced by Henry).
SIP Needs
Ø For AAA
Ø Are these needs modular? John L: Yes.
Ø Should they be?
Discussion:
Ø Jonathan: This looks to be 3GPP specific.
Ø John L: Shouldn’t be, but admits this was starting point. John is not SIP expert thus needs feedback to ensure generic.
Architecture needed
Ø Do we need to sketch out a roaming architecture for SIP where AAA is used, possibly in a modular way?
Ø Does multi-access make this interesting?
Discussion:
Ø Rohan: Question with regards to intent to cover access types in architecture.
Ø John L: May access as a subscriber with different access types. Services may have to vary depending upon access. Some things
Ø Rohan: SIP – you have one or more addresses of record, which can be associated with different access types. IF you’re accessing a SIP server that you normally don’t have a relationship with, but you want access. You could be doing this in a non-traditional, non-roaming perspective.
Ø John L: Unrelated, but needs to be brought out is that these requirements are meant to enhance SIP services and not detract. For scalability in some deployment scenarios, AAA can enhance the network services. These requirements should not burden SIP.
Examples
Ø Simple 3GPP example
Ø WLAN roaming using 3rd party service providers
Discussion:
Ø Rohan: SIP UA on laptop and want to make calls to the PSTN. Invites go to various gateway UAs which want to Authenticate subscriber.
Ø John L: Access and Service are tightly coupled. Access authorization should be separate from Service Authorization.
Ø Brian R: Simplest example would be an enterprise with multiple sites. This is much simpler than 3GPP and WLAN roaming. Requires cross site authentication.
Charts for General requirements (from draft)
Ø JohnL: SIP has its own Authentication and Authorization needs outside of this.
Ø Pulver: Explain this from a service provider perspective.
Ø John L: you can have a SIP session without a AAA infrastructure. It could.
Ø Allison: very simple example. User and your request for SIP Digest goes to AAA. 2 SIP proxies that speak TLS may not need AAA network. Whether they are or not should be transparent.
Ø Radika: Extension in SIP for this?
Ø John L: No. work may not require extra extensions for SIP. Could be some beneficial extensions to SIP.
Ø Radika: How do you make this happen?
Ø John L: Some SIP servers may need to talk to AAA. But, this is solution’s space.
Ø Henning: What’s meant by deregistration?
Ø Jonathan: You didn’t pay your bill.
Ø Dean: Registration is related to whether you can make calls.
Ø Rohan: The service they most often want to provide is prepaid.
Ø Mary: 2.1.2 is Cx interface. This is database access.
Ø Jonathan: Who knows about this?
Ø Keith: Doesn’t know this.
Ø Rohan: If we can’t think of a good use for this in the general SIP case, then push to the end.
Ø Mary: 3GPP uses DIAMETER for Cx and database.
Ø Others (John L, Dean, Keith, Mark): use for Authentication also to get vectors.
2.1.3 Updating SIP Server Entries is 3GPP specific.
2.1.4 Indication of Assigned Server is 3GPP specific.
2.1.5 User Deregistration
Ø Rohan: Re-write 2.1.5 – Want to be to support pre-paid.
o Brian: This depends, the requirement may indeed be generic.
o Jonathan: Authorization model for outgoing calls.
o Rohan: If we have a term that has a SIP connotation, should change.
o Henning: Does this mean that “Register” , SIP Server asks and AAA server sends a token, does this mean that AAA server instantiates the notion of telling SIP Server.
o John L: General requirement. SIP server asks and AAA replies.
o Keith: PP requirement is a PP2 requirement. Believes it’s valid to remove a SIP registration.
o Rohan: There’s a lot of motivation for a requirement to do prepaid type of services. This is a useful requirement.
o Keith: What he’s saying is that both requirements exist. 3GPP requirement to remove a user’s association of proxies.
o Brian: Want deregistration for paranoid IT department.
o Rohan: What does this have to do with Registration.
o Brian: Basic SIP, want to turn off services.
o Rohan: Authorization Policy decision for operator. You could remove registration, but this is NOT the only way to solve the problem.
o Cullen: Meta-comment with regards to architecture with information PUSH. Do we want that as a requirement?
o John L: perhaps this should be a MAY
o Mary: this PUSH may be more related to DB access.
o Henning: Trying to do several things. Implement services. Also, saying how you could use AAA to do this. 2. Trying to define what AAA should do. 3. Not all of these are needed for every configuration.
o John L: solutions MAY provide that.
o Aki: DIAMETER provides other stuff. AAA Server can direct what kind of accounting can be done.
o John L: DIAMETER and SIP are similar in the protocol stack. APPLS on DIAMETER for SIP services. What are the needs to build APPLs on DIAMETER?
o Mark W: If you’ve obtained Authorization; if Authorization stops, how quickly do you want to enforce that? If a longer duration is acceptable, then that allows Registration related interval, however, this won’t work for prepaid where need realtime response.
2.1.6 SIP Server Allocation is 3GPP specific.
Ø Brian R: You have both to worry about. But, think this is a general problem.
Ø Sanjoy: Why is 2.1.6 a AAA problem?
Ø John L: Agree, this is 3GPP specific.
Discussion:
Ø Henry: Is there any idea of how call setup delay will increase?
Ø John L: Yes, this is a valid requirement that should not unduly impact realtime.
Ø Keith: You’re probably willing to wait longer for Auth during Registration.
2.2.1: Authentication Based on SIP REGISTER
Ø Rohan: Reword 2.2.1 to say “Authentication of SIP Requests”
Discussion:
Ø Henry: Handoff with these Authentication processes.
Ø John L: This is a different layer than SIP.
Ø Keith: If you’re moving out of area, Registration is lost…
Ø John L: Will you do handoff between service providers?
Ø Keith: Not during active call, you would need to re-register.
Ø JohnL: Is requirement that you should be able to move and roam?
Ø Henry: SIP doesn’t know about this.
Ø John L: What is the requirement?
Ø Keith: Changing servers doesn’t change registration. Changing providers does.
2.3.1: Ability to Authorize SIP Registration
Ø AKI: Should be Authroizing a SIP request.
Ø Allison: should flag any of these that are doing a AAA operation as part of a SIP request or per call.
Ø Cullen: Lots of info to pass as part of Authorization (from SIP server to AAA server).
Ø John L: Word as supporting “ disparate information as part of authorization decision”
2.4 Accounting
Ø Aki: General: How do you bill a SIP session?
Ø John L: Need a flexible approach.
Ø Brian R: This is a common problem: billing SIP services are hard.
Ø Allison: Perhaps, need an appendix to this document on how to deal with this.
Ø John L: This could help firm up the requirements.
Ø Aki: you can collect this info for trend analysis. .
2.4.1 : Separation of Accounting INformation
Ø cullen: Session duration is a complicated topic – at what point does session start (Invite, …)
Ø John L: Service providers should be able to specifiy.
Ø
2.4.2 Accounting Information Related to Session Progression
Ø JohnL: likely related to prepaid
Ø Keith: Not sure that right information is being conveyed. In 3G, want to transfer information during progress of session. Don’t think this is necessarily related to the prepaid.
2.4.5 SIP Session Changes
2.4.6 Support For Accounting on Different Media Components
2.4.7 Support for Cumulative and Non-Cumulative Accounting
Ø John L: This is from earlier document.
Ø Jon P: Stateful and Stateless.
Ø Cullen: IF this is just when call started or when call ended, then agree to this general requirement.
2.4.8 Configuration of Accounting Generation Parameters
2.4.9 Ability to Relate SIP Session to Access Bearer Used
Ø JohnL: this is likely a 3GPP requirement.
Ø Mary: This this should go away.
Ø Jonathan: this is bad.
Ø Keith: Don’t think this is PP specific. P-headers are intended to provide correlation.
Ø Cullen: Generalized requirement: Support arbitrary correlation Ids.
2.4.10 Ability to Transfer Accounting Server Information
Ø Cullen: What does this mean?
Ø John L: Just specifying that need ability to do so, not specifying how to do so.
Ø Jon P: Auto-configuration?
Ø Cullen: Support an automatic discovery process.
Ø John L: this could fall into a general requirement, for sip configuration
Ø Henry: Nice to be in terms of XML files, etc. Should use same mechanism that is used in the Internet.
4 Security Considerations
General Discussion:
Ø John L: Question to chairs: Thinks there’s a need for this document. After this document is done, what do we do? Does this require additional work in SIP or AAA?
Ø Brian: Want requirements documents out of SIPPING. Put a small design team together to determine where this needs to be done. We may have to force requirements over to AAA.
Ø Henry: Needs more than AAA. This ties you to business support systems. 1. How does SIP Server interface/interact with AAA? 2. Billing: billing is tied to business support systems. Business support systems are all based on XML.
Ø Allison: A design team is a good idea, because there is need to do some homework. There’s been lots of homework done on XML by AAA-Arch and AAA WG. Gathering the knowledge base from that work into a small group better than doing it on the fly. Don’t want to do this just in SIP. See a BCP for SIPPING to ensure that we properly influence other bodies. Need more homework.
Ø Aki: whether Accounting server is DIAMETER. You need a backend from AAA server that you could tie into business system.
Ø Henry: backend is considered front-end by some J
Ø Allison: nothing stops you from developing whatever interface you want from the accounting record. How much needs to be done in IETF.
Ø Henry: agree don’t want to take on design work from others.
Ø John L: points back to 2.1.1.
Next Steps
Ø John L: Should this in general be a WG draft?
Ø BrianR: can’t make a WG item decision at an interim meeting; take discussion to the list.
Ø AKI: SIP-AAA list.
Ø Allison: keep on the SIPPING mailing list.
Ø Henry: propose coordination with AAA-arch and AAA folks at next IETF meeting. Mobile IP WG has gone through this.
Ø Allison: Mobile IP is struggling because they didn’t do upfront work.
Ø Henry: AAA WG has fixed itself on DIAMETER. May want to argue that identity should be XML based.
Ø John L: SIP must be able to derive SIP identity from network identity. May not be the only way.
Ø Aki: in Digest, you already have the concept of a non-XML based identity.
Ø Henry: need an identity that is compatible with Internet payment systems. Don’t need to repeat the AAA WG screw-up.
Ø Jon P: Talk about the kinds of identities in SIP and then decide.
Ø Rohan: Requirements should be generic enough.
Ø Jon P: We have a base specification that already discuss authentication and authorization and new network identity stuff.
Ø John L: is this reasonable.
Ø Allison : This is perfect. Nothing should be dictating content or form of data. You don’t get XML document built into SIP. Won’t belabor AAA/Diameter spec issues.
Ø Sanjoy: Does diameter support XML based AVPs.
Ø John L: Appls on DIAMETER can support this; may need specific extensions.
Content Indirection (Jonathan Rosenberg)
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt
History – basic problem is in sip envents, we had ability for NOTIFY to contain a URL to find the state instead of the state itsleft. Thought it was a gernally usefully thing. Just as draft was about to do to draft it got pulled out – several reason but iuncplude that this was not really anotify specific mechanism. Seemed that lots of things, particularly IM cases, would want to send just the URL then the receiver can decide when if and how to fetch the resource that the URL refered too. Took this to sipping to gerneatrate this draft.
Ø Henning – Closely related to earlier work on web change notification in draft-wu-sipping-webshare-00.txt
Ø Jonathan: Why is this a remotely hard problem? Issues such as lifetime: how long is the URL good for?
Ø Rohan: Am I publishing presence doc or giving you a URL from which to render data?
Ø Jonathan: Want to be able to PUSH content with versioning, such that you know whether you need to get new content.
Ø Henning: There is a strong connection to the publishing issue. Discussion seemed to point to certain architecture. Does it make sense to treat these as separate problems OR should we look at this as 2 facets of the same problem that overlap.
Ø Jonathan: If publish should be done as SIP PUBLISH. This problem is an upward reference to the other.
Ø Henning: can see the same mechanism working in both cases. A variety of SIP methods contain a list of URLS with expiration and type information. Can stick same header in the NOTIFY and it would do the same thing.
Ø Jonathan: One problem is a customer of the others. Can you “publish” mechanism to achieve the content indirection.
Ø Henning: Publish requirements can be folded in here.
Ø Rohan: Why should publish requirements be applied here.
Ø Ben: requirements are separate, BUT the same mechanism can meet both sets of requirements (e.g. lifetime of URL). IF you add: Is this URL rewriteable, then you get very close to PUBLISH requirements.
Ø Henning: Only difference is direction.
Ø Ben: requirements are generically different, but both can lead to a common mechanism.
Ø Rohan: you don’t need an explicit direction. HTTP URI with method = POST – writing.
Ø Henning: May not care about R/W. What you care about is the protocol equivalent things that you can apply (e.g. GET/POST). Don’t see customer relationship. One comes from a read perspective, another a write perspective.
Ø Rohan: Content indirection doesn’t have to be read only. Content Indirection is more generic than publication. PUBLISH may be a trivial use of content indirection.
Ø Jonathan: Henning seems to be proposing that these requirements include the PUBLISH ones. Haven’t thought about this in that perspective. Content vault introduces more requirements.
Ø Ben: Don’t want to merge requirements. Want to know what it is you want to accomplish. Agree mechanism is likely to be similar, but don’t want to force same solution.
Ø Rohan: There are uses for this outside of publish. Requirements should be kept separate. Mechansim work later can incorporate both later.
Ø Related to this is the fact that
REQ-2: It MUST be possible to specify the purpose and disposition of
each URL independently. At a minimum, the following
dispositions SHOULD be supported:
* render: the content should be rendered
* publish: the content contains service data that the
client wishes to push to the server
* retrieve: the content represents data that is to be
shared between the client and server
* execute: the content represents executable data such as a
script that is intended to be executed as part of the
processing of this request
Discussion:
Ø Jonathan: finds this confusing. Any disposition in Content dispostion header should be able to go here.
Ø Henning: Note the use of publish.
Ø Ben: using content indirection to publish.
Ø Adam: Replace “Server” with “User Agent Server”
REQ-6: The mechanism MUST ensure that the element which uses the URI
will be able to access a content type it understands. This is
to avoid losing the ability to negotiate content types when
using the content indirection mechanism.
Discussion:
Ø Jonathan: Implementation choice in SIP (JPEG or GIF) , should be same here.
Ø Roni: You know other side cannot handle the format until after you send it. Should be able to determine before you send.
Ø Jonathan: We’re not looking to solve the RESCAP problem. Want to make sure existing SIP functions are lost.
REQ-8: It MUST be possible for an automaton to process the content
indirection without human intervention.
Discussion:
Ø Jonathan: Normal assumption that other end (automata) can handle the content
REQ-9: It MUST allow for indirect transference of content in any SIP
message which would otherwise carry that content as a body.
Discussion:
Ø Rohan: Should exclude bodies with SESSION.
Ø Cullen: can’t lead to clients MUST support HTTP.
Ø Rohan: What if content expires, thus the indirection problem does become more difficult. You’re not providing enough information to understand why this break.
Ø Jonathan: New requirement: for additional errors or warnings.
Ø Rohan: Very little motivation for doing indirection of OFFERS/Answers.
Ø Jonathan: Why is OFFER/ANSWER worse or better.
Ø Rohan: Content is typically optional.
Ø Johnathan: what is requirement? Only work for optional content OR should it highlight potential problems.
Ø Rohan: Requirements: 1. Way for appropriate errors/warnings. 2. Verify that you don’t break Offer/Answer model with content in sessions.
Ø Jonathan: Protocol already supports this. Should highlight areas where the use of this would be inappropriate.
Ø Peter: When do you send the 200 OK.
Ø Jonathan: after you retrieve the URI.
Ø Ben: The distinction between an error due to indirection piece (eg.. Notify with indirect body. Is 200 OK to indirect body). Thus indirection must complete before 200 OK, thus timing issues.
Ø Adam: don’t think this is an issue.
Ø Jon P: IF mandatory should fail the message. Might want to have SDP for content indirection for encrypting or signing, thus it’s larger than useual.
Ø Jonathan: Requirement for being able to indicate whether message should be responded before or after content fetch. May need to couple with optional or mandatory.
Ø Roni: How will you know receiver of message can handle? (Requirement 6)
Ø Jonathan: Don’t loose negotiation capabilities from before.
Ø Cullen: What is real motivation behind requirements? Is this a mechanism for dealing with blocks that are too large for UDP messages OR a SIMPLE requirement?
Ø Jonathan: Started solving problem in different application contexts. What is the broadest general problem? “Sending content indirectly”
Ø Adam: Timing issue is a red herring. It’s not any different than when you have to fetch things vs proxy having to interface with something else before sending response.
Ø Peter: You have 2 types: immediate ack, can await an ack. Do you have a means if you’re delaying?
Ø Jonathan: Agree that you need the 2 types. Additional requirement for notification later if there’s a failure to an already responded to.
Ø Sanjoy: 100 trying. Download can’t send a response.
Ø Jonathan: Again, agree that there are 2 types: immediate response (optional), delayed (mandatory). This is another requirement for an additional notification for the immediate response scenarios. In SIMPLE, handling this case for IM by adding a success/failure indication. Broadening of that requirement.
Conclusion: Req-9 is a requirement.
More Discussion:
Ø Rohan: believes that content indirection only makes sense for optional.
Ø Jon P: new status code to indicate that you couldn’t process because you couldn’t retrieve indirect content. Why not allow?
Ø Rohan: Just because you can, doesn’t mean you SHOULD?
Ø Jon P: Sees uses for this for some devices.
Ø Rohan: Asking UAC to be well behaved in one way, but not in another.
Ø Adam: EG: page mode message with a URL.
Ø Henning: Recipient can decide how important call is. May decide that you can pay to download URL OR reject, thus allows recipient some control.
Ø Rohan: These things are going to have to be processed automatically.
Ø Jonathan: Fetching would only happen if rest of message was handled successfully.
Ø Joerg: Agrees with Jon P’s approach.
REQ-10: It MAY allow for indirect transference of content in any SIP
message which would otherwise carry that content as part of the
SIP headers. In other words, a SIP message with a large number
of headers could transfer the content of those headers
indirectly through this mechanism.
Discussion:
Ø Rohan: This seems bad.
Ø Allison: This seems to be really inviting trouble.
Conclusion: Remove Req-10.
Next Steps:
Ø Update requirements document.
Discussion:
Ø Rohan: Concensus on requirements, can we start work straight in SIP?
Ø Jonathan: Get this added to charter, finish requirements in SIPPING.
Ø Allison: Fits in existing charter. Publish requirements.
Key Events/ Stimulus Markup – Bert Culpepper & Jonathan Rosenberg
http://home.cfl.rr.com/bculpepper/draft-culpepper-sipping-app-interact-reqs-01.txt
R5: The protocol mechanism must provide a means for a network
entity to indicate its desire to receive user activity
indications and/or to present an application interface on the
User's UA. The protocol mechanism must provide a means for a
SIP UA receiving a request to respond with its
capability/intent to provide the requested services.
Ø Have rewritten the requirement to specify behavior for the protocol agent
R-8: The mechanism should support devices that possess a UI, and those which do not possess a UI.
Ø Thus, R-8 has been reworded.
Ø Discussion:
Ø Jonathan: Some devices have a display capability. Some devices (i.e. black phone) don’t have this.
List comment: The mechanism should be capable of handling Uis from simple screens
……
Reworded R-10:
List comment: The mechanism should allow the user to interface with multiple user interfaces for different applications within the same call.
Ø Bert’s Comment: Took this to mean that the mechanism should somehow dictate the user interface of the device.
Ø Thus, added R-18.
The mechanism should allow the user to know which appliction is associated with which user interface/input.
Ø Added R-17.
The mechanism should allow a device ….
…
Ø RFC comment: Described the view of the virtual instance of a device’s physical UI that can be “placed in focus”. BC: This is a device thing.
Ø JDR: The mechanism must support providing a display.
Added R18, R19 and R20:
R18: The mechanism must support the ability for multiple virtual
user interfaces to be associated with the same user session.
Each virtual user interface may be associated with the same or
different applications. For example, a user may want to
interact with a voice-recording application and a prepaid
calling application within the same call but allow each
application to use a different virtual user interface.
Discussion on the concept of the virtual instance:
Ø Jonathan: How can multiple apps cooperate within the same Virtual User.
Ø BC: Not sure what’s RFC’s point.
Ø Matt H.: Multiple Uas in virtual manner.
Ø Jonathan: An example would be a call from a PC interacting with VRU and prepaid app. One model would be 2 screen pops with view on each appl. Overall app is the entire monitor. Each app views that it has ownership of the entire screen.
Ø Henning: terminology is unusual.
Ø Jonathan: Makes sense for a screen with buttons, screen area maps to a button. The phone figures which app gets which buttons. A similar concept of “windows” as far as resources.
Ø Henning: perhaps logical versus physical. Physical representation is independent of logical. Can be represented in many ways (softbuttons, screens, etc.)
Ø Jonathan: can figure term later. Should this be part of requirements? Requirement for multiple Apps to I/F with user.
Ø Cullen: Not one type of focus: keyboard, voice, etc. Event model of vitualizing these events to the “windows” needs to be described.
Ø Jonathan: will depend upon markup types. DTMF case is really hard. Requirement should be to focus this to a specific markup.
Ø Matt H: ability to have a virtual I/F across multiple physical. Virtual User I/F that work across multiple types of input.
Ø Jonathan: there is a requirement that it support a wide range of devices.
Ø Matt H: 2 way – responding back must support this.
Ø Carl/Pulver: need to eliminate the word virtual. Stuck in the paradigm of DTMF.
Ø Bert: Likes Hennings “logical” versus “physical”
Ø Sanjoy: Support context: Will DTMF need this concept?
Ø Jonathan: markup proposal is to provide context. With markup proposal, yes.
Ø Bert: Context would be indicated through the subscription.
Ø Jonathan: How does a user know: prepaid vs. voice recording when user presses #? With markup: user can provide context, thus no feature interaction problem. Need to support the case where you can’t have context. Don’t want this to be the paradigm to be supported.
Ø Bert: believes this is a device problem. Logic would have to be inside the device and defined in the package.
Ø Peter: need to be able to present markup on a dumb device.
Ø Sanjoy: when you’re sending notification: event name tells you the context. How do you map key to specific event notification?
Ø Jonathan: you’ve wandered away from requirements. From a requirements perspective, does appl provide a context?
Ø General agreement on this requirement.
R19: The mechanism must support the ability for multiple
applications to explicitly cooperate within the same virtual
user interface. Specifically, each application may be
associated with different UI components within the same virtual
user interface.
Ø Bert: believes R19 needs to be cleaned up.
R20: The mechanism must allow user interface components created
through this mechanism to be updated or removed as desired by
the creating application entity.
List comment: The mechanism must allow a user to have assurances that the user input it is providing is only to applications/servers on the call path between caller and callee.
Ø Reword R16:
Reword R17:
R17: The Reporter must be able to identify and authenticate the
Requestor for each user interface component. Specifically, in
the case where the Requestor is an Application Entity, the User
must be able to identify the application name & instance. An
application instance consists of the application type [e.g.,
applications name, version & application designer name] and
application instance [e.g., instance identifier & service
provider's identity].
Ø Jonathan: how do you know appl should legitimately get feedback? This should be an expression of authorization policies.
List Comment: The mechanism must work with applications that are both proxy and bbua.
Ø Author’s comment: Authors feel that the requirements are for the protocol agent and this requirement is addressed.
Ø Jonathan: SIP piece could be a proxy.
Robert’s new questions:
A) Are people sufficiently interested in pursuing and solving the more general problem of representing input-based UI components beyond the simple telephone DTMF dialpad at all?
B) If so, do we want only one general key-based interaction mechanism where DTMF dialpads are simply a particular key-instance within that mechanism; or do people want multiple mechanisms; …
Conclusion: Bert: will update doc and sendout.
Markup as a Framework for App Interaction (Jonathan)
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt
What’s the idea
Ø General problem is to provide stimulus input to network applications.
Ø Stimulus signaling has 2 aspects:
o A disply to guide the stimulus
o A way to collect the stimulus and send it to the application
o May not be a display (black phones)
Ø Markup languages (HTML, WML, VoiceXML) are targeted at this functionality.
Basic Flow
Ø UAC sends INVITE
Ø Apps return 183s with app-info header (contains an HTTP URI for fetching markup)
Ø Caller fetches markups (can use CC/PP to handle UI variations, Fetches from each app)
Ø Renders/executes markups
Ø Input Posted to URI in markup (may fetch more markup)
Handling Display-less UI
Benefits of this framework
Ø Supports a vast array of devices under same model (PCs, wireless phones, virtual reality I/F, etc.)
Ø Treats display less UI as a subset of general case
Ø Simple for simple devices (Barebones HTTP and trivial XML)
Ø Allows for reuse of existing w3c work in this area (HTML, VoiceXML, CC/PP)
Ø Provides a sane model for involving multiple applications (separate vitural UI-screen pops, dividing button real estate, etc.)
Discussion:
Ø Cullen: Agree on XML, but believes that HTML will continue to get more complex.
Ø Jonathan: Don’t want to limit solution.
Ø Henning: W3C approach (???).
Ø Jonathan: This is SALT. The point of this proposal was to support that sort of stuff.
Ø Rohan: The DML seems to be lacking the ability to specify a “long” pound.
Ø Jonathan: IF you want that, do it.
Ø Dave O: it’s in the MGCP digit map stuff. You’d need some way to encapsulate the digit map and the parms.
Ø Jonathan: Can add all that’s required as far as timers, etc to this proposal.
Ø Jonathan: Framework allows UACs to know the order in which they were encountered.
Open issues:
Ø Do we want a general framework this this or should we focus on key –events….
DML issues:
Ø How to handle multiple DML docs?
o Fork DTMF to each
o Prioritize them, define pass-trhur models
o Prioritize them, highest consumes until it terminates
o Others?
Ø How to prioritize them?
Ø What are the models for passing through?
Discussion:
Ø Mike P: confused about how DTMF is being used here. Sometimes it’s the AVT aspect and sometimes it’s a reference to the keypad.
Ø Jonathan: from UA, it’s the 12 key keypad.
Ø Rohan: Do you want to use the term signaled digits?
Ø Mike P: should remove the term DTMF.
Ø Mike P: Need to indicate that a button has been pressed for an amount of time.
Ø Dave O: This has nothing to do with DTMF as a physical layer encoding of button presses. BUT, as a stimulus package to capture low-level user interface actions.
Conclusion: General agreement that this is the right framework with which to continue.
END: Mary’s role as notetaker for morning session:
Privacy and Network Asserted Identity (Direction Forward) -- Cullen
Jennings
http://ties.itu.int/~watsonm/draft-watson-sipping-nai-reqs-00.txt (Mark)
Short term Network Asserted Identity requirements
2 motivations:
Ø Network intermediaries (proxies or CSCFs in 3GPP) need a reliable authenticated identity of the caller
Ø User Agent will find a more reliable user identification useful, if UA cannot Authenticate other UA directly
Applicability:
Immediate requirement is for a mechanism which works within a “trust domain”
Ø Nodes in a trust domain are known (by the human network designers) to obey the Network Asserted identity specifications (Spec(T), where T is the Trust domain, A “is a member of” T -> obeys Spec(T))
Ø A given node in the trust domain knows (by configuration)about some other nodes in the domain
Ø Nodes in the domain are securely interconnected.
Terminology:
Ø Node A is trusted by Node B iff:
o Node b knows (by configuration) that Node A is in the Trust Domain and
o There is a secure connection between Node A and Node B (integrity, confidentiality)
Ø Symmetrical within network – A trusts B iff B trusts A
o ….
Implications of Trust domain model
……
Out of Scope:
Ø How to identify privacy requirements
Ø Privacy services required (+ user/subscriber debate, etc.)
Ø Contents/meaning of From: field
Requirements:
Ø NAI1: generate NAI and pass to trusted node
Ø NAI2: A sends NAI to B for case A does not trust B, but B does trust A.
NAI received from a node you do not trust is garbage – DISCARD!
Discussion:
Ø Need to add: If NAI is private and you know it’s going to a non-trusted node
Requirement not addressed:
Ø User Agent providing hints to network entity to help generate NAI
o -EG User Agent’s preferred NAI – where it has several that would be equally valid from the network’s point of view.
Additional issues:
Ø How many NAIs?
o Possibility of a user with both a SIP URI and a TEL URI?
o NAI is Network Asserted version of From: what about a Network Asserted version of Reply-to, call-info, etc.?
Ø Parties with NAI?
o Sender of message (request or response)
Ø Privacy of NAI?
o User must indicate privacy preference for NAI.
o Privacy: header? Timing?
Discussion:
Ø Dean: propose to restrict short term requirements to only include NAI for From.
Ø Keith: 3GPP requirements for June. Also need to consider ITU requirements. Would like to see used for Reply-to also.
Ø Jonathan: What application are you trying to solve? Need a higher level application to drive it. Even 3G should be able to do it from this perspective.
Ø Henning: fundamental difference between simple identity and auxiliary info that requires a certain model about what information is stored for a subscriber. This should be out of scope.
Ø Mark: mechanism should be extensible, but did not include the more general requirements.
Ø Dave Oran: Reply-To.
Ø Keith: proposing the use of the Network asserted form thereof.
Ø Jon P: a separate issue for SIP to ISUP mapping.
Ø Mark: the way that ITU are approaching the SIP to ISUP mapping, they’ve come to the conclusion that they don’t have this info (calling line identity, but there is a history of problems caused by the single identity).
Ø Jon P: perhaps we need an addendum to our SIP-ISUP mapping to address this.
Ø Keith: Long term, need to authenticate any identity provided in SIP. Thus, this isn’t out of scope. Already have 2 identities in the PSTN.
Ø Henning: carrier has no mechanism for validating some of these things (i.e. Reply-to number) .
Rohan: What do chairs think?
Ø Brian R: Doesn’t see an issue.
Ø Dean: wants to make sure he understands. Example: making a phone call and have call barring activated. Reply-to is admin number. Just as henning was saying, there’s no way for network to assert the identity.
Ø Mark: the answer isn’t in realtime verification. In the UK, there are regulatory rules about the numbers the user can use.
Ø Dean: If we have 2 conflicting sets of requirements. What Keith wants has nothing to do with reply-to.
Ø Keith: What are the semantics of reply-to.
Ø Mark: there are differents in PSTN. In SIP, there are no restrictions to what you can put in reply-to. IN PSTN, CLIP service has regulatory rules about this number.
Ø Dave O: suggesting that there are network operators in a special position – there are network trust boundaries.
Ø Jonathan: What’s the minimal thing that needs to be done for 3GPP? Don’t see the need for this – network authenticated Reply-to header.
Ø Rohan: Agree that there is concensus for Network Asserted From.
Ø Keith: Never said the service would be useless without Network Asserted Reply-to…..Believe that this is in the long term requirements.
Ø Cullen: This has not been considered in any of the drafts being discussed.
Items for decision
Ø Requirements to WG item?
Ø Solution discussion to SIP list?
o Revision of remote-party-id? OR
o New draft (cullen’s)
§ To WG item after list discussion?
§ Move forward to 3GPP timescale?
Ø Hints requirement
Discussion on how to go forward – Rohan had wanted a hum vote:
Ø Jon P: proposed that the decision to continue this work be deferred until after discussion of long term.
Ø Allison: Trust definition needs updated.
http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-04.txt
http://www.ietf.org/internet-drafts/draft-peterson-sip-privacy-longterm-00.txt
http://www.ietf.org/internet-drafts/draft-peterson-sip-identity-00.txt
JonP: Discussion on short term vs. long term
2 key propertiess:
1.Know who it was that generated identity (trust is end to end and NOT hop to hop)
2. Must assume behavior is homogenous – MUST rely on someother entity in network to know when to remove data (short term), whereas long term work has this done by the involved parties.
Discussion:
Ø Dave O: the degree of trust shouldn’t be related to the mechanism used for auth. Trust is an assertion from outside the system.
Ø Rohan: recalled writing applicability scope and issues weren’t raised then. Is this that important that can’t allow work that doesn’t have that property.
Ø Dave O: What protects the misuse? This doesn’t give origin authentication.
o Jon P: Believes draft gives clear guidelines.
Ø Dave O: an authenticated ID without a signature over the message is of marginal utility.
Ø Rohan: a digital signature over an NAI without replay protection.
Ø Jon P: believes that what’s specified in the draft will deal with this.
Ø Cullen: point on 2 above, someone will misconfigure a proxy.
Ø JonP: yes, you can also share private keys.
Ø Rohan: it’s significantly easier to misconfigure a chain of trust than to lose a key. Peterson identity draft is useful. Thinks this absolutely needs to be done.
Ø Jon P: Issue that needs to be discussed is what to do with short term work and whether (and how) they co-exist.
Ø Jonathan: one hope for the privacy draft was that an alternate mechanism would come that would extend that. Easier to say that we’ll do a short term thing which is a subset of the longterm.
Ø JonP: MIME bodies in identities without S/MIME.
Ø Dave O: Believes the mechanism fails if it’s not cryptographically pure. Should add non-repudiation to this.
Ø Rohan: Do we do longterm, shortterm or both? Need longterm work, but shortterm work is required to support current implementations. The transition could result in mismatches between UA and network. Doesn’t see a lot of interaction problems.
Ø Jonathan: BBUA thing – debated amongst the editors about modifying bodies. Once the draft is reved, if they can recognize that it won’t impact– shouldn’t restrict because BBUAs are bad.
Ø Henning: we’re not moving from 0 to 1, but from 2 to 3. NAI, certificate and trust based one. Imposes a policy concern, but already need to make a decision.
Ø Jon P: need to consider “cost” of having both solutions.
NAI in header vs. body
Header
Ø Easy to add/remove for intermediaries
Ø Difficult to stage PKI (easier to stage Digest-ish security)
Body
Ø How doe an intermediary add the body?
Ø Can reuse S/MIME/PKI (but who supports S/MIME)
Ø Easy to record multiple headers worth of data
Ø No length concerns (but who supports MIME multipart?)
Discussion:
Ø Henning: Doesn’t like artificial limitations on lengths in headers vs. bodies.
Ø Jonathan: there’s was lots of pushback against this previously was that this was difficult, etc.
Ø Henning: Another concern is a we have SIP servlets, CGI and CPL make assumptions about the info they can access. They have a strong preference to peek in headers and not in bodies.
Ø Rohan: including certificates is a barrier either way, S/MIME isn’t a barrier.
Proxying vs. Rejecting for Retry
Ø Authentication service can choose to add an auth-id body to requests itself
o One less RTT
o However, Proxies should not tamper with bodies
Ø Authentication service can reject the request with a new status code (428) containing an auth-id that should be used by the client
o Redirection is always more secure than proxying
o Data can be hidden from originator by encrypting the auth-id body if necessary
Discussion:
Ø Mark: How is mode specified?
Ø Jon P: Authentication service decides based upon level of client support.
Ø Henning: doesn’t see supported stuff in the draft.
Side discussion on Pre-loaded route
Ø Jonathan: don’t like that idea. Working on an alternative.
Ø Jon P: have a slide on that topic,
Another side discussion on Forking
Ø General agreement that you’re not going to fork before you hit this functionality.
Routing Requests through Privacy/Authentication Services
Ø Services like privacy and network authentication need to be inserted into the path of requests
o While some privacy functions can be completed by the client, others are the responsibility of the network.
Ø Best if these services are co-located with a local outbound proxy for an administrative domain
o Although privacy may require services provided outside the local administrative domain (onion routing)
o Authentication services should use the same credentials that are provided when a user registers
§ An identity means you are eligible to receive requests for that AoR.
Hostname conventions
Current draft proposes a hostname convention for Authentication Services
Back to general discussion on whether we need to do this – identity..
Ø Dean (as WG chair): Privacy/Security is one of the chartered elements for the SIP group. This fits.
Ø Mike Pierce: 2 things: 1. Removal of network asserted identity 2. hiding data that is in messages from being viewed by an intermediary.
Ø Jon P: Certificate based vs. Trust based issues.
Ø Dave O: Bias to doing this stuff in 1st hop proxy – signing operations are very expensive. Don’t want to have to produce one at any point sooner than when you’re going to need it.
Ø Jon P: mechanism to allow host to reject request. Don’t always have to use Authentication service.
Ø Dean: something similar came up in 3GPP. Need to do at 1st hop – P-cscf.
Ø Jon P: with 1st hop have reference integrity.
Ø Henning: carrier with whom I have a business relationship is outside proxy, this becomes much less useful.
Ø Jon P: SIP/S helps out here – makes it more secure if you’re not directly connected to Auth server. Should try to have onehop to Auth service, if not should use SIP/S (per current bis).
Conclusion:
Ø Advance both shortterm and longterm
Ø Dean: Have a requirement from 3G contingency to progress a solution by June.
Ø Mark: short term approach works well if the trust is already setup for another reason.
Ø Dean: Will we have a complete solution with certificate model by early June?
Ø Jon P: Believe that there’s a lot of work to go into shortterm, as well.
Ø Dean: Is it reasonable to presume that there would be something based on Cullen’s draft in early June?
Ø Mark: There is some scope for working deadline within a reasonable number of weeks.
Ø Allison: 3GPP had good reason to doubt that this would get out in time, due to last minutes concerns on security issues. Think that we could have a WGLC to start on May 31st and get RFC number in time for 3GPP.
Ø Dean: Can we get a short term solution based on Mark’s requirements?
Ø General agreement that requirements can be out by the end of this week (action on Mark).
Ø Dean: Can we get a short term solution that’s a subset of the longterm?
Ø Jonathan: Is is true that this longterm identity information is a superset of the short term?
Ø Jon P: Not sure. Need to work through.
……break…..
Do we agree it’s header or body based?
Ø General agreement for body based.
General discussion continues.
Ø Dave: confounding of security mechanisms and level of trust. Both long term and short term must address call trace, which is where these 2 things intersect.
Ø Discussion of multiple keying for call trace.
Ø Matt: we’re setting up the mechanisms and are not defining the policies.
Ø Cullen: it will work either way.
Ø Keith: if you’re going to define call trace, you don’t go outside the trust boundaries.
Ø Allison: it would be useful for some of this stuff to go ahead and document it, particularly with regards to call trace (in an informational).
Ø Henning: Multiple key issue will likely be quite common.
Cullen: Previous discussion on 2 approaches: header in body long term, header short term.
Ø Jon P: need to reread Mark’s requirements.
Proposal:
Ø Draft-watson-sipping-nai-reqs-0.txt Adopted as SIPPING WG document for Identity (and published as informational).
Ø Draft-peterson-sip-privacy-longterm-00.txt becomes WG document for SIP privacy
Ø Draft-jennings-sipping-NAI-00.txt REPLACES draft-ietf-sip-privacy-04.txt (MUST satisfy Watson requirements draft and MUST co-exist with and MAY be a subset of draft-peterson-sip-identity-00.txt)
Ø Draft-peterson-sip-identity-00.txt ADOPT as a SIP WG document ?
Future Security Needs (Discussion)
http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-00.txt (Vesa)
Ø SIP WG draft undergoing WGLC.
Ø Changes:
Ø New syntax:
Ø do not use option tags
Ø Relative position not related to semantics anymore
Ø SIP Error codes included
Discussion:
Ø Rohan: UA stuff is spread throughout document. There’s nothing that addresses the scenario where there is no response at all to UA.
Ø Jonathan: lots of problems with options (and forking). Syntax is broken. You can’t use commas to separate elements that are part of the same header.
Ø Rohan: It wasn’t clear that you would have multiple security mechanism headers. Will work with them to ensure syntax is correct.
Issues:
Ø Table 2 questions:
o Can this be used with Subscribe?
o Use of the header: conditional/optional?
Ø The use of 421 (Extension Required)
Ø
http://www.ietf.org/internet-drafts/draft-undery-sip-auth-00.txt
http://www.softarmor.com/sipwg/drafts/draft-thomas-sip-sec-req-00.txt