Notes on SIP Sesison 2 at IETF 62
Reported by Miguel Angel Garcia-Martin
Tuesday, 1300-1500
1300 Agenda Bash
1310 SIP Interaction Framework
Jonathan Rosenberg
draft-ietf-sipping-app-interaction-framework-04.txt
Jonathan goes through his slides, highlighting the Target-Dialog draft.
Alan Johnston: the target dialog needs an option tag.
Conclusion: Jonathan to do add it to the draft.
Robert Sparks: this is the way to go forward.
Jonathan: target dialog draft proposes a concrete semantic. It is a key
for authorization decision.
Conclusion: the chairs are to coordinate with the ADs to added the
target dialog draft to the charter.
1350 Management of Outbound Connections
Cullen Jennings
draft-jennings-sipping-outbound-01.txt
Cullen goes through his slides.
On the issue of an option tag to know if registrar supports flow-id an
dif UA supports this.
Rohan: no need for an option tag.
Jonathan: you need it in the Require in the REGISTER.
Rohan: you can check in the response what it came back, and perhaps add
a Contact header field parameter to discover if the functionality is
supported by the registrar.
Alain ???: if the registrar does not support the functionality, you end
up with a wrong binding that you to fix it later.
It seems that none objects to add an option tag, so consensus reveals
that an option tag is the way to move forward.
1405 Using Certificates with SIP
Cullen Jennings
draft-ietf-sipping-certs-01.txt
Cullen goes through the slides.
Robert Sparks: needs further text about caching certs, and checking
certificate revocation.
Rohan: need to refresh the subscription even if the cert is still is
valid, when there hasn't been a NOTIFY for some long period of time.
Francois: this does not deal well with retargetting (and/or forking).
Cullen: not right, the draft assumes that all devices under the same id
have the same credentials.
Francois: the sales group example does not work properly.
Francois: the other case is retargetting. Use case: the helpdesk. You
don't care who is going to answer, but the requirement is the
conversation to be encrypted.
Jon P: RFC 3261 with end to end security solves it.
Cullen: this is a separate problem: to determine who the certificate
belongs to. This is just about acquiring the certs.
Conclusion: There is consensus to change the name to reflect that this
is a credential management service.
Jonathan: what happens if I send a SUBSCRIBE for a GRUU? Do I get the
cert for the AOR?
Cullen: the draft discusses users, not devices.
Jonathan: we need to be very clear on this issue.
Jon: this is the distinction between identities and certs draft.
1420 End-to-middle security
Kumiko Ono
draft-ono-sipping-end2middle-security-04.txt
Kumiko goes through the slides.
Dean: it is expected that this work will end up in SIP fairly soon,
although the draft is issued towards SIPPING.
Open issue #1, signatures inside, encryption outside or the other way
around.
Jon: we did some analysis about this when drafting RFC 3261, but I
think the signature should go inside, the encryption outside.
Cullen: signature inside the encrypting part will give you a better
security properties (from the security group).
Catherine: the crypto community thinks signature inside is better,
although there are sometimes exceptions.
Conclusion: consensus to have signature inside.
Open issue #2, disclosing a body while protecting.
Option 2, use 493 Undecypherable response.
James Polk: CID and Reason header?
Jon: CID is valid is the scope is a partial body of the multipart, but
if you talk about the whole body, you don't need a CID.
Dean: can the proxy request a body?
Jon: if it is undecypherable, how can it point to one body? The proxy
only knows the whole multipart body, not the individual parts.
Jon: better to do it at the high level, the proxy says I need to read
this body, without indicating which one.
Dean, Jonathan: you can also do disclosing based on a
Content-Disposition.
Conclusion: interesting ideas that require further exploration.
Dean: this is a proposal for an implementation of the end-to-middle
requirements.
Conclusion: Hmm reveals that the working group wants to adopt this
document as WG item.
1440 Extension Negotiation
Volker Hilt
draft-hilt-sip-ext-neg-00.txt
Volker goes thorough his slides.
Paul: this aggregates on not being clear of what is the scope of what
an Accept header is. Does it apply to OPTIONS?
Severe discussion about when to include or not the Accept header, in
which methods.
Jonathan: not clear answer, but interoperability is maximised when you
put everything you support in the header.
Jonathan: OPTIONS carries a permanent scope: this is what I support.
Gonzalo: at the end of the day what we want to disclose is the desired
Content-Disposition.
Dean: RFC 3261 scopes the Accept header to the duration of a dialog.
Dean: this is time to have guidelines of Accept headers.
Cullen, Jonathan: it is simpler to populate the Accept header with
everything that is supported.
Dean: RFC 3264 also scopes the Accept header for the duration of the
SUBSCRIBE dialog.
Jonathan clarifies that the use case is when the server can provide
an alternative extension in case the client does not support a
given extension. The example: if the presence server knows that the
client does not support RPID, then the server might put the contents of
activity elements in note elements.
Adam: there is no way for the server to determine that something is not
supported at the client.
There does not seem to be a clear path forward.
Conclusion: we should seriously discuss use cases.
Retargetting draft.
Jon Peterson goes through his slides, highlighting that the same that a
legitimate proxy can modify a body for legitimate purposes, an attacker
can do the same. We have open the door to attackers. The underlying
assumption is that proxies are trusted. But effectively they are only
trusted for certain functions.
Keith: response identity should be connected party.d
Jon: the problem is defined as the ability from the UAC to determine
that the response came from an impersonator.
Rohan: an anticipated responder is sometimes a good thing, sometimes it
isn't.
Cullen: don't agree that an anticipated responder is always a good
thing.
Jon: implementation of connected party is likely to occur security
problems, a UAC doing wrong authorizations.
Jonathan: suggestion to reduce the scope of the requirements to
something that we can solve today. There are other harder problems that
we can't solve today.
Jon: we need to solve the problem that ends up in SRTP, starting from
SIP identity, SIP certs, Mikey, SRTP.
Billy: you can only trust the endpoint, not proxies.
Jon: the basic assumption in SIP is that you trust at least your proxy.
Cullen: because the SIP proxy allocates you with a SIP URI and can take
it out of you at any time, and we have to trust the proxy.
Jon: takes this work as an informational document in SIPPING discussing
the kind of attacks.
Jonathan: need to update the SIPS behaviour in SIP, there are a few
open holes.
Jon: the scope is to detect that there has been a retargetting, not to
prevent that retargetting to happen.
Conclusion: to be further discussed in the mailing list.