SIPCORE Minutes, IETF89, March 2014 ============================= Conclusions & Action Items ============================ * Errata on 3325: Conclusion: No objection to interpretation given by chairs. Action: Agree to clarify that it is allowed, but not required, to interpret these characters when not enclosed in <>. * draft-johansson-dispatch-dane-sip: Conclusion: Few present understood the issue. Many were confused. Action: Olle to send use cases to the list. * draft-yusef-sipcore-digest-scheme: Conclusion: Don't fix Digest, fix Authentication Action: Those who think fixing digest is insufficient should send use cases to the sipcore mailing list. * draft-johansson-sip-dual-stack Action: split the action item into two: one for the DNS part, and another for the remainder of Happy Eyeballs. Discuss the milestone text on the list. Action: call for adoption of draft-johansson-dispatch-dane-sip on the list for the DNS part. * RFC 6665 Dialog Re-Use with REFER Conclusion: Much objection to need for GRUU to solve this problem. Action: Robert Sparks and Adam Roach to write a new draft updating RFC3515 (REFER) for consistency with RFC6665. Action: Continue discussion on list. (Especially those who object to described approach.) ================================ Monday, Ben Campbell ================================ SIPCORE minutes 02/03/2014 Agenda Status, and Summary -- Chairs present NOTE WELL Note takers: Ben, Nathan Jabber scribe: Cullen Chairs present Gonzalo with an Oolong Tea Chairs present document and milestone status slides. All old milestones are done. Expect milestone for happy-eyeballs (discussion on Thursday.) SIP TLS Authentication using DANE http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip Errata on 3325-- syntax problems with p-Asserted-Identity and p-Preferred-Identity. Paul proposed requiring brackets, called for objections: Keith Drage: What happens when you receive something you can interpret but is not legal. Adam: Proposed we allow, but do not require, parsing without the brackets. No further objection. -- SIP DANE recently dispatched to SIPCORE, so SIPCORE appropriated an hour of DISPATCH time. Olle Johansson presents slides. -- Question under discussion is whether sipcore wants to adopt this effort. SIP TLS cert rules do not allow using CN if SAN is present. Trusting DANE assumes trust in DNSSEC. Places certificate in signed, trusted DNS zone. Can publish constraints , root of private CA, certificates, public keys with fingerprints. connection involves asking for TLSA RR, then authn TLS peer. Can also authorize if server can server a particular domain. SIP Domain certs connect URI domain part with a cert. SNI only allows asking for host name. Need to handle URIs. TLSA allows delegation from domain to a host possibly not in that domain. Separates authorization from authentication. Full 3263 DNS query chain needs to be DNSSEC protected. Assertion that SNI is not possible Cullen: Why? Olle: SNI only allows us to query for host name. Cullen: Just a string. Host and domain name don't many anything different in this context. Wes Hardeker: Agrees with Cullen. Author of dane document that explains what names to use; this work should learn from that. Can use CNAMEs to point to other TLSA records, etc. DANE OPS draft, etc. Olle: Great! will follow latest updates. Wes: DANE bis needed to fix some normative language. Olle: Can follow existing work, need to spec how to use SIP URIS Jon Peterson: (Looks at reading materials slide): How much is SIP specific, and needs to be in a SIP draft? Olle: DANE drafts say applications should spec their own uses JonP: What use cases? Just TLS? Identity being re-spun in stir. Have looked at dane in stir. Olle: Not many tested peers use 5922 Cullen: Most commercial deployments use 5922. JonP: What do we need to do beyond 6988 Wes: Yes. dane ops doc etc does not cover following srv, mx, cname, etc. Can't just use vanilla 6988. May be stuff to still. JonP: How many people have deployments using SRV (a few.) JonP: If dane requires application specific specs, he can understand. What else do we need? Olle: The "what else" needs to be discussed. Wes: Need pointers to other docs. JonP: Why does dane srv doc require application specific specs? Wes: Historical reasons. Doc is intertwined with HTTP. Dane-bis may strip out the HTTP stuff (http bis should handle that.) Other protocols (e.g. smtp, sip) have extra redirection. Need to specify redirections, trust, naming, etc. Every application is special, can't solve the problem for all applications for now and future. Cullen: Need srv and naptr doc to be done, SIP says we do what srv and naptr say. Olle: One of the dane docs says having domains for certs not a good idea, dane certs should use host names. Cullen: Host and domain names are not distinct. Olle: doc says we need host name attribute in certificate. We may need to feed issues back to dane. -- not worrying about sip identity, simple, or sips URIs. Keith Drage: What about pres: and im: URIs? JonP: Not technically defined by simple. Cullen: sips pretty much deprecated, identity in stir Chairs: Where do we go from here? RB: (as individual) SIP should be able to use dane. Not convinced we need SIP specific drafts. Need a concise statement of what new bits are compared to dane-srv, pull out commonalities, etc. Not keen on adopting without understanding those bits in more detail. RB: We need a technical reason, not just an assertion from dane-srv that we need a sip rfc. Wes: Need something that says how SIP should do it, even if it's a two page rfc that points back to dane-srv. dane does not standardize across application protocols. RB: Applications sometimes need to specify how to use TLS, sometimes they can use it as it. Does SIP need additional considerations? Wes: Probably not, just a pointer back to say use dane. JonP: If TLS uses dane, why does SIP need to specify stuff? Wes: No TLS binding saying tls _must_ us dane. Dane is a way, but not a must. Cullen: Not going to say sip MUST do dane. What's different between saying SIP can use dane and saying TLS can use dane. Wes: dane spec doesn't say you can use dane for a specific port/application/protocol. No one will use it without a draft that says use this specific prot, etc. Olle: Need to clarify use of SAN vs CN, etc. Might be informational. Cullen: Probably need a doc that says something (e.g. what happens when dane fails). But we should not have to explain how to use naptr/dns JonP: dane-srv suggests documenting how to work with devices that don't support srv (not a problem for SIP), fallback logic if dnssec failure. Wes: Fallback from bogus response in dane-srv needs to spec when you MUST be authenticated, encrypted, can fall back to opportunistic crypto, when you can send in clear. Spelled out for SMTP, probably different for SIP. Cullen: That makes sense Chairs: Need to ask some questions: -- How many people think they understand the situation? (not many) -- How many are confused: (several to lots) RB: (as AD). We probably need to do some things, but not sure what those things are. Can we agree on milestone, if not document? JonP:Wants to understand it better before agreeing to a milestone. Paul: Need to do something, not sure if that will result in a milestone. Keith: Doesn't understand the scope. Might need milestone for "investigate". Robert: Thinks there is interest in mapping out what needs to happen and where so implementors can use dane. This is a good venue to start that conversation. Paul: Do we agree that SIP should be able to use DANE: JonP: Yes, but not sure if we need to do anything in SIP to make that happen. Paul: Profound confusion on what we need to do to allow SIP to use DANE. Wes: If implementors will just tell TLS stack to use DANE, SIP doesnt need to doc anything. Not convinced that will happen based on current documentation. May only need to tell implementors how to bind things together. Paul: Next Steps? Robert: Focus on specific examples/use cases Chair to Olle: Can you send specific use cases to list? [agreed] Cullen: Need to look at use cases, see what needs to be specified and where. [conclusion] Back up to use cases, look at gaps. Chairs thank Olle for taking the first (and subsequent) steps. ================================ Monday, Nathan Egge ================================ SIPCORE meeting minutes: 2014/3/3 4:30pm GMT - Oolong tea to Gonzales for 4 years service. Since IETF 84 published 4 RFCs - decision to drop drafts-ietf-sipcore-proxy-feature-reqs-03 Errata: RFC 3325 (P-Preferred-Id, P-Asserted-Id) - Only need to worry about "," - Question is do we follow 20.10 rule for all three (, ; ?) - Keith "How do you handle received URLs that do not conform?" - Adam Roach "You can interpret these if you want to [without 20.10 rules], but we will not require it." Olle E Johansson - Do we want to add DANE to SIPCORE charter? - Protocols that have active WGs need to discuss DANE in their own WG. - To trust DANE you need to trust DNS-SEC - TLS client needs a chain of certificates, with DANE we can simplify - add cert to DNS zone - flexibility in certificate management - fingerprint - key material - etc. Cullen Jenings: why is SNI not possible? Answer: SNI asks for hostnames and not domains with SIP domain certificates, we validate against a SAN or CN if we want to find a certificate with SNI, we are only allowed to query for hostname Cullen: no distinction between hostname and domain name Agreed. Wes: suggest you read the DANE specification, this case is covered. DANE ops draft has recommendations Johnathan: How much of this is SIPs problem, and how much is restating what is in TLS for DANE document? Answer: need to consider backwards compatibility Johnathan: Cullen: Most major deployments use 5922 Johnathan: Is there something beyond 6698 we need to do to make DANE work for SIP? Wes: Yes, one thing that is not covered is following SRBs, following MXs and CNAMEs. But there is other documentation for this. Main question is whether or not this working group needs to do something? Not everything is specified in DANE document? Wes: Is all that needs to be done is include a pointer? Answer: I would also like to see some implementation guidelines. Wes: Why does the SRB document require separate documentation? - A lot of it comes from history, the original 6698 is a blend of concept of DANE (pointer to certificate) combined with the HTTP layer. - In reality, people pushing on DANE-BIZ to strip out the HTTP stuff. Should be done in HTTP-BIZ. Cullen: We need SRB and NAPTR document and nothing beyond that. I would be surprised if we need more. Both the DANE document and the SRB one says each application MUST write a document that says you need to use DANE and how. Applications that use TLS sometimes need to write a document how they write TLS. The question is "Is DANE usable as it is or do we need to write additional documentation" Cullen: We are not going to say SIP must use DNS or even SIP can use DANE. We are going to say TLS can use DANE. How many people feel they now understand the situation? (1 or 2 hands) How many people are confused? (few hands) AD: Do we want to have a milestone? - no It may very well be that what needs to be done is write to the people doing the DANE SRB stack and ask them to do something. Keith: we may need to have a milestone that says "investigate" Robert Sparks: There is interest in mapping out what needs to happen and where it needs to happen. This is a good venue for this. Do we have agreement that SIP aught to be able to use DANE? Adam Roach: Put some specific examples of use cases for SIP with DANE on the list. Solicit feedback. Cullen: We can try and look at what are the things that are not currently specified and where should they be specified? - nothing stoping us from doing work ================================ Thursday, Nathan Egge ================================ * Rifaat Shekh-Yusef SIP Digest Authentication draft-yusef-sipcore-digest-scheme Discussion about preference field in registry Getting priorities right for the authentication algorithms is tough, so putting the prio into the registry could help. Other opinions expressed that this should rather be discussed in the corresponding spec. No conclusion Forking of authentication & QoP Backwards compatibility Suggesting to not consider both further, since it is not used. Why not design a new “scheme” with better properties? E.g. allowing for SSO. Could use new header fields and in future deprecate currently used Auth* header fields. What are the use cases. Having those would allow to design the new schema to match what is needed. Why offer multiple algorithmns? It is prone to downgrade attacks. 3GPP 24229 proposes multiple authentication alternatives, that might include a useful option. Author should check for these. Discussion summary: ”Don’t fix Digest, fix Authentication” Design (or select from something existing) a new authentication scheme and establish a plan how to migrate from digest to the new one. But be warned of what happened in HTTPAuth. WG adoption premature Next step: Describe use cases * Olle E. Johansson Happy Eyeballs for SIP draft-johansson-sip-dual-stack Proposal to address two issues: • Clarify and provide BCP guidance for DNS look-up procedures in dual stack networks to adhere to Happy-Eyeballs algorithm • Document usage of DNS SRV records to indicate server preference of address family Lots of side discussion on how to make sending over UDP work. General advice: Registration should use similar techniques as in outbound. The hard part is client/server interface, server-to-server interface should be addressable easily from there. Proposal: Try to make a successful registration. Once that worked sending the INVITE afterwards should work as well. Problem with media: ICE still not used by SSPs. SIPIT ICE support is in 75-80%, but unclear about testing of ICE for dual-stack. On draft adoption: Not enough people read the latest version to decide upon adoption. Thus a call for adoption will be done on list With respect to the corresponding milestone, it was proposed that it could be split up into a DNS part and a Happy Eyeballs part. Text for such a split needs to be proposed and discussed on list. * Adam Roach RFC 6665 Dialog Re-Use with REFER (Time Permitting) http://www.ietf.org/mail-archive/web/sipcore/current/msg05787.html What action required? One option proposed was producing a 3515bis that clarifies what to do when Refer is used together with 6665. It could also include norefersub handling, change to using an explicit subscription. That could easily take several meeting cycles. 3GPP uses a feature tag that indicates support _and_ usage of norefersub, i.e. in a certain profile. Robert Sparks & Adam Roach volunteered to write a draft updating 3515/6665/norefersub/... That document should address the specific problem until IETF90. After evaluation the decision will be made if a 3515bis would be needed as well.