Notes, SIPPING Session 2, IETF 60

1300 Open Meeting -- Chairs
Note Well
Agenda Bash
1305 MIB -- Rohan 
draft-ietf-sip-mib-08.txt
Open Issues Summary

On a post by Jean Francois about the open issues, it seems that not
many people read it. 4 people demonstrate interest for the SIP MIB.

4 open issues. Proposal to close 3 of 4.  Issue 1:
configuration. Proposal to not address configuration of the UA since
we have the UA config framework. Configuration will be out of the
scope, although some elements will be able to be read. Consensus on
the proposal

Question: added an application index to all these tables. The problem
is to define application name may end up in the same name repeated. Is
this legal? The problem is that the same application is an instance of
the same application. RFC 2788 seems to say one entry per
application. The MIB spec is restricted in the name. A suffix to the
application name may solve the issue, although this point is not
agreed. Follow up on the list.



1315 The History of History and Voicemail, A Diatribe by Cullen
Jennings draft-jennings-sip-voicemail-uri-02.txt, reading optional for
historical perspective

History of voicemail, Cullen, Mary Barnes
Two solutions for users with voice mail.
1.	History: proxies retarget include information about where and why they retargeted.
2.	Voicemail uri: proxies figure out what services they want voicemail to provide and tell the voicemail the voicemail to do that

Cullen shows the long list of drafts that request this issue.

Cullen goes through the changes in voicemail-uri. See slides.

The possibility of using both: Cullen indicates that both seem to be
needed and not mutually exclusive..

Recommendation: chose something now: History, URI, Both. The
recommendation is to use both, since the do different things and they
work together.

Rohan, as chair: We are already doing History. So the question is: we
do History alone or we do History AND URI.

Cullen: agree. The option is whether we do this or not.
Mary: Request-History has several usages, not only voicemail URI.

Dean: anyone implementing voicemail URI? No answers. Suggestion: to
take voicemail URI as individual submission heading informational RFC.

1330 Request History -- Mary Barnes
draft-ietf-sip-history-info-03.txt

Mary goes through the changes from -02 (see slides)

Keith: the ABNF should be normative and should not duplicate the
normative in the text.
Rohan: the IESG use to like to explain how things work.  
Keith: the document should say: you MUST implement the ABNF.
Gonzalo: you are putting normative statements in two places of the
document, the may contradict at some point.
Mary: agree to remove all capitals from section 4.1 
Dean: explanations are good, the requirements level is not.

Consensus to remove the requirements level from section 4.1

Mary continues to go through the slides, describing th eissues
discussed since -03 was issued (see slides).

Mary request more reviewers. The document is ready for WGLC

Mary presents an analysis of History-Info vs robust security:
comparison with draft-ietf-sip-identity-02 and
draft-ietf-mahy-sipping-add-body (see slides).

Mary also presents an analysis of History-Info versus Privacy.

Jon: People are much confortable with the request portion than with
the response portion in the request identity draft. Suggest to split
the request-identity in two drafts. Considering to work on two options
for request-history as well, since they are incompatible.
Rohan: transition mechanism that the P-Asserted-Identity to the
general internet.  Jon: the request identity draft just says that a
proxy cannot add a body.
Keith: we need to solve the ientity stuff before the history, not the
other way round.
Rohan: is is sufficient to say in history-info that a proxy that
retargets to a non-local then it should redirect. This will
work. Other mechanisms may be specified later.
Rohan: if a proxy want to convey history-info securily, then you can
redirect to TLS.

Rohan to send text.

1410 Connected party, who am I talking to
draft-jennings-sipping-connected-00.txt

Problem description in the slides.  Possible solutions: 1) update of
state in the dialog; 2) transfer to a new user. 1) has two
subsolutions:

1a) Update To or From, although is not compatible to 2543.

Jonathan: I hope people are not using To and From as the primary
source of information for the user.
Cullen: already used by other drafts (identity).  1b) update with a
new header, body, AIB, etc. Compatible with 2543, but a 2543 phone
will not update its display.
Rohan: solution 1a and 2543. A 2543 implementation will return 481. To
and From are useless today.
Andrew: don't depend on To and From headers, the UA will not use them.
Jon: email contains From and To headers, and they are useful and
intuitive. They can be forged, and that's why we need identity, and
this is approach taken by identity, making them meaningful. it
requires a lot of motivation to make the to/from header less
meaningful.
Jyri: In forwarding scenarios accros different domains, there is not
traces of the original sender.
Keith: the problem is reusing a header for different usage. This is
the problem why we end up with so many identities.
Rohan: the semantics of from/to: To is a semantics of to which you
address the dialog. Cullen suggests the semantics of to who you are
communicating. The identity work addresses part of this correlation.
Rohan: if we go with 1a and do not change the To header, someone has
to change a bunch of stuff in Section 26 of 3261 to indicate how to do
things now with S/MIME.  Hisham: ok to change To/From, if you
authenticate the user you don't authenticate the To/From. If I want to
change my name, I can re-INVITE to change my From.  Cullen: sort of
agree with Hisham. right now we don't have a mechanism to change the
name.

