CONSOLIDATED, UNEDITED, RAW NOTES FROM SIPCORE IETF90 MONDAY

_______________________________________________________________________________________
RAW NOTES BY BRIAN ROSEN

Monday Session 13:00 Notes by Brian Rosen
Clarifications on use of REFER (Robert Sparks)
       draft-sparks-sipcore-refer-clarifications-00
 AR and Christer what to know about contact in dialog REFER
 RS: Can we say "If you send REFER in dialog, use whatever your local contact is"
 Room seems to agree
 There was a proposed update to 6665 to clarify to use GRUU in any dialog creating message
 Andrew: that's what I thought it meant, but clarify is okay
 Keith: who is modifying what doc?
 Robert: Separate doc to update 6665
Doc will be revved soon     
Explicit Subscriptions for REFER (Robert Sparks)
       draft-sparks-sipcore-refer-explicit-subscription-00
Nosub option tag
Andrew: May not get used much
AUthorizing refer sub (proposal is possession allows it, temp GRUU can be used)
Andrew: how about target dialog?
Robert: Don't know in advance who the target is always
<big discussion on whether temp GRUU is practical
Jon: not a great leakage of data even if compromised
Doc will be revved soon
Keith: Does this doc update anything?
Robert: No.
Christer: Support and will review
Jon: STIR refer baiting problem - is there some interaction
Robert to Brian - would you think about this?
Brian: Yeah
Using OAuth for SIP Authorization (Rifaat Shekh-Yusef)
       draft-yusef-sipcore-sip-oauth-00
       (draft-yusef-sipcore-digest-scheme-04)
Jon: 401 wont work
Robert: Do the work in HTTP, get a token, use that
Adam: Use case not clear enough
<lots of discussions on possible uses, summing to some skepticsm on how useful it is in classic SIP flows, more potential for new kinds of services or flows (direct person 2 person with no registrar for example)
Christer: IMS has a use case using a browser to get IMS services using OAuth
Jon: Should look at WebRTC mechanisms for import back to SIP (as alternative to this work)
Jon: also may interact with STIR (use phone number to authenticate)
Chairs: who is interested?
<about 10 hands>
Christer: same situation as CLUE, don't understand the whole thing yet, but there is interest
Using DANE for SIP TLS Sessions (Chairs)
       (draft-johansson-dispatch-dane-sip-01)
Jon: Work needed, but maybe less than proposed.  Need more generic TLS use and then cite that in our work.  So, agree with what chairs proposed.
Wes: Working on DANE, happy to help.  Updates to DANE happening, if you need stuff added, ask now.  Do need protocol specific stuff.  Choices to be made: do you need CA or not?  
Dan: Good use cases in browsers is so-so, but e.g. XMPP uses a lot of DANE.  SMTP is starting to use DANE.
Wes: Actually DANE suggests use CA OR don't, not both

_______________________________________________________________________________________
RAW NOTES BY MICHAEL PROCTOR

SIPCORE - IETF90 21/7/2014, 1300-1500

Clarifications on use of REFER - RjS
------------------------------------
RjS presented his slides.

No objections to two proposed text updates

Christer: Do we need to insist on gruu?
RjS: Covered separately.
ABR: (floor) Be explicit - gruu required if any chance of being addressed out of dialog

Other potential work: update rfc6665 to require gruu 
Christer: Is this a separate document?
RjS: Yes
ABR: (floor) Seperate document or possibly errata,
    although errata may not be read by implementors
AndrewAllen: Thought this was what was meant all along
    - not harmful to clarify
KeithDrage: Lost in weeds - what is updated / already 
    updated / being updated?
RjS: This draft updates 3515 - should have drawn a diagram

RjS: Hearing that people want this, and as a separate document.


Explicit Subscriptons for REFER - RjS
-------------------------------------
RjS presented his slides. Not asking for adoption today.

Proposal: add "nosub" too
AndrewAllen: This basically allows you to do everything in 4488, deprecate it?
RjS: Move to historic in a couple of years if nobody is using it
ABR: (floor) useful if you want to see fate of call (?)

Refer-Events-At uri: nobody had comments

Accepting an Event: refer subs: Is possession of URI sufficient authentication?
AndrewAllen: Is there a reason not to use target-dialog?
RjS: Info about target-dialog not available to subscriber
AndrewAllen: uris are likely to be static - info available
    on subsequent days when reallocated?
Christer: You could add target-dialog header to URI returned
    in Refer-Events-At uri
RjS: That URI needs to be more unique - multiple REFERs could be in progress
Christer: Can subscription be refreshed indefinitely?
RjS: Server can terminate subscription
PaulK: (floor) Why are we talking about gruus?  Yes - it
    is unique and globally routable.  But not really a gruu 
    in the permanent/temp gruu associated with an AoR sense.
RjS: This is an example, not the only way to do it.
AndrewAllen: Suggesting temp-gruus adds complexity.  
    Some temp-gruus may be invalidated / limited.  Might 
    have to re-use if attempting lots of REFERs.
    Unspecified how long a temp-gruu will live.
RjS: Will address this in the text.
JonPeterson: What are the consequences of exploiting this?  Call duration?
RjS: All you see is some of the headers from the responses to an INVITE
JonPeterson: This is what needs to be documented.
RjS: Plea for input concerning what would break if someone subscribes to REFER pkg.
AndrewAllen: Could you unSUBSCRIBE someone else's subscription?
RjS: You would need to know the dialog id too.

KeithDrage: 2nd document - does it update anything?
RjS: No - defines new option tag
Christer: I support this work
JonPeterson: REFER-baiting: Is there some interaction we need to pay attention to?
RjS: Something to think about - Brian!


Using OAuth for SIP - Rifaat
----------------------------
Rifaat presented his slides.

PaulK: How many people are familiar with this?  Comfortable with this?
(laughter)
RjS: I follow the gist of the presentation.
PaulK: Presumably photo server allows multiple auth
    servers, user chose Facebook.  Does 302 indicate
    multiple auth servers?
ABR: That is done before this flow.


JonPeterson: UI element to select "Log in using..." not 
    typically available in SIP.  Can be solved, but moving
    towards a hybrid SIP/Web solution.  401 isn't going to do it.
RjS: He is suggesting that when in SIP space, you need credentials,
    you need to move to the web space, and do it in HTTP.  Bring
    the token back to the SIP space.  Just a strawman.
JonPeterson: Did you mean the REGISTER goes to Facebook?
Rifaat: No
JonPeterson: Pushing the problem around.  Still need the interface
    step where you choose who to use as your IdP.
ABR: (floor) Confusion because we don't know what use-cases are
    driving this.
JonPeterson: What is the goal? Placing a call?
Rifaat: Yes, or access to voicemail server
Rifaat: Need to talk about the use-cases.

Exchange a Code with Access Token
JonPeterson: Why the extra step? (auth code --> access token)
    Why should the proxy manage these tokens? Does this make
    sense in the SIP space? Why do you trust the proxy more
    than the UA?
JonPeterson: Imagine forwarding the access token/refresh token/
    master-key to the UA.  There is a reason not to in the web
    world - does the same logic apply in SIP?
JonPeterson: Unclear that SIP use-cases map to the more complex
    web OAUTH model.
MattRyan: Trying to correlate a SIP REGISTER with an HTTP GET.
    Not necessarily the right mapping.
JonPeterson: It is worse than that.  You register with something
    you have a direct business relationship.  Not the same
    model as oauth.
MattRyan: That's kind of my point.  Which services do I want authorization
    for?
RjS: In the use-cases you are going to write, don't use proxies and
    registrars.  Basic phone-to-phone call.
BrianRosen: There may be lots of services that can use this.
JonPeterson: This would support a radically different world.
PaulK: (floor) First assumption: this draft was to replace digest
    or something like that.  E.g. proxy accepting facebook IDs.

Backup slides: Authenticate & obtain access token
JonPeterson: This flow makes sense to me.  We should address
    the header/body discussion in a wider context than here.

Authenticated Requests
PaulK: I can see this would work, but does it buy us something
    we don't already have?
JonPeterson: It's replacing digest as you said
PaulK: Assuming Facebook wants to support SIP
JonPeterson: Not reciprocal, which would be desirable.
Christer: 3GPP has an interest in this. Browser access to IMS
    doesn't require IMS credentials.
JonPeterson: Going to "meta-up".  Bring back some lessons from
    WebRTC back to SIP, like IdP.
Christer: WebRTC is seen as an access to IMS.  Maybe add 3GPP
    use-cases.
PaulK: This is like the blind people and the elephant.
JonPeterson: Recommend a requirements/use cases phase.  Look
    at STIR, especially if you want it to work with telephone
    numbers.
PaulK: Please contribute on-list.  More input is helpful.
    It takes a village to have an idiot.


SIP DANE - PaulK
----------------
PaulK presented his slides.

JonPeterson: Don't think we need to do nothing.  Dane changes
    mainly to unify handling across multiple usages.  Believe
    that DNSSEC will happen, in a mostly-CA-free environment.
WesH: Co-author of SMTP/DANE and other DANE documents - happy
    to help.  Some DANE fixes in progress.  Why a protocol-specific usage
    is necessary - depends on whether your environment uses CAs.
    DANE can be tied to existing CA infrastructure.  Can also
    be used without CA bindings at all.  Choice to be made for
    each protocol.  DNSSEC is getting more and more deployed.
DanYork: DANE to replace CAs is just one mode to use DANE.
    DANE used extensively with XMPP.  Lots of SMTP is now
    using DANE too.  tram is discussing DANE with TURN servers.
JonPeterson: We are in a position to specify, but not endorse
    DANE modes.  Key sizes need to be considered too.
WesH: Read the DANE ops draft - it says you should not use both
    CA and non-CA modes.
PaulK: It's going to take a group of people to make this happen.
    Will start on the mailing list.