Solution 2 is about INVITE/Replaces, not about REFER.

Jonathan: this does not work with bill. The billing system charges the
user on INVITE and BYE. This is wrong. The billing system should take
information about "what happens" during the call, and figure out that
information when the call started/ stopped.

Jonathan: don't understand the serious security issues (see slide, solution 2). 
Rohan: replaces has requirements for authorization of the replacement,
and the way to do it is to look at the Referred-By header and
correlated.
Jonathan: a solution: GRUU + cryptographicly random grids
Rohan: post on the list the proposal.
Dean: consensus to look at the cryptographic technics of the GRUU and
the dialog usage.

Poll of the room about the possible solutions: support for Replaces
with GRUU and cryptographic randoms (solution 2). If that does not
work, then try a new header (solution 1b).



1400 SIP State Update -- John Elwell
 draft-elwell-sip-state-update-02.txt

John goes through the slides. 

The proposal to treat the clarifications to existing RFC ad bug fixes
and add similar clarifications to authid-body and future drafts is
accepted.

Jean Francois: How does this related to the previous presentation. Do
we need to put this on hold until we resolve the previous proposal.

Dean: bring the list of bugs, one at a time, to the mailing list, so
we can get attention and work through.


1420 Making S/MIME Work With Certs - -Cullen Jennings
draft-jennings-sipping-certs-04.txt

Cullen goes through the slides.

Slide: The Sacred Choice
Jonathan: great. This is the only deployable solution of S/MIME with SIP.

Fetching credentials: options to use notification or config framework.
Jonathan: config framework.

Fetching certificates: the trick to make this deployable is to have
one certificate per domain instead of a certificate per user?

Jonathan: tying the lifetime of the certificate with the lifetime of
the subscription solves a bunch of problems.
Rohan: want to use HTTPS to fetch a certificate to avoid a bunch of
SIP messages.
Jonathan: we can do this with zero call setup delay. buddylist
provides a context to get certificate from my buddy. You can add a
flag to a presence document "hasCert".
Cullen: agree.
Rohan: if I received a signed message from someone I don't have a
certificate, then HTTPS is better. From deployment perspective it's
easier.
Jonathan: this is easier to deploy with SIP. In which way the HTTP
solution is superior to the SIP solution?
Scott: maintaining a large number of subscriptions is server side
state. The HTTP solution has not server side state.  Clarified that we
already have the subscriptions for the buddy list.
Scott: the subscription solution offers immediate notification of
certificate revocation.
Cullen: the short timer in certificates cannot be used, since it is
expensive to generate certificates.
Jonathan: fetching the cert does not require TLS.
Jonathan: I don't object to the HTTP solution, but how do compute the
HTTP URI?  
Cullen: there is a draft that solves the problem.
Rohan: SRV already solves the problem
Cullen: proposal to continue the discussion on the list.
Jonathan Lennox: ...
Jonathan (Rosenberg): we are debating which one is mandatory to
implement.

Dean: we have a lot of dependencies on making S/MIME to work. There is
strong consensus to make this work. Proposal to make this a WG
item. Poll to the room indicates strong consensus to adopt this as WG
item. It will be work out with the Ads.


1440 How offer/answer interacts with multipart/alternative in SIP --
Cullen Jennings Discussion

Cullen: presents the slides. The problem of first trying a secure call
and then the insecure, is that the secure call is prioritized (e.g, if
the voicemail implements secure, S/MIME, SRTP, the voicemail will
always answer).

Solution: Content-ID in each multipart entity in the offer and a
Content-Reference in the answer.

Allison: this cannot be decided here, but the MIME WG?
Cullen: do we need a Require header. Proposal: yes
Jonathan: weak feeling. If I do SRTP I need to encrypt the SDP. Better
to start with the problem statement. The problem: I cannot use SRTP
because it is a backward compatibility problem.
Cullen: the solution to the bid down attack is the auth body and
encrypt everything.
Jonathan: there is two problem statements. Another problem is due to
the consequences of sending secured multipart, the nonencrypting UA
will reject.
Dean: problem 1) how to find out if the other party can do SRTP or
not. Solution: multipart. Alternative: send an offer encrypted, if
rejected, send offer unencrypted, but what happens with forking.
Jean Francois: the number of alternatives is big (encrypted voice,
non-encrypted audio type of things). This may increase complexity and
size of the multipart.
Dave: Should it be possible to accept the session but reject the
offer. Get a 200 OK, but sending something that "I want to establish
the session, but there is something in the SDP that I don't
understand".
Hisham: yes, you can reject everyhig in the answer
Hisham: Can you offer both RTP and SRTP as options?
Cullen: the problem is tha tif you do SRTP you need to encrypt.
Aki: about the tag, inspire in the security agreement.
Jonathan: may need to look at preconditions as a solution.
Rohan: backwards compatibility is an issue, so preconditions does not
help.

Discussion is deferred to the list



Using SAML for SIP -- Hannes Tschofenig
draft-tschofenig-sip-saml-00.txt 

Hannes goes through the slides. No comments.