IETF Real Time Protocol Security ()

Cullen Jennings | 11 May 2007 19:42

Plan for moving forward


Hi All,

I have talked to the RAI and SEC ADs and here is the rough plan for  
how I would like to move forward with this. I would like to split the  
work off into the following working groups.

TLS
Make any modifications that may be required to DTLS to allow DTLS to  
generate the keys for SRTP.

AVT
Describe how DTLS is used to key SRTP and how SRTP is used in  
combination with DTLS. This includes the issues of multiplexing DTLS  
and SRTP on one port. draft-mcgrew-tls-srtp will be the starting  
draft for this.

MMUSIC
Provide a scheme for transporting DTLS fingerprints in SDP offer/ 
answer (suspect this is already done but it not, MMUSIC does it).   
Provide a scheme that allow an offer to say it is willing to do SRTP  
or RTP but would prefer SRTP.  The ongoing draft-ietf-mmusic-sdp- 
media-capabilities work should meet this need.

RAI/SEC
Write overview document on how SIP UA can secure media using  
combination of DTLS/SRTP, SDP Fingerprint, Identity, Outbound, and  
Digest and TLS for SIP. This document will not describe new  
mechanisms, it just provides the roadmap of how they all fit  
together. Jon Peterson has the token to start this.

(Continue reading)

headers

Lakshminath Dondeti | 2 Jun 2007 08:29

Re: Plan for moving forward

On 5/11/2007 10:42 AM, Cullen Jennings wrote:
> 
> Hi All,
> 
> I have talked to the RAI and SEC ADs and here is the rough plan for how 
> I would like to move forward with this. I would like to split the work 
> off into the following working groups.
> 
> TLS
> Make any modifications that may be required to DTLS to allow DTLS to 
> generate the keys for SRTP.

I haven't followed the TLS working group closely over the years, but I 
don't recall DTLS being a TLS WG product.  In any event, DTLS is not 
part of the TLS charter.  Are we talking about rechartering that group 
to include this item?  When will that happen?  For the record, this work 
is not high priority on my list, but I am curious about the timeline.  I 
would like to be not surprised by a suddenly hurried up process (e.g., 
the "decision making" at the Prague meeting).

One of the things I would like to see done is to make the protocol truly 
peer-to-peer, or put another way, either side can initiate and more 
importantly allow requesting the other side to authenticate first.  One 
of the applications I recently came across has the Caller having the 
Callee authenticate first and within the resulting secure channel use a 
legacy method to authenticate itself.

> 
> AVT

(Continue reading)

headers

Sam Hartman | 4 Jun 2007 16:06

Re: Plan for moving forward

>>>>> "Lakshminath" == Lakshminath Dondeti <ldondeti <at> qualcomm.com> writes:

    >>  AVT Describe how DTLS is used to key SRTP and how SRTP is used
    >> in combination with DTLS. This includes the issues of
    >> multiplexing DTLS and SRTP on one port. draft-mcgrew-tls-srtp
    >> will be the starting draft for this.

    Lakshminath> My take is that draft-mcgrew-tls-srtp specifies a
    Lakshminath> DTLS extension for SRTP and thus belongs in a
    Lakshminath> security area WG, and not in AVT.  Of course, this
    Lakshminath> kind of thing is up to the AD.  But I wonder if you
    Lakshminath> are willing to share your thought process in arriving
    Lakshminath> at this conclusion. Specifically, why do you think
    Lakshminath> that the AVT WG is a better place to get the
    Lakshminath> necessary reviews for this work?

First, I consider avt a security WG in that they own srtp and thus
need to have as much security clue as most security wgs.  They are
housed in the RAI area, but 1) I consider the RAI ADs fairly good at
security and 2) I consider all the ADs to be good at knowing when they
need more review.

And because I think AVT already has security stuff on its charter and
already has SRTP responsibility, it seemed like a good fit.

Like the other ADs involved in this discussion I firmly believe that
both security, RTP, SIP and AVT review is required.

(Continue reading)

headers

Cullen Jennings | 2 Jun 2007 17:26

Re: Plan for moving forward


On Jun 1, 2007, at 11:29 PM, Lakshminath Dondeti wrote:

> On 5/11/2007 10:42 AM, Cullen Jennings wrote:
>> Hi All,
>> I have talked to the RAI and SEC ADs and here is the rough plan  
>> for how I would like to move forward with this. I would like to  
>> split the work off into the following working groups.
>> TLS
>> Make any modifications that may be required to DTLS to allow DTLS  
>> to generate the keys for SRTP.
>
> I haven't followed the TLS working group closely over the years,  
> but I don't recall DTLS being a TLS WG product.  In any event, DTLS  
> is not part of the TLS charter.  Are we talking about rechartering  
> that group to include this item?  When will that happen?  For the  
> record, this work is not high priority on my list, but I am curious  
> about the timeline.  I would like to be not surprised by a suddenly  
> hurried up process (e.g., the "decision making" at the Prague  
> meeting).

It is not clear any changes are needed but it is possible that the  
RTPSEC solution might end up using the TLS extractor work.  Once the  
specific changes are clear we can decide if it would need a milestone  
update, charter update, or nothing in TLS. It is clear that the TLS  
WG is the place that has the best affinity with the security  
expertise to review this work.

(I have no idea what you mean about surprised by hurried up process  
as what happened in Prague was actually more or less a meeting late

(Continue reading)

headers

Lakshminath Dondeti | 3 Jun 2007 00:44

Re: Plan for moving forward


On 6/2/2007 8:26 AM, Cullen Jennings wrote:
> 
> On Jun 1, 2007, at 11:29 PM, Lakshminath Dondeti wrote:
> 
>> On 5/11/2007 10:42 AM, Cullen Jennings wrote:
>>> Hi All,
<snip>
>>
>> One of the things I would like to see done is to make the protocol 
>> truly peer-to-peer, or put another way, either side can initiate and 
>> more importantly allow requesting the other side to authenticate 
>> first.  One of the applications I recently came across has the Caller 
>> having the Callee authenticate first and within the resulting secure 
>> channel use a legacy method to authenticate itself.
> 
> Well, before the Montreal BOF would have been the place and time to 
> bring up that requirement. 

Are you suggesting that we have added no requirements to the mix after 
the Montreal BoF?  Aren't we still tweaking them?  Did I miss the last 
call for requirements?  This is another surprise to me btw and I am 
following the list and attending all the meetings.

> Luckily, I think you are pretty safe in that 
> this requirement is supported by the solution we are on. SIP allows an 
> INVITE to have and offer and also allows INVITES without an offer where 
> the UAS sends the offer. I think this will meet your requirement.

The problem is simply that we are going ahead with a strict

(Continue reading)

headers

Eric Rescorla | 3 Jun 2007 01:40

Re: Plan for moving forward


At Sat, 02 Jun 2007 15:44:54 -0700,
Lakshminath Dondeti wrote:
> > Luckily, I think you are pretty safe in that 
> > this requirement is supported by the solution we are on. SIP allows an 
> > INVITE to have and offer and also allows INVITES without an offer where 
> > the UAS sends the offer. I think this will meet your requirement.
> 
> The problem is simply that we are going ahead with a strict 
> client-server imposition on the parties to the communication.  For 
> general purpose use, we need to start thinking a little bit broader (see 
> the example of IKEv2).  I made a note of this issue at the meeting in 
> Prague and perhaps earlier too.

I'm sorry, I still don't understand what you think the impact
of "strict client-server imposition" is here. I agree that TLS/DTLS
has a client and server, but so what? What relevant use case does
that preclude?

-Ekr

headers

Lakshminath Dondeti | 3 Jun 2007 03:37

Re: Plan for moving forward

On 6/2/2007 4:40 PM, Eric Rescorla wrote:
> At Sat, 02 Jun 2007 15:44:54 -0700,
> Lakshminath Dondeti wrote:
> 
> I'm sorry, I still don't understand what you think the impact
> of "strict client-server imposition" is here. I agree that TLS/DTLS
> has a client and server, but so what? What relevant use case does
> that preclude?
> 
> -Ekr
> 
Eric,

That's a self-fulfilling argument.  Any use case one might present, it 
appears, will be declared irrelevant and so I am not going to waste any 
more time on this.  You design, the rest of us it seems have no other 
option but to figure out how to work within those arbitrary constraints 
or just design our own solutions and standardize through other means.

best wishes,
Lakshminath

headers

Lakshminath Dondeti | 3 Jun 2007 00:44

Re: Plan for moving forward

The problem is with "decision making" at a meeting.  Generally speaking, 
I would say that is not allowed.  Seriously, if I think back, all of 
this was based on some hums taken after the meeting was over and we were 
into the break time in Prague.  I am surprised that none of the ADs are 
bothered by that kind of thing (i.e., declaring "consensus" on a 
solution after taking hums at a meeting).  Perhaps I am all wrong about 
this, but all the people I have talked to in private so far, said otherwise.

I don't expect or want the "decision" changed, but the process exists 
for good reasons.

On 6/2/2007 8:26 AM, Cullen Jennings wrote:
> 
> On Jun 1, 2007, at 11:29 PM, Lakshminath Dondeti wrote:
> 
>> On 5/11/2007 10:42 AM, Cullen Jennings wrote:
> 
> (I have no idea what you mean about surprised by hurried up process as 
> what happened in Prague was actually more or less a meeting late from 
> what we agreed to do in Montreal but never mind that. )
> 

Why was it a meeting late in the first place and why the hurry to make 
decisions at a meeting and without verifying the consensus on the list? 
  An outsider never knows when things are going to be in a slumber or 
when things will progress at a break neck speed.

Lakshminath

(Continue reading)

headers

Sam Hartman | 4 Jun 2007 16:00

Re: Clarity of consensus


>>>>> "Lakshminath" == Lakshminath Dondeti <ldondeti <at> qualcomm.com> writes:

    Lakshminath> The problem is with "decision making" at a meeting.
    Lakshminath> Generally speaking, I would say that is not allowed.
    Lakshminath> Seriously, if I think back, all of this was based on
    Lakshminath> some hums taken after the meeting was over and we
    Lakshminath> were into the break time in Prague.  I am surprised
    Lakshminath> that none of the ADs are bothered by that kind of
    Lakshminath> thing (i.e., declaring "consensus" on a solution
    Lakshminath> after taking hums at a meeting).  Perhaps I am all
    Lakshminath> wrong about this, but all the people I have talked to
    Lakshminath> in private so far, said otherwise.

After the meeting I told Cullen that I believed the consensus in the
room was sufficiently rough that it needed more time on the list.
It's my recollection that he agreed that a way forward was to propose
a direction as a consensus on the list and see if it stuck.  That's
clearly allowed.  Naturally such a proposal would need to have some
sort of call for comments etc.

Sam Hartman
Security Area Director

headers

Lakshminath Dondeti | 4 Jun 2007 17:18

Re: Clarity of consensus


Thanks Sam.  Perhaps Cullen's email should be reworded inviting people 
who were not present at the meeting in Prague to share their opinions. 
As I noted in one of my other emails, we would have then given everyone 
a fair chance to express their opinions on the matter and we can go from 
there.  It's really that simple.

regards,
Lakshminath

On 6/4/2007 7:00 AM, Sam Hartman wrote:
>>>>>> "Lakshminath" == Lakshminath Dondeti <ldondeti <at> qualcomm.com> writes:
> 
>     Lakshminath> The problem is with "decision making" at a meeting.
>     Lakshminath> Generally speaking, I would say that is not allowed.
>     Lakshminath> Seriously, if I think back, all of this was based on
>     Lakshminath> some hums taken after the meeting was over and we
>     Lakshminath> were into the break time in Prague.  I am surprised
>     Lakshminath> that none of the ADs are bothered by that kind of
>     Lakshminath> thing (i.e., declaring "consensus" on a solution
>     Lakshminath> after taking hums at a meeting).  Perhaps I am all
>     Lakshminath> wrong about this, but all the people I have talked to
>     Lakshminath> in private so far, said otherwise.
> 
> After the meeting I told Cullen that I believed the consensus in the
> room was sufficiently rough that it needed more time on the list.
> It's my recollection that he agreed that a way forward was to propose
> a direction as a consensus on the list and see if it stuck.  That's
> clearly allowed.  Naturally such a proposal would need to have some
> sort of call for comments etc.

(Continue reading)

headers

Peterson, Jon | 5 Jun 2007 02:07

RE: Clarity of consensus


I didn't really read Cullen's original mail describing the plan as a "so mote it be" proclamation. It's what
seemed like an appropriate direction given the emerging consensus we perceive. While I do concede that it
didn't explicitly invite comments, it certainly didn't present itself as a done deal (it characterized
itself as a "rough" plan, how he "would like" things to go forward, etc). After the mail was sent, it stood
without comment for almost a month - as such, I'm not sure that people have been deprived of a fair chance to
express their opinions and so on.

That much said, obviously people should feel welcome to comment on this plan and the overall direction, as
you have. 

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com]
> Sent: Monday, June 04, 2007 8:19 AM
> To: Sam Hartman
> Cc: Cullen Jennings; ietf-rtpsec <at> imc.org; Tim Polk; Peterson, Jon
> Subject: Re: Clarity of consensus
> 
> 
> Thanks Sam.  Perhaps Cullen's email should be reworded 
> inviting people 
> who were not present at the meeting in Prague to share their 
> opinions. 
> As I noted in one of my other emails, we would have then 
> given everyone 
> a fair chance to express their opinions on the matter and we 
> can go from

(Continue reading)

headers

Lakshminath Dondeti | 7 Jun 2007 08:08

Re: Clarity of consensus

When confirming consensus, chairs in a different working group did the 
following:

http://www1.ietf.org/mail-archive/web/netlmm/current/msg01168.html

(I picked that example because it pertains another contentious 
discussion and one that I recall of the top of my head).

To summarize, questions asked in the meeting were reiterated on the list 
and people who did not get to participate in the discussion were 
explicitly asked for their opinions.

With that context, let me ask a question.  Did I miss an ION or 
something where the IESG decided that the approach used in this case is 
indeed the right way to determine consensus?  If so, perhaps we should 
advertise it to the entire IETF.  Why waste time by repeating questions 
on the list and all of that?

If that is not the case, let us follow the example above and set things 
right.  Perhaps no one will respond to that call, so be it.  At least 
the procedures we follow in the IETF would be consistent and as 
documented, not ad hoc.

thanks and regards,
Lakshminath

On 6/4/2007 5:07 PM, Peterson, Jon wrote:
> 
> I didn't really read Cullen's original mail describing the plan as a

(Continue reading)

headers

Sam Hartman | 5 Jun 2007 04:40

Re: Clarity of consensus


Jon, just to be clear, I was not stating a position on whether I
thought what Cullen had done was consistent with how I thought we were
going forward.  I was also not requesting that a decision be
reconsidered nor raising any objection.

headers

Dan Wing | 2 Jun 2007 18:57

RE: Plan for moving forward


> > One of the applications I recently 
> > came across  
> > has the Caller having the Callee authenticate first and within the  
> > resulting secure channel use a legacy method to authenticate itself.
> 
> Well, before the Montreal BOF would have been the place and time to  
> bring up that requirement. Luckily, I think you are pretty safe in  
> that this requirement is supported by the solution we are on. SIP  
> allows an INVITE to have and offer and also allows INVITES 
> without an  
> offer where the UAS sends the offer. I think this will meet your  
> requirement.

I don't think flipping who sends the offer is sufficient -- DTLS-SRTP,
as the several documents are now, uses a=fingerprint to authenticate
both endpoints.  What Lakshminath is looking for is a way for one side
to declare that they don't want their certificate used as the 
authentication mechanism, but rather wants something else used (a
password or something; 'legacy method' encompasses a lot of stuff).

-d

headers

Eric Rescorla | 2 Jun 2007 19:18

Re: Plan for moving forward


At Sat, 2 Jun 2007 09:57:28 -0700,
Dan Wing wrote:
> 
> 
> > > One of the applications I recently 
> > > came across  
> > > has the Caller having the Callee authenticate first and within the  
> > > resulting secure channel use a legacy method to authenticate itself.
> > 
> > Well, before the Montreal BOF would have been the place and time to  
> > bring up that requirement. Luckily, I think you are pretty safe in  
> > that this requirement is supported by the solution we are on. SIP  
> > allows an INVITE to have and offer and also allows INVITES 
> > without an  
> > offer where the UAS sends the offer. I think this will meet your  
> > requirement.
> 
> I don't think flipping who sends the offer is sufficient -- DTLS-SRTP,
> as the several documents are now, uses a=fingerprint to authenticate
> both endpoints.  What Lakshminath is looking for is a way for one side
> to declare that they don't want their certificate used as the 
> authentication mechanism, but rather wants something else used (a
> password or something; 'legacy method' encompasses a lot of stuff).

Hmm... I realize we're used to thinking of certificates as a form
of authentication, but I think that leads people off track in
this case. In DTLS-SRTP, the authentication at the DTLS layer 
serves primarily to bind the authentication performed in the
signalling plane to the cryptography being done in the media

(Continue reading)

headers

Dan Wing | 2 Jun 2007 19:29

RE: Plan for moving forward


> > I don't think flipping who sends the offer is sufficient -- 
> > DTLS-SRTP,
> > as the several documents are now, uses a=fingerprint to authenticate
> > both endpoints.  What Lakshminath is looking for is a way 
> > for one side
> > to declare that they don't want their certificate used as the 
> > authentication mechanism, but rather wants something else used (a
> > password or something; 'legacy method' encompasses a lot of stuff).
> 
> Hmm... I realize we're used to thinking of certificates as a form
> of authentication, but I think that leads people off track in
> this case. In DTLS-SRTP, the authentication at the DTLS layer 
> serves primarily to bind the authentication performed in the
> signalling plane to the cryptography being done in the media 
> plane. That's why it's OK for the certs to be self-signed and
> just authenticated via fingerprint.

Yes, but in conjunction with SIP-Identity (RFC4474) you get
authentication -- if, of course, you trust the entity that 
created that RFC4474 signature.  I don't usually think of DTLS-SRTP
without SIP-Identity, myself -- without SIP-Identity, you're getting
little more than opportunistic encryption (unless you store the
certificate you used last time with that same party, and/or read 
each other's certificate fingerprints or something akin to that).

> I would argue that from an architectural perspective if you
> want another form of authentication (e.g., EAP) you should
> put that at the SIP layer. Remember, there are plenty of contexts
> in which you need to trust the other endpoint where no media streams

(Continue reading)

headers

Hannes Tschofenig | 2 Jun 2007 20:57

Re: Plan for moving forward

This discussion very much reminds me to the discussion we had with Vesa 
Lehtovirta a little bit more than a month ago.
He also had the requirement that "existing credentials" should be 
reused. Whether this works or not depends heavily on the architecture 
and the way how you would like to integrate them into the overall 
solution. If you use, let's say, the UMTS authentication algorithm 
between the SIP UA and the P-CSCF then you can obviously use the SIP 
Identity mechanisms from the P-CSCF towards the other SIP endpoint.

In our previous discussion with Vesa we requested more details and we 
never got them. Now, Lakshminath seems to have also a solution in mind 
but without the details it is hard to figure out whether it works.

I wonder why these details have not been shared with the group already....

Dan Wing wrote:
>   
>>> I don't think flipping who sends the offer is sufficient -- 
>>> DTLS-SRTP,
>>> as the several documents are now, uses a=fingerprint to authenticate
>>> both endpoints.  What Lakshminath is looking for is a way 
>>> for one side
>>> to declare that they don't want their certificate used as the 
>>> authentication mechanism, but rather wants something else used (a
>>> password or something; 'legacy method' encompasses a lot of stuff).
>>>       
>> Hmm... I realize we're used to thinking of certificates as a form
>> of authentication, but I think that leads people off track in
>> this case. In DTLS-SRTP, the authentication at the DTLS layer

(Continue reading)

headers

Lakshminath Dondeti | 3 Jun 2007 00:45

Re: Plan for moving forward

Hannes,

Vesa and I may be talking about two different things.  Vesa, if you are 
following the list, please see below for a description of the use case I 
am talking about.

On 6/2/2007 11:57 AM, Hannes Tschofenig wrote:
> This discussion very much reminds me to the discussion we had with Vesa 
> Lehtovirta a little bit more than a month ago.
> He also had the requirement that "existing credentials" should be 
> reused. Whether this works or not depends heavily on the architecture 
> and the way how you would like to integrate them into the overall 
> solution. If you use, let's say, the UMTS authentication algorithm 
> between the SIP UA and the P-CSCF then you can obviously use the SIP 
> Identity mechanisms from the P-CSCF towards the other SIP endpoint.
> 
> In our previous discussion with Vesa we requested more details and we 
> never got them. Now, Lakshminath seems to have also a solution in mind 
> but without the details it is hard to figure out whether it works.

I don't have a solution in mind really.  I just came across a use case 
recently.  All I am saying is that we should facilitate that use case.

You are familiar with the IKEv2 model: The Initiator authenticates first 
in the "normal" case.  However, it has an option to skip the 
authentication and ask the Responder to authenticate first and then use 
EAP to authenticate itself.

Let's say I have a phone which has the certificate of a gateway.  Using

(Continue reading)

headers

Eric Rescorla | 3 Jun 2007 00:53

Re: Plan for moving forward


At Sat, 02 Jun 2007 15:45:05 -0700,
Lakshminath Dondeti wrote:
> 
> Hannes,
> 
> Vesa and I may be talking about two different things.  Vesa, if you are 
> following the list, please see below for a description of the use case I 
> am talking about.
> 
> On 6/2/2007 11:57 AM, Hannes Tschofenig wrote:
> > This discussion very much reminds me to the discussion we had with Vesa 
> > Lehtovirta a little bit more than a month ago.
> > He also had the requirement that "existing credentials" should be 
> > reused. Whether this works or not depends heavily on the architecture 
> > and the way how you would like to integrate them into the overall 
> > solution. If you use, let's say, the UMTS authentication algorithm 
> > between the SIP UA and the P-CSCF then you can obviously use the SIP 
> > Identity mechanisms from the P-CSCF towards the other SIP endpoint.
> > 
> > In our previous discussion with Vesa we requested more details and we 
> > never got them. Now, Lakshminath seems to have also a solution in mind 
> > but without the details it is hard to figure out whether it works.
> 
> I don't have a solution in mind really.  I just came across a use case 
> recently.  All I am saying is that we should facilitate that use case.
> 
> You are familiar with the IKEv2 model: The Initiator authenticates first 
> in the "normal" case.  However, it has an option to skip the 
> authentication and ask the Responder to authenticate first and then use

(Continue reading)

headers

Eric Rescorla | 2 Jun 2007 19:36

Re: Plan for moving forward


At Sat, 2 Jun 2007 10:29:56 -0700,
Dan Wing wrote:
> 
> 
> > > I don't think flipping who sends the offer is sufficient -- 
> > > DTLS-SRTP,
> > > as the several documents are now, uses a=fingerprint to authenticate
> > > both endpoints.  What Lakshminath is looking for is a way 
> > > for one side
> > > to declare that they don't want their certificate used as the 
> > > authentication mechanism, but rather wants something else used (a
> > > password or something; 'legacy method' encompasses a lot of stuff).
> > 
> > Hmm... I realize we're used to thinking of certificates as a form
> > of authentication, but I think that leads people off track in
> > this case. In DTLS-SRTP, the authentication at the DTLS layer 
> > serves primarily to bind the authentication performed in the
> > signalling plane to the cryptography being done in the media 
> > plane. That's why it's OK for the certs to be self-signed and
> > just authenticated via fingerprint.
> 
> Yes, but in conjunction with SIP-Identity (RFC4474) you get
> authentication -- if, of course, you trust the entity that 
> created that RFC4474 signature.  I don't usually think of DTLS-SRTP
> without SIP-Identity, myself -- without SIP-Identity, you're getting
> little more than opportunistic encryption (unless you store the
> certificate you used last time with that same party, and/or read 
> each other's certificate fingerprints or something akin to that).

(Continue reading)

headers

Lakshminath Dondeti | 3 Jun 2007 00:57

Re: Plan for moving forward

On 6/2/2007 10:36 AM, Eric Rescorla wrote:
> At Sat, 2 Jun 2007 10:29:56 -0700,

> Totally agree. I'm just saying that we ought to think of the 
> authentication as happening in the signalling and being transferred
> into the media. We should try to avoid having authentication 
> mechanisms which authenticate only the media and not the signalling.

Why?  If we apply this to other use cases, this is akin to saying that 
we ought to tie access authentication to end-to-end secure communication.

I can see the point that in case of SIP, communicating parties may 
choose to use identities asserted in the signaling path.

regards,
Lakshminath

> 
> -Ekr
>

headers

Eric Rescorla | 3 Jun 2007 01:31

Re: Plan for moving forward

At Sat, 02 Jun 2007 15:57:11 -0700,
Lakshminath Dondeti wrote:
> 
> 
> 
> On 6/2/2007 10:36 AM, Eric Rescorla wrote:
> > At Sat, 2 Jun 2007 10:29:56 -0700,
> 
> > Totally agree. I'm just saying that we ought to think of the 
> > authentication as happening in the signalling and being transferred
> > into the media. We should try to avoid having authentication 
> > mechanisms which authenticate only the media and not the signalling.
> 
> Why?  If we apply this to other use cases, this is akin to saying that 
> we ought to tie access authentication to end-to-end secure communication.

What other uses cases?

This group is about keying secure RTP sessions that are set up 
via SIP. In that context, SIP is the layer at which identities
are meaningful and end-to-end secure communication is about
leveraging those identities into the provision of secure media.

> I can see the point that in case of SIP, communicating parties may 
> choose to use identities asserted in the signaling path.

I'm not sure what you mean by "asserted". The identities or 
only relevant in the signalling path. What's needed here is that
the media path setup makes sure you're talking to the same entities.

(Continue reading)

headers

Lakshminath Dondeti | 3 Jun 2007 03:35

Re: Plan for moving forward


On 6/2/2007 4:31 PM, Eric Rescorla wrote:
> At Sat, 02 Jun 2007 15:57:11 -0700,
> Lakshminath Dondeti wrote:
>>
>>
>> On 6/2/2007 10:36 AM, Eric Rescorla wrote:
>>> At Sat, 2 Jun 2007 10:29:56 -0700,
>>> Totally agree. I'm just saying that we ought to think of the 
>>> authentication as happening in the signalling and being transferred
>>> into the media. We should try to avoid having authentication 
>>> mechanisms which authenticate only the media and not the signalling.
>> Why?  If we apply this to other use cases, this is akin to saying that 
>> we ought to tie access authentication to end-to-end secure communication.
> 
> What other uses cases?
> 
> This group is about keying secure RTP sessions that are set up 
> via SIP. In that context, SIP is the layer at which identities
> are meaningful and end-to-end secure communication is about
> leveraging those identities into the provision of secure media.
> 

Hmmm, that's one model.  But, why do those two layers have to be tied so 
strongly?

> 
>> I can see the point that in case of SIP, communicating parties may 
>> choose to use identities asserted in the signaling path.
>

(Continue reading)

headers

Dan Wing | 5 Jun 2007 08:08

RE: Plan for moving forward


> >> On 6/2/2007 10:36 AM, Eric Rescorla wrote:
> >>> At Sat, 2 Jun 2007 10:29:56 -0700,
> >>> Totally agree. I'm just saying that we ought to think of the 
> >>> authentication as happening in the signalling and being 
> >>> transferred
> >>> into the media. We should try to avoid having authentication 
> >>> mechanisms which authenticate only the media and not the 
> >>> signalling.
> >> Why?  If we apply this to other use cases, this is akin to 
> >> saying that 
> >> we ought to tie access authentication to end-to-end secure 
> >> communication.
> > 
> > What other uses cases?
> > 
> > This group is about keying secure RTP sessions that are set up 
> > via SIP. In that context, SIP is the layer at which identities
> > are meaningful and end-to-end secure communication is about
> > leveraging those identities into the provision of secure media.
> 
> Hmmm, that's one model.  But, why do those two layers have to 
> be tied so strongly?

Because the media layer needs the signaling layer, or else it
doesn't exist.

The signaling layer (SIP, RTSP, what have you) is necessary for
the media layer.  There isn't any way to create a media layer
without signaling -- you need to signal your transport address

(Continue reading)

headers

Lakshminath Dondeti | 7 Jun 2007 07:41

Additional use cases? (Re: Plan for moving forward)


Apologies for letting my frustration get the better of me over the 
weekend folks.

Thanks for your note Dan.  I have been busy over the past few days and 
hence the delay in responding to you.

I guess I talked about the generic case a few times, so let's start with 
an example.  Consider the use case of using calling cards

Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
(Calling card Server).

Case 1: Uma registers Alice as an authorized phone with Bob.  The 
current model of DTLS-SRTP works (although it reverses the client-server 
relationship).

Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma may 
accept Bob's identity asserted through the SIP infrastructure, but wants 
to authenticate via a secure channel established with Bob authenticated 
and Uma will authenticate by sending calling card information (username, 
password, or just password) as DTMF tones in the media path.  (Note: Uma 
may not necessarily trust Bob's identity asserted through the SIP 
infrastructure.)

Case 3: Bob's identity is asserted in the media path and Uma enters the 
calling card information as DTMF tones in the media path.

In other contexts, the terms user-identity and device-identity have also 
been used.

(Continue reading)

headers

Erwin Davis | 9 Jun 2007 15:13

Re: Additional use cases? (Re: Plan for moving forward)

Hi, folks,

Forgive me as newbbie. Which RFC(s) and draft(s) address the mechanism(s) of

sending calling card info (such as usernames, passwods) as DTMF tones in the

media path and its security mechanims? much appreciated,

Best Regards,

On 6/7/07, Lakshminath Dondeti <ldondeti <at> qualcomm.com > wrote:

Apologies for letting my frustration get the better of me over the
weekend folks.

Thanks for your note Dan.  I have been busy over the past few days and
hence the delay in responding to you.

I guess I talked about the generic case a few times, so let's start with
an example.  Consider the use case of using calling cards

Alice is a SIP Phone, and Uma wants to use it to make a call to Bob
(Calling card Server).

Case 1: Uma registers Alice as an authorized phone with Bob.  The
current model of DTLS-SRTP works (although it reverses the client-server
relationship).

Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma may
accept Bob's identity asserted through the SIP infrastructure, but wants
to authenticate via a secure channel established with Bob authenticated
and Uma will authenticate by sending calling card information (username,
password, or just password) as DTMF tones in the media path.  (Note: Uma
may not necessarily trust Bob's identity asserted through the SIP
infrastructure.)

Case 3: Bob's identity is asserted in the media path and Uma enters the
calling card information as DTMF tones in the media path.

In other contexts, the terms user-identity and device-identity have also
been used.

Note that priority call placement use case is similar.

regards,
Lakshminath

On 6/4/2007 11:08 PM, Dan Wing wrote:
>>>> On 6/2/2007 10:36 AM, Eric Rescorla wrote:
>>>>> At Sat, 2 Jun 2007 10:29:56 -0700,
>>>>> Totally agree. I'm just saying that we ought to think of the
>>>>> authentication as happening in the signalling and being
>>>>> transferred
>>>>> into the media. We should try to avoid having authentication
>>>>> mechanisms which authenticate only the media and not the
>>>>> signalling.
>>>> Why?  If we apply this to other use cases, this is akin to
>>>> saying that
>>>> we ought to tie access authentication to end-to-end secure
>>>> communication.
>>> What other uses cases?
>>>
>>> This group is about keying secure RTP sessions that are set up
>>> via SIP. In that context, SIP is the layer at which identities
>>> are meaningful and end-to-end secure communication is about
>>> leveraging those identities into the provision of secure media.
>> Hmmm, that's one model.  But, why do those two layers have to
>> be tied so strongly?
>
> Because the media layer needs the signaling layer, or else it
> doesn't exist.
>
> The signaling layer (SIP, RTSP, what have you) is necessary for
> the media layer.  There isn't any way to create a media layer
> without signaling -- you need to signal your transport address
> (without it, you can't get media).
>
>>>> I can see the point that in case of SIP, communicating parties may
>>>> choose to use identities asserted in the signaling path.
>>> I'm not sure what you mean by "asserted". The identities or
>>> only relevant in the signalling path. What's needed here is that
>>> the media path setup makes sure you're talking to the same entities.
>> There may be an identity relevant within the local domain and another
>> end-to-end.
>
> Ok, I can see that.  I could be 001234 locally (employee number)
> and dwing <at> cisco.com end-to-end.
>
>> The sense I am getting is that we will just have to
>> establish DTLS-SRTP session using the SIP-level identity and then use
>> other means to prove the second identity.  It looks like we will also
>> have to live with arbitrary notions of client-server relationships in
>> each session.
>
> Can you throw a use-case bone over the wall for everyone to chew on?
>
> -d
>

headers

Cullen Jennings | 14 Jun 2007 00:24

Re: Additional use cases? (Re: Plan for moving forward)


My apologies if this was already answered but RFC 4733 is typically  
used to sent DTMF over RTP. This is widely used and deployed although  
there are other approaches for doing DTMF including as audio in the  
RTP and ways to do it outside the media path such as RFC 4730.

On Jun 9, 2007, at 3:13 PM, Erwin Davis wrote:

> Hi, folks,
>
> Forgive me as newbbie. Which RFC(s) and draft(s) address the  
> mechanism(s) of
> sending calling card info (such as usernames, passwods) as DTMF  
> tones in the
> media path and its security mechanims? much appreciated,
>
> Best Regards,
>
> e
>
>
> On 6/7/07, Lakshminath Dondeti <ldondeti <at> qualcomm.com > wrote:
> Apologies for letting my frustration get the better of me over the
> weekend folks.
>
> Thanks for your note Dan.  I have been busy over the past few days and
> hence the delay in responding to you.
>
> I guess I talked about the generic case a few times, so let's start  
> with
> an example.  Consider the use case of using calling cards
>
> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob
> (Calling card Server).
>
> Case 1: Uma registers Alice as an authorized phone with Bob.  The
> current model of DTLS-SRTP works (although it reverses the client- 
> server
> relationship).
>
> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma may
> accept Bob's identity asserted through the SIP infrastructure, but  
> wants
> to authenticate via a secure channel established with Bob  
> authenticated
> and Uma will authenticate by sending calling card information  
> (username,
> password, or just password) as DTMF tones in the media path.   
> (Note: Uma
> may not necessarily trust Bob's identity asserted through the SIP
> infrastructure.)
>
> Case 3: Bob's identity is asserted in the media path and Uma enters  
> the
> calling card information as DTMF tones in the media path.
>
> In other contexts, the terms user-identity and device-identity have  
> also
> been used.
>
> Note that priority call placement use case is similar.
>
> regards,
> Lakshminath
>
> On 6/4/2007 11:08 PM, Dan Wing wrote:
> >>>> On 6/2/2007 10:36 AM, Eric Rescorla wrote:
> >>>>> At Sat, 2 Jun 2007 10:29:56 -0700,
> >>>>> Totally agree. I'm just saying that we ought to think of the
> >>>>> authentication as happening in the signalling and being
> >>>>> transferred
> >>>>> into the media. We should try to avoid having authentication
> >>>>> mechanisms which authenticate only the media and not the
> >>>>> signalling.
> >>>> Why?  If we apply this to other use cases, this is akin to
> >>>> saying that
> >>>> we ought to tie access authentication to end-to-end secure
> >>>> communication.
> >>> What other uses cases?
> >>>
> >>> This group is about keying secure RTP sessions that are set up
> >>> via SIP. In that context, SIP is the layer at which identities
> >>> are meaningful and end-to-end secure communication is about
> >>> leveraging those identities into the provision of secure media.
> >> Hmmm, that's one model.  But, why do those two layers have to
> >> be tied so strongly?
> >
> > Because the media layer needs the signaling layer, or else it
> > doesn't exist.
> >
> > The signaling layer (SIP, RTSP, what have you) is necessary for
> > the media layer.  There isn't any way to create a media layer
> > without signaling -- you need to signal your transport address
> > (without it, you can't get media).
> >
> >>>> I can see the point that in case of SIP, communicating parties  
> may
> >>>> choose to use identities asserted in the signaling path.
> >>> I'm not sure what you mean by "asserted". The identities or
> >>> only relevant in the signalling path. What's needed here is that
> >>> the media path setup makes sure you're talking to the same  
> entities.
> >> There may be an identity relevant within the local domain and  
> another
> >> end-to-end.
> >
> > Ok, I can see that.  I could be 001234 locally (employee number)
> > and dwing <at> cisco.com end-to-end.
> >
> >> The sense I am getting is that we will just have to
> >> establish DTLS-SRTP session using the SIP-level identity and  
> then use
> >> other means to prove the second identity.  It looks like we will  
> also
> >> have to live with arbitrary notions of client-server  
> relationships in
> >> each session.
> >
> > Can you throw a use-case bone over the wall for everyone to chew on?
> >
> > -d
> >
>
>

headers

Eric Rescorla | 7 Jun 2007 15:28

Re: Additional use cases? (Re: Plan for moving forward)

At Wed, 06 Jun 2007 22:41:34 -0700,
Lakshminath Dondeti wrote:
> I guess I talked about the generic case a few times, so let's start with 
> an example.  Consider the use case of using calling cards
> 
> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
> (Calling card Server).
> 
> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
> current model of DTLS-SRTP works (although it reverses the client-server 
> relationship).

Why does this reverse the client-server relationship?

1. DTLS-SRTP requires that both sides have certificates, but EITHER
side can have a self-signed cert or a third-party cert. This is true
no matter which side is client or server. 

2. The client-server relationship in DTLS-SRTP is actually independent
of who is the caller. It's controlled by passive/active attributes
in the SDP. In general, it's attractive for the answerer to be the
client, purely for the performance reason that if you're not using
ICE you want the ClientHello to be sent immediately to minimize RTTs.
[With ICE, the performance issues are more complicated and depend
on which side is controlling and whether you are doing aggressive
or regular nomination].

> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma may 
> accept Bob's identity asserted through the SIP infrastructure, but wants 
> to authenticate via a secure channel established with Bob authenticated 
> and Uma will authenticate by sending calling card information (username, 
> password, or just password) as DTMF tones in the media path.  (Note: Uma 
> may not necessarily trust Bob's identity asserted through the SIP 
> infrastructure.)
>
> Case 3: Bob's identity is asserted in the media path and Uma enters the 
> calling card information as DTMF tones in the media path.
>
> In other contexts, the terms user-identity and device-identity have also 
> been used.
> 
> Note that priority call placement use case is similar.

I don't understand why you think that any of these cases presents
a problem. 

You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
which are all about protecting the signalling channel and binding
it to the media and then you pass the DTMF or whatever in the
media. This works fine.

-Ekr

headers

Francois Audet | 8 Jun 2007 02:11

RE: Additional use cases? (Re: Plan for moving forward)


I agree with Eric.

More on the "it doesn't matter who is the caller" stuff:

On the RFC 4474 side, RFC 4474 allows for the sender of the request
to provide the identity assertion. Yes, indeed, this is the calling
party.

There is no "response" identity. However, the callee may send its own
request in 
the reverse direction to provide it's own identity, as per 
draft-ietf-sip-connected-identity-05.txt. 

In other words, in SIP also there is no implied "direction" to this,
even if 
technically, the origin of the protocol used a client/server model (as
in,
request/response).

I think we'll have to write up a "high level" description on how these
pieces
fit together.

> -----Original Message-----
> From: owner-ietf-rtpsec <at> mail.imc.org 
> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of Eric Rescorla
> Sent: Thursday, June 07, 2007 06:28
> To: Lakshminath Dondeti
> Cc: Dan Wing; ietf-rtpsec <at> imc.org; 'Sam Hartman'; 'Tim Polk'; 
> jon.peterson <at> neustar.biz
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> 
> At Wed, 06 Jun 2007 22:41:34 -0700,
> Lakshminath Dondeti wrote:
> > I guess I talked about the generic case a few times, so let's start 
> > with an example.  Consider the use case of using calling cards
> > 
> > Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
> > (Calling card Server).
> > 
> > Case 1: Uma registers Alice as an authorized phone with Bob.  The 
> > current model of DTLS-SRTP works (although it reverses the 
> > client-server relationship).
> 
> Why does this reverse the client-server relationship?
> 
> 1. DTLS-SRTP requires that both sides have certificates, but 
> EITHER side can have a self-signed cert or a third-party 
> cert. This is true no matter which side is client or server. 
> 
> 2. The client-server relationship in DTLS-SRTP is actually 
> independent of who is the caller. It's controlled by 
> passive/active attributes in the SDP. In general, it's 
> attractive for the answerer to be the client, purely for the 
> performance reason that if you're not using ICE you want the 
> ClientHello to be sent immediately to minimize RTTs.
> [With ICE, the performance issues are more complicated and 
> depend on which side is controlling and whether you are doing 
> aggressive or regular nomination].
> 
> 
> > Case 2: Alice is any SIP Phone and Uma makes a call using 
> it.  Uma may 
> > accept Bob's identity asserted through the SIP infrastructure, but 
> > wants to authenticate via a secure channel established with Bob 
> > authenticated and Uma will authenticate by sending calling card 
> > information (username, password, or just password) as DTMF tones in 
> > the media path.  (Note: Uma may not necessarily trust Bob's 
> identity 
> > asserted through the SIP
> > infrastructure.)
> >
> > Case 3: Bob's identity is asserted in the media path and Uma enters 
> > the calling card information as DTMF tones in the media path.
> >
> > In other contexts, the terms user-identity and device-identity have 
> > also been used.
> > 
> > Note that priority call placement use case is similar.
> 
> I don't understand why you think that any of these cases 
> presents a problem. 
> 
> You just do the ordinary SIP-Identity + DTLS-SRTP handshake, 
> which are all about protecting the signalling channel and 
> binding it to the media and then you pass the DTMF or 
> whatever in the media. This works fine.
> 
> -Ekr
> 
> 
>

headers

Hannes Tschofenig | 9 Jun 2007 17:59

Re: Additional use cases? (Re: Plan for moving forward)


Hi Francois,

Francois Audet wrote:
> I agree with Eric.
>
> More on the "it doesn't matter who is the caller" stuff:
>
> On the RFC 4474 side, RFC 4474 allows for the sender of the request
> to provide the identity assertion. Yes, indeed, this is the calling
> party.
>
> There is no "response" identity. However, the callee may send its own
> request in 
> the reverse direction to provide it's own identity, as per 
> draft-ietf-sip-connected-identity-05.txt. 
>
> In other words, in SIP also there is no implied "direction" to this,
> even if 
> technically, the origin of the protocol used a client/server model (as
> in,
> request/response).
>
> I think we'll have to write up a "high level" description on how these
> pieces
> fit together.
>   

http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.txt is meant 
to provide how these pieces fit together. Do you think that there is 
something missing that needs to be added?

Ciao
Hannes

headers

Jonathan Rosenberg | 12 Jun 2007 20:52

Re: Additional use cases? (Re: Plan for moving forward)


One issue, which was raised in mmusic, is that RFC 4145 links together 
directionality of TLS and directionality of the TCP connection. Here, 
you are using RFC 4145 JUST to indicate TLS directionality. This causes 
things to get messed up with ICE; ICE will establish the TCP connections 
using its own attributes to indicate directionality, and furthermore 
allows for simultaneous opens. Thus, the direction of TCP connection 
opening can be independent from the TLS roles.

Its not clear to me we should be reusing the comedia directionality 
attributes.

-Jonathan R.

Hannes Tschofenig wrote:
> 
> Hi Francois,
> 
> 
> Francois Audet wrote:
> 
>> I agree with Eric.
>>
>> More on the "it doesn't matter who is the caller" stuff:
>>
>> On the RFC 4474 side, RFC 4474 allows for the sender of the request
>> to provide the identity assertion. Yes, indeed, this is the calling
>> party.
>>
>> There is no "response" identity. However, the callee may send its own
>> request in the reverse direction to provide it's own identity, as per 
>> draft-ietf-sip-connected-identity-05.txt.
>> In other words, in SIP also there is no implied "direction" to this,
>> even if technically, the origin of the protocol used a client/server 
>> model (as
>> in,
>> request/response).
>>
>> I think we'll have to write up a "high level" description on how these
>> pieces
>> fit together.
>>   
> 
> 
> http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.txt is meant 
> to provide how these pieces fit together. Do you think that there is 
> something missing that needs to be added?
> 
> Ciao
> Hannes
> 

--

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

headers

Dan Wing | 12 Jun 2007 21:02

RE: Additional use cases? (Re: Plan for moving forward)


For DTLS, why not allow both sides to send a DTLS ClientHello, and use a
tie-breaker to decide which wins (larger random value wins).

-d

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com] 
> Sent: Tuesday, June 12, 2007 11:53 AM
> To: Hannes Tschofenig
> Cc: Francois Audet; Eric Rescorla; Lakshminath Dondeti; Dan 
> Wing; ietf-rtpsec <at> imc.org; Sam Hartman; Tim Polk; 
> jon.peterson <at> neustar.biz
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> One issue, which was raised in mmusic, is that RFC 4145 links 
> together 
> directionality of TLS and directionality of the TCP connection. Here, 
> you are using RFC 4145 JUST to indicate TLS directionality. 
> This causes 
> things to get messed up with ICE; ICE will establish the TCP 
> connections 
> using its own attributes to indicate directionality, and furthermore 
> allows for simultaneous opens. Thus, the direction of TCP connection 
> opening can be independent from the TLS roles.
> 
> Its not clear to me we should be reusing the comedia directionality 
> attributes.
> 
> -Jonathan R.
> 
> Hannes Tschofenig wrote:
> > 
> > Hi Francois,
> > 
> > 
> > Francois Audet wrote:
> > 
> >> I agree with Eric.
> >>
> >> More on the "it doesn't matter who is the caller" stuff:
> >>
> >> On the RFC 4474 side, RFC 4474 allows for the sender of the request
> >> to provide the identity assertion. Yes, indeed, this is the calling
> >> party.
> >>
> >> There is no "response" identity. However, the callee may 
> send its own
> >> request in the reverse direction to provide it's own 
> identity, as per 
> >> draft-ietf-sip-connected-identity-05.txt.
> >> In other words, in SIP also there is no implied 
> "direction" to this,
> >> even if technically, the origin of the protocol used a 
> client/server 
> >> model (as
> >> in,
> >> request/response).
> >>
> >> I think we'll have to write up a "high level" description 
> on how these
> >> pieces
> >> fit together.
> >>   
> > 
> > 
> > 
> http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.tx
> t is meant 
> > to provide how these pieces fit together. Do you think that 
> there is 
> > something missing that needs to be added?
> > 
> > Ciao
> > Hannes
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen <at> cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com

headers

Eric Rescorla | 12 Jun 2007 21:27

Re: Additional use cases? (Re: Plan for moving forward)


At Tue, 12 Jun 2007 12:02:44 -0700,
Dan Wing wrote:
> For DTLS, why not allow both sides to send a DTLS ClientHello, and use a
> tie-breaker to decide which wins (larger random value wins).

This seems to complicate things unnecessarily. If we need a separate
attribute here let's add it.

-Ekr

headers

Lakshminath Dondeti | 12 Jun 2007 21:33

Re: Additional use cases? (Re: Plan for moving forward)


If we allow the DTLS ClientHello to be part of the SIP INVITE, would 
there still be a need for a tie-breaker?

Lakshminath

On 6/12/2007 12:02 PM, Dan Wing wrote:
> For DTLS, why not allow both sides to send a DTLS ClientHello, and use a
> tie-breaker to decide which wins (larger random value wins).
> 
> -d
> 
> 
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com] 
>> Sent: Tuesday, June 12, 2007 11:53 AM
>> To: Hannes Tschofenig
>> Cc: Francois Audet; Eric Rescorla; Lakshminath Dondeti; Dan 
>> Wing; ietf-rtpsec <at> imc.org; Sam Hartman; Tim Polk; 
>> jon.peterson <at> neustar.biz
>> Subject: Re: Additional use cases? (Re: Plan for moving forward)
>>
>> One issue, which was raised in mmusic, is that RFC 4145 links 
>> together 
>> directionality of TLS and directionality of the TCP connection. Here, 
>> you are using RFC 4145 JUST to indicate TLS directionality. 
>> This causes 
>> things to get messed up with ICE; ICE will establish the TCP 
>> connections 
>> using its own attributes to indicate directionality, and furthermore 
>> allows for simultaneous opens. Thus, the direction of TCP connection 
>> opening can be independent from the TLS roles.
>>
>> Its not clear to me we should be reusing the comedia directionality 
>> attributes.
>>
>> -Jonathan R.
>>
>> Hannes Tschofenig wrote:
>>> Hi Francois,
>>>
>>>
>>> Francois Audet wrote:
>>>
>>>> I agree with Eric.
>>>>
>>>> More on the "it doesn't matter who is the caller" stuff:
>>>>
>>>> On the RFC 4474 side, RFC 4474 allows for the sender of the request
>>>> to provide the identity assertion. Yes, indeed, this is the calling
>>>> party.
>>>>
>>>> There is no "response" identity. However, the callee may 
>> send its own
>>>> request in the reverse direction to provide it's own 
>> identity, as per 
>>>> draft-ietf-sip-connected-identity-05.txt.
>>>> In other words, in SIP also there is no implied 
>> "direction" to this,
>>>> even if technically, the origin of the protocol used a 
>> client/server 
>>>> model (as
>>>> in,
>>>> request/response).
>>>>
>>>> I think we'll have to write up a "high level" description 
>> on how these
>>>> pieces
>>>> fit together.
>>>>   
>>>
>>>
>> http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.tx
>> t is meant 
>>> to provide how these pieces fit together. Do you think that 
>> there is 
>>> something missing that needs to be added?
>>>
>>> Ciao
>>> Hannes
>>>
>> -- 
>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> Cisco Fellow                                   Parsippany, NJ 
>> 07054-2711
>> Cisco Systems
>> jdrosen <at> cisco.com                              FAX:   (973) 952-5050
>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>> http://www.cisco.com
>

headers

Eric Rescorla | 12 Jun 2007 21:36

Re: Additional use cases? (Re: Plan for moving forward)


At Tue, 12 Jun 2007 12:33:02 -0700,
Lakshminath Dondeti wrote:
> If we allow the DTLS ClientHello to be part of the SIP INVITE, would 
> there still be a need for a tie-breaker?

That's effectively using the INVITE to commit to one direction.

-Ekr

headers

Lakshminath Dondeti | 12 Jun 2007 21:39

Re: Additional use cases? (Re: Plan for moving forward)


Right.  So, why not do it?

Lakshminath

On 6/12/2007 12:36 PM, Eric Rescorla wrote:
> At Tue, 12 Jun 2007 12:33:02 -0700,
> Lakshminath Dondeti wrote:
>> If we allow the DTLS ClientHello to be part of the SIP INVITE, would 
>> there still be a need for a tie-breaker?
> 
> That's effectively using the INVITE to commit to one direction.
> 
> -Ekr
>

headers

Eric Rescorla | 12 Jun 2007 21:46

Re: Additional use cases? (Re: Plan for moving forward)


At Tue, 12 Jun 2007 12:39:47 -0700,
Lakshminath Dondeti wrote:
> Right.  So, why not do it?

Because it involves a number of changes in the DTLS model (having
one message happen out of band, having one clienthello elicit
multiple serverhellos, etc.) and nobody has described a compelling
reason to do this.

-Ekr

headers

Lakshminath Dondeti | 13 Jun 2007 00:45

Re: Additional use cases? (Re: Plan for moving forward)

Interesting ...  I wondered about the reasoning of multiple 
serverhellos.  Is the argument that multiple clienthellos are alright 
since that amounts to lower overhead than multiple serverhellos (if the 
expected response is HelloVerifyRequest, then the overhead might be 
similar)?  But that seems to optimize for the forking use case and 
ignores other use cases.

Why is the ClientHello going out-of-band a problem?

As to why to do this: it seems to allow the use case I was talking about 
and Dan was making a case for it too earlier today.

regards,
Lakshminath

On 6/12/2007 12:46 PM, Eric Rescorla wrote:
> At Tue, 12 Jun 2007 12:39:47 -0700,
> Lakshminath Dondeti wrote:
>> Right.  So, why not do it?
> 
> Because it involves a number of changes in the DTLS model (having
> one message happen out of band, having one clienthello elicit
> multiple serverhellos, etc.) and nobody has described a compelling
> reason to do this.
> 
> -Ekr
>

headers

Dan Wing | 13 Jun 2007 01:14

RE: Additional use cases? (Re: Plan for moving forward)

> Interesting ...  I wondered about the reasoning of multiple 
> serverhellos.  Is the argument that multiple clienthellos are alright 
> since that amounts to lower overhead than multiple 
> serverhellos (if the expected response is HelloVerifyRequest, 
> then the overhead might be similar)? 

The client instantiates its state prior to sending a ClientHello,
and the server instantiates its state when it receives a ClientHello.

If a client were to send a ClientHello in an Invite, and the call
forked, and the client received a bunch of ServerHellos, it wouldn't
be doing DTLS anymore because the client would instantate new state 
for each of those ServerHellos that arrive (and complete the DTLS 
handshake with each of those).

> But that seems to optimize for the forking use case and 
> ignores other use cases.

That = the existing DTLS-SRTP specifications?

I don't see how they are optimized for forking and de-optimized
for the non-forking case.  Do you mean it's much too expensive
for the originator (who may have to deal with a bunch of forked
endpoints) than you'd like?  Or do you mean it's not efficient
over-the-wire (bandwidth?).

> Why is the ClientHello going out-of-band a problem?

In addition to the problem of forking causing multiple ServerHellos,
you'd have to prevent your DTLS implementation from sending its
ClientHello over the wire, grab its data and stick it into a
SIP header or into the SDP or wherever you were thinking it would
go.  Not hard, but not beautiful, either.

> As to why to do this: it seems to allow the use case I was 
> talking about

The use case where someone dials a number and proves their identity
using a PIN?  One thing you mentioned at the bottom of your first
email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
that "priority call placement use case is similar"; however, it
isn't -- IEPREP isn't requiring someone to connect to a remote
gateway, prove their identity to that remote gateway, and someone
pull that authentication and authorization 'back' into the 
originating network.  The trouble with such an approach is how
you'd get the access to perform that connection to that remote
resource in order to initiate that authorization in the first
place -- the phone system is overloaded and the more components
of it you involve the more likely you'll find overload.

> and Dan was making a case for it too earlier 
> today.

In my email related to directionality?  That was only an idea
to avoid the SDP for directionality.

-d

> regards,
> Lakshminath
> 
> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
> > At Tue, 12 Jun 2007 12:39:47 -0700,
> > Lakshminath Dondeti wrote:
> >> Right.  So, why not do it?
> > 
> > Because it involves a number of changes in the DTLS model (having
> > one message happen out of band, having one clienthello elicit
> > multiple serverhellos, etc.) and nobody has described a compelling
> > reason to do this.
> > 
> > -Ekr
> >

headers

Lakshminath Dondeti | 13 Jun 2007 02:02

Re: Additional use cases? (Re: Plan for moving forward)


Dan,

I was talking about the GETS use case.  My understanding is that IEPREP 
is considering that use case although I did not find a call flow to 
point to (I don't know for sure, could someone verify that?).  Perhaps 
others in this list may have ready references.

thanks,
Lakshminath

On 6/12/2007 4:14 PM, Dan Wing wrote:
> 
> The use case where someone dials a number and proves their identity
> using a PIN?  One thing you mentioned at the bottom of your first
> email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
> that "priority call placement use case is similar"; however, it
> isn't -- IEPREP isn't requiring someone to connect to a remote
> gateway, prove their identity to that remote gateway, and someone
> pull that authentication and authorization 'back' into the 
> originating network.  The trouble with such an approach is how
> you'd get the access to perform that connection to that remote
> resource in order to initiate that authorization in the first
> place -- the phone system is overloaded and the more components
> of it you involve the more likely you'll find overload.
> 
>> and Dan was making a case for it too earlier 
>> today.
> 
> In my email related to directionality?  That was only an idea
> to avoid the SDP for directionality.
> 
> -d
> 
>  
>> regards,
>> Lakshminath
>>
>> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
>>> At Tue, 12 Jun 2007 12:39:47 -0700,
>>> Lakshminath Dondeti wrote:
>>>> Right.  So, why not do it?
>>> Because it involves a number of changes in the DTLS model (having
>>> one message happen out of band, having one clienthello elicit
>>> multiple serverhellos, etc.) and nobody has described a compelling
>>> reason to do this.
>>>
>>> -Ekr
>>>
>

headers

Dan Wing | 13 Jun 2007 02:28

DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]

> I was talking about the GETS use case.  My understanding is 
> that IEPREP is considering that use case although I did not 
> find a call flow to point to (I don't know for sure, could 
> someone verify that?).  Perhaps others in this list may 
> have ready references.

IEPREP's existing work excludes cross-domain authentication and 
authorization.  In any event, I don't see how GETS/IEPREP is 
harmed, in any way, if the UAC is really owned by Alice Waters
(chef at a good restaurant here in California) but, due to the
recent earthquake, a nice gentleman from FEMA is using Alice's
home phone and provides authentication to an IEPREP-capable 
system (whatever it is) and gets authorization to make a 
high-bandwidth multimedia call to someone in another city, at
a time where mere mortals aren't able to acquire sufficient
bandwidth or SIP signaling (or whatever) to make a similar
call.

You must believe there is some potential harm with IEPREP
and the network asserting that Alice's phone was involved.
I don't see the harm.  If you still feel there is harm, we'll
need more details -- I don't see the harm and I don't see a 
requirement that falls out of IEPREP or a GETS use case that
applies to RTPSEC.

-d

> thanks,
> Lakshminath
> 
> On 6/12/2007 4:14 PM, Dan Wing wrote:
> > 
> > The use case where someone dials a number and proves their identity
> > using a PIN?  One thing you mentioned at the bottom of your first
> > email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
> > that "priority call placement use case is similar"; however, it
> > isn't -- IEPREP isn't requiring someone to connect to a remote
> > gateway, prove their identity to that remote gateway, and someone
> > pull that authentication and authorization 'back' into the 
> > originating network.  The trouble with such an approach is how
> > you'd get the access to perform that connection to that remote
> > resource in order to initiate that authorization in the first
> > place -- the phone system is overloaded and the more components
> > of it you involve the more likely you'll find overload.
> > 
> >> and Dan was making a case for it too earlier 
> >> today.
> > 
> > In my email related to directionality?  That was only an idea
> > to avoid the SDP for directionality.
> > 
> > -d
> > 
> >  
> >> regards,
> >> Lakshminath
> >>
> >> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
> >>> At Tue, 12 Jun 2007 12:39:47 -0700,
> >>> Lakshminath Dondeti wrote:
> >>>> Right.  So, why not do it?
> >>> Because it involves a number of changes in the DTLS model (having
> >>> one message happen out of band, having one clienthello elicit
> >>> multiple serverhellos, etc.) and nobody has described a compelling
> >>> reason to do this.
> >>>
> >>> -Ekr
> >>>
> >

headers

Lakshminath Dondeti | 13 Jun 2007 03:59

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


Hmm, interesting choice of words.

All I was saying was that there is a class of applications that we 
should be able to optimize for.  Skipping client authentication during 
secure tunnel establishment and using a legacy method inside the secure 
tunnel is a mode of operation allowed elsewhere in the IETF (e.g., TTLS, 
PEAP, IKEv2-EAP).  However, we seem to be not allowing that with 
DTLS-SRTP.  We mandate the client to authenticate using self-signed 
certs.  There are use cases where that client authentication has a 
purpose.  Elsewhere it is wasteful.  Is there "harm" due to that 
additional requirement?  I am saying why does one have to fight that 
battle in making a case to other standards organizations in adopting 
IETF protocols.  I can think of simple counter arguments: do what is 
necessary and nothing more.

The only argument against that I see so far is that DTLS-SRTP is the 
chosen protocol and the chosen protocol must not be changed.

regards,
Lakshminath

On 6/12/2007 5:28 PM, Dan Wing wrote:
>> I was talking about the GETS use case.  My understanding is 
>> that IEPREP is considering that use case although I did not 
>> find a call flow to point to (I don't know for sure, could 
>> someone verify that?).  Perhaps others in this list may 
>> have ready references.
> 
> IEPREP's existing work excludes cross-domain authentication and 
> authorization.  In any event, I don't see how GETS/IEPREP is 
> harmed, in any way, if the UAC is really owned by Alice Waters
> (chef at a good restaurant here in California) but, due to the
> recent earthquake, a nice gentleman from FEMA is using Alice's
> home phone and provides authentication to an IEPREP-capable 
> system (whatever it is) and gets authorization to make a 
> high-bandwidth multimedia call to someone in another city, at
> a time where mere mortals aren't able to acquire sufficient
> bandwidth or SIP signaling (or whatever) to make a similar
> call.
> 
> You must believe there is some potential harm with IEPREP
> and the network asserting that Alice's phone was involved.
> I don't see the harm.  If you still feel there is harm, we'll
> need more details -- I don't see the harm and I don't see a 
> requirement that falls out of IEPREP or a GETS use case that
> applies to RTPSEC.
> 
> -d
> 
> 
>> thanks,
>> Lakshminath
>>
>> On 6/12/2007 4:14 PM, Dan Wing wrote:
>>> The use case where someone dials a number and proves their identity
>>> using a PIN?  One thing you mentioned at the bottom of your first
>>> email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
>>> that "priority call placement use case is similar"; however, it
>>> isn't -- IEPREP isn't requiring someone to connect to a remote
>>> gateway, prove their identity to that remote gateway, and someone
>>> pull that authentication and authorization 'back' into the 
>>> originating network.  The trouble with such an approach is how
>>> you'd get the access to perform that connection to that remote
>>> resource in order to initiate that authorization in the first
>>> place -- the phone system is overloaded and the more components
>>> of it you involve the more likely you'll find overload.
>>>
>>>> and Dan was making a case for it too earlier 
>>>> today.
>>> In my email related to directionality?  That was only an idea
>>> to avoid the SDP for directionality.
>>>
>>> -d
>>>
>>>  
>>>> regards,
>>>> Lakshminath
>>>>
>>>> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
>>>>> At Tue, 12 Jun 2007 12:39:47 -0700,
>>>>> Lakshminath Dondeti wrote:
>>>>>> Right.  So, why not do it?
>>>>> Because it involves a number of changes in the DTLS model (having
>>>>> one message happen out of band, having one clienthello elicit
>>>>> multiple serverhellos, etc.) and nobody has described a compelling
>>>>> reason to do this.
>>>>>
>>>>> -Ekr
>>>>>
>

headers

Eric Rescorla | 13 Jun 2007 05:14

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]

At Tue, 12 Jun 2007 18:59:32 -0700,
Lakshminath Dondeti wrote:
> Hmm, interesting choice of words.
> 
> All I was saying was that there is a class of applications that we 
> should be able to optimize for.  Skipping client authentication during 
> secure tunnel establishment and using a legacy method inside the secure 
> tunnel is a mode of operation allowed elsewhere in the IETF (e.g., TTLS, 
> PEAP, IKEv2-EAP). However, we seem to be not allowing that with 
> DTLS-SRTP.  We mandate the client to authenticate using self-signed 
> certs.  There are use cases where that client authentication has a 
> purpose.  Elsewhere it is wasteful.

I'm not convinced that that's true. Again, the client authentication's
job is to tie the signalling to the media. I haven't yet heard from
you a case where that's clearly not desirable. Even in cases where
you don't care who you are talking to or you have some in-tunnel way
of doing so, you still need to tie it to the signalling, because
you depend on the signalling for things like call transfer.

>  Is there "harm" due to that 
> additional requirement?  I am saying why does one have to fight that 
> battle in making a case to other standards organizations in adopting 
> IETF protocols.  I can think of simple counter arguments: do what is 
> necessary and nothing more.
>
> The only argument against that I see so far is that DTLS-SRTP is the 
> chosen protocol and the chosen protocol must not be changed.

Funny, I don't recall anyone making that argument. 

I do, however, recall making that argument both earlier on this
thread and at several IETF meetings.

-Ekr

headers

Francois Audet | 13 Jun 2007 17:57

RE: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


> > The only argument against that I see so far is that 
> DTLS-SRTP is the 
> > chosen protocol and the chosen protocol must not be changed.

Didn't we agree on this at the last meeting?

Isn't it time to move on?

headers

Lakshminath Dondeti | 13 Jun 2007 19:02

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]

Francois,

We don't make decisions at a meeting in the IETF.

We definitely didn't say that DTLS-SRTP cannot be changed.  If you 
recall, change control was a big part of the arguments at the meeting.

I am not (cannot) stopping anyone from making progress.  I am simply 
presenting a use case and seeking clarification on why some properties 
are more important than others.  In some systems, optimization of 
computational and communication overhead is important.  If we have to 
sacrifice some security properties, as long as the risks are well 
understood, it should be allowed (that's one of the reasons we have the 
security considerations section).

The necessary question to ask is what security properties are considered 
crucial to all use cases and why.  That is an important discussion to 
have.  One of the lessons from history is that IKE main mode had some 
properties people didn't care for, that made the quick mode popular and 
subsequently in IKEv2 we got rid of some of those properties in the 
interest of fewer RTs.  Now of course, IKEv2 effort was motivated by a 
lot of other reasons too.

regards,
Lakshminath

On 6/13/2007 8:57 AM, Francois Audet wrote:
>>> The only argument against that I see so far is that 
>> DTLS-SRTP is the 
>>> chosen protocol and the chosen protocol must not be changed.
> 
> Didn't we agree on this at the last meeting?
> 
> Isn't it time to move on?
>

headers

Cullen Jennings | 14 Jun 2007 00:24

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


On Jun 13, 2007, at 7:02 PM, Lakshminath Dondeti wrote:

> We don't make decisions at a meeting in the IETF.

Could you please send me the RFC that says that but, please, I would  
rather not repeat the thread from IETF list here.

The advice I have given chairs about consensus for several years now  
(long before I was an AD) is the following: It is my personally  
opinion that when chairs consider how to determine rough consensus,  
they should not ignore the opinions that have been expressed on the  
list or the opinions that have been expressed in the room.

Cullen <with my individual hat on>

headers

Lakshminath Dondeti | 14 Jun 2007 00:37

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


rfc4677

On 6/13/2007 3:24 PM, Cullen Jennings wrote:
> 
> On Jun 13, 2007, at 7:02 PM, Lakshminath Dondeti wrote:
> 
>> We don't make decisions at a meeting in the IETF.
> 
> Could you please send me the RFC that says that but, please, I would 
> rather not repeat the thread from IETF list here.
> 
> The advice I have given chairs about consensus for several years now 
> (long before I was an AD) is the following: It is my personally opinion 
> that when chairs consider how to determine rough consensus, they should 
> not ignore the opinions that have been expressed on the list or the 
> opinions that have been expressed in the room.
> 
> Cullen <with my individual hat on>
>

headers

Spencer Dawkins | 14 Jun 2007 02:05

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


Ummm, actually RFC 4677 is an excellent document, but it's not normative 
(Informational).

The RFC that discusses working group consensus and decision making at 
meetings/onlist is RFC 2418, AKA BCP 25, "IETF Working Group Guidelines and 
Procedures", especially around sections 3.2 and 3.3.

Spencer

>
> rfc4677
>
> On 6/13/2007 3:24 PM, Cullen Jennings wrote:
>>
>> On Jun 13, 2007, at 7:02 PM, Lakshminath Dondeti wrote:
>>
>>> We don't make decisions at a meeting in the IETF.
>>
>> Could you please send me the RFC that says that but, please, I would 
>> rather not repeat the thread from IETF list here.
>>
>> The advice I have given chairs about consensus for several years now 
>> (long before I was an AD) is the following: It is my personally opinion 
>> that when chairs consider how to determine rough consensus, they should 
>> not ignore the opinions that have been expressed on the list or the 
>> opinions that have been expressed in the room.
>>
>> Cullen <with my individual hat on>
>>
>
>

headers

Dan Wing | 13 Jun 2007 04:55

RE: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> Sent: Tuesday, June 12, 2007 7:00 PM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Jonathan Rosenberg'; 'Hannes 
> Tschofenig'; 'Francois Audet'; ietf-rtpsec <at> imc.org; 'Sam 
> Hartman'; 'Tim Polk'; jon.peterson <at> neustar.biz
> Subject: Re: DTLS-SRTP harming GETS [was RE: Additional use 
> cases? (Re: Plan for moving forward)]
> 
> Hmm, interesting choice of words.
>
> All I was saying was that there is a class of applications that we 
> should be able to optimize for.  Skipping client 
> authentication during secure tunnel establishment and using 
> a legacy method inside the secure tunnel is a mode of 
> operation allowed elsewhere in the IETF (e.g., TTLS, PEAP, 
> IKEv2-EAP). 

But we don't have a legacy method to authenticate an RTP endpoint
or an SRTP endpoint.

> However, we seem to be not allowing that with 
> DTLS-SRTP.  We mandate the client to authenticate using self-signed 
> certs.  There are use cases where that client authentication has a 
> purpose.  Elsewhere it is wasteful.  Is there "harm" due to that 
> additional requirement?  I am saying why does one have to fight that 
> battle in making a case to other standards organizations in adopting 
> IETF protocols.  I can think of simple counter arguments: do what is 
> necessary and nothing more.

That's reasonable.  But it is an optimization that saves ~600 bytes 
or so?  Or are you just trying to allow one side to ignore the 
certificate sent by the other (that is, don't verify it matches
the associated a=fingerprint).

And as others have stated, it complicates things to optimize this.
You are well aware of the risks in complicating security protocols.

> The only argument against that I see so far is that DTLS-SRTP is the 
> chosen protocol and the chosen protocol must not be changed.

Every requirement needs justification.

-d

> regards,
> Lakshminath
> 
> On 6/12/2007 5:28 PM, Dan Wing wrote:
> >> I was talking about the GETS use case.  My understanding is 
> >> that IEPREP is considering that use case although I did not 
> >> find a call flow to point to (I don't know for sure, could 
> >> someone verify that?).  Perhaps others in this list may 
> >> have ready references.
> > 
> > IEPREP's existing work excludes cross-domain authentication and 
> > authorization.  In any event, I don't see how GETS/IEPREP is 
> > harmed, in any way, if the UAC is really owned by Alice Waters
> > (chef at a good restaurant here in California) but, due to the
> > recent earthquake, a nice gentleman from FEMA is using Alice's
> > home phone and provides authentication to an IEPREP-capable 
> > system (whatever it is) and gets authorization to make a 
> > high-bandwidth multimedia call to someone in another city, at
> > a time where mere mortals aren't able to acquire sufficient
> > bandwidth or SIP signaling (or whatever) to make a similar
> > call.
> > 
> > You must believe there is some potential harm with IEPREP
> > and the network asserting that Alice's phone was involved.
> > I don't see the harm.  If you still feel there is harm, we'll
> > need more details -- I don't see the harm and I don't see a 
> > requirement that falls out of IEPREP or a GETS use case that
> > applies to RTPSEC.
> > 
> > -d
> > 
> > 
> >> thanks,
> >> Lakshminath
> >>
> >> On 6/12/2007 4:14 PM, Dan Wing wrote:
> >>> The use case where someone dials a number and proves 
> their identity
> >>> using a PIN?  One thing you mentioned at the bottom of your first
> >>> email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
> >>> that "priority call placement use case is similar"; however, it
> >>> isn't -- IEPREP isn't requiring someone to connect to a remote
> >>> gateway, prove their identity to that remote gateway, and someone
> >>> pull that authentication and authorization 'back' into the 
> >>> originating network.  The trouble with such an approach is how
> >>> you'd get the access to perform that connection to that remote
> >>> resource in order to initiate that authorization in the first
> >>> place -- the phone system is overloaded and the more components
> >>> of it you involve the more likely you'll find overload.
> >>>
> >>>> and Dan was making a case for it too earlier 
> >>>> today.
> >>> In my email related to directionality?  That was only an idea
> >>> to avoid the SDP for directionality.
> >>>
> >>> -d
> >>>
> >>>  
> >>>> regards,
> >>>> Lakshminath
> >>>>
> >>>> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
> >>>>> At Tue, 12 Jun 2007 12:39:47 -0700,
> >>>>> Lakshminath Dondeti wrote:
> >>>>>> Right.  So, why not do it?
> >>>>> Because it involves a number of changes in the DTLS 
> model (having
> >>>>> one message happen out of band, having one clienthello elicit
> >>>>> multiple serverhellos, etc.) and nobody has described a 
> compelling
> >>>>> reason to do this.
> >>>>>
> >>>>> -Ekr
> >>>>>
> >

headers

Lakshminath Dondeti | 13 Jun 2007 05:24

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


On 6/12/2007 7:55 PM, Dan Wing wrote:
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
>> Sent: Tuesday, June 12, 2007 7:00 PM
>> To: Dan Wing
>> Cc: 'Eric Rescorla'; 'Jonathan Rosenberg'; 'Hannes 
>> Tschofenig'; 'Francois Audet'; ietf-rtpsec <at> imc.org; 'Sam 
>> Hartman'; 'Tim Polk'; jon.peterson <at> neustar.biz
>> Subject: Re: DTLS-SRTP harming GETS [was RE: Additional use 
>> cases? (Re: Plan for moving forward)]
>>
>> Hmm, interesting choice of words.
>>
>> All I was saying was that there is a class of applications that we 
>> should be able to optimize for.  Skipping client 
>> authentication during secure tunnel establishment and using 
>> a legacy method inside the secure tunnel is a mode of 
>> operation allowed elsewhere in the IETF (e.g., TTLS, PEAP, 
>> IKEv2-EAP). 
> 
> But we don't have a legacy method to authenticate an RTP endpoint
> or an SRTP endpoint.

I was considering sending a PIN entered by the user, transmitted via RTP 
(RFC 2833), a legacy method.

> 
>> However, we seem to be not allowing that with 
>> DTLS-SRTP.  We mandate the client to authenticate using self-signed 
>> certs.  There are use cases where that client authentication has a 
>> purpose.  Elsewhere it is wasteful.  Is there "harm" due to that 
>> additional requirement?  I am saying why does one have to fight that 
>> battle in making a case to other standards organizations in adopting 
>> IETF protocols.  I can think of simple counter arguments: do what is 
>> necessary and nothing more.
> 
> That's reasonable.  But it is an optimization that saves ~600 bytes 

Ah, the luxury!  This reminds me of the time when a few of us were given 
a budget of 40 octets after some serious kicking and screaming :). 
Different context for sure.

I would be happy to save some bytes during a VoIP call setup too.

> or so?  Or are you just trying to allow one side to ignore the 
> certificate sent by the other (that is, don't verify it matches
> the associated a=fingerprint).
> 

I am also looking to save any computational expense on the client 
(mobile phone) side, contextual of course.  The client will need to 
verify the server's credentials.

> And as others have stated, it complicates things to optimize this.
> You are well aware of the risks in complicating security protocols.

Yes, but we have the expertise too, thankfully.

Anyway, I will sign-off here on this.  I am beginning to get the sense 
that we all understand the use case and its applicability.

thanks Dan,
Lakshminath

> 
>> The only argument against that I see so far is that DTLS-SRTP is the 
>> chosen protocol and the chosen protocol must not be changed.
> 
> Every requirement needs justification.
> 
> -d
> 
> 
>> regards,
>> Lakshminath
>>
>> On 6/12/2007 5:28 PM, Dan Wing wrote:
>>>> I was talking about the GETS use case.  My understanding is 
>>>> that IEPREP is considering that use case although I did not 
>>>> find a call flow to point to (I don't know for sure, could 
>>>> someone verify that?).  Perhaps others in this list may 
>>>> have ready references.
>>> IEPREP's existing work excludes cross-domain authentication and 
>>> authorization.  In any event, I don't see how GETS/IEPREP is 
>>> harmed, in any way, if the UAC is really owned by Alice Waters
>>> (chef at a good restaurant here in California) but, due to the
>>> recent earthquake, a nice gentleman from FEMA is using Alice's
>>> home phone and provides authentication to an IEPREP-capable 
>>> system (whatever it is) and gets authorization to make a 
>>> high-bandwidth multimedia call to someone in another city, at
>>> a time where mere mortals aren't able to acquire sufficient
>>> bandwidth or SIP signaling (or whatever) to make a similar
>>> call.
>>>
>>> You must believe there is some potential harm with IEPREP
>>> and the network asserting that Alice's phone was involved.
>>> I don't see the harm.  If you still feel there is harm, we'll
>>> need more details -- I don't see the harm and I don't see a 
>>> requirement that falls out of IEPREP or a GETS use case that
>>> applies to RTPSEC.
>>>
>>> -d
>>>
>>>
>>>> thanks,
>>>> Lakshminath
>>>>
>>>> On 6/12/2007 4:14 PM, Dan Wing wrote:
>>>>> The use case where someone dials a number and proves 
>> their identity
>>>>> using a PIN?  One thing you mentioned at the bottom of your first
>>>>> email http://www.imc.org/ietf-rtpsec/mail-archive/msg00751.html is
>>>>> that "priority call placement use case is similar"; however, it
>>>>> isn't -- IEPREP isn't requiring someone to connect to a remote
>>>>> gateway, prove their identity to that remote gateway, and someone
>>>>> pull that authentication and authorization 'back' into the 
>>>>> originating network.  The trouble with such an approach is how
>>>>> you'd get the access to perform that connection to that remote
>>>>> resource in order to initiate that authorization in the first
>>>>> place -- the phone system is overloaded and the more components
>>>>> of it you involve the more likely you'll find overload.
>>>>>
>>>>>> and Dan was making a case for it too earlier 
>>>>>> today.
>>>>> In my email related to directionality?  That was only an idea
>>>>> to avoid the SDP for directionality.
>>>>>
>>>>> -d
>>>>>
>>>>>  
>>>>>> regards,
>>>>>> Lakshminath
>>>>>>
>>>>>> On 6/12/2007 12:46 PM, Eric Rescorla wrote:
>>>>>>> At Tue, 12 Jun 2007 12:39:47 -0700,
>>>>>>> Lakshminath Dondeti wrote:
>>>>>>>> Right.  So, why not do it?
>>>>>>> Because it involves a number of changes in the DTLS 
>> model (having
>>>>>>> one message happen out of band, having one clienthello elicit
>>>>>>> multiple serverhellos, etc.) and nobody has described a 
>> compelling
>>>>>>> reason to do this.
>>>>>>>
>>>>>>> -Ekr
>>>>>>>
>

headers

Eric Rescorla | 13 Jun 2007 05:38

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]

At Tue, 12 Jun 2007 20:24:55 -0700,
Lakshminath Dondeti wrote:
> On 6/12/2007 7:55 PM, Dan Wing wrote:
> > That's reasonable.  But it is an optimization that saves ~600 bytes 
> 
> Ah, the luxury!  This reminds me of the time when a few of us were given 
> a budget of 40 octets after some serious kicking and screaming :). 
> Different context for sure.
>
> I would be happy to save some bytes during a VoIP call setup too.

I don't know what context you're referring to but there's an enormous
difference between per-packet overhead and one-time overhead. Any
reasonable media plane protocol is going to push >> 600 bytes over
its lifetime.

> > And as others have stated, it complicates things to optimize this.
> > You are well aware of the risks in complicating security protocols.
> 
> Yes, but we have the expertise too, thankfully.

I'm not convinced we do, actually. The implications of having only
occasional binding of the signalling to the media strike me as 
quite difficult to analyze--not least the question of how a 
reasonable implementation would know which one to do.

> Anyway, I will sign-off here on this.  I am beginning to get the sense 
> that we all understand the use case and its applicability.

Well, I don't, at least if the implication is that you don't need to
authenticate both sides. On the contrary, as I've observed several
times, even where the callee has some in-band authentication
mechanism, it's desirable to cryptographically bind the media to the
signalling.

-Ekr

headers

Lakshminath Dondeti | 13 Jun 2007 06:20

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


Someone at the IETF recently said that I don't try enough :) , so I 
guess I will continue on since you don't understand what I am trying to say.

On 6/12/2007 8:38 PM, Eric Rescorla wrote:
> At Tue, 12 Jun 2007 20:24:55 -0700,
> Lakshminath Dondeti wrote:
>> On 6/12/2007 7:55 PM, Dan Wing wrote:
>>> That's reasonable.  But it is an optimization that saves ~600 bytes 
>> Ah, the luxury!  This reminds me of the time when a few of us were given 
>> a budget of 40 octets after some serious kicking and screaming :). 
>> Different context for sure.

It looks like the 40 octet number was confusing, but I was just giving a 
real example of a budget I got for each message of a security protocol 
(unrelated to SRTP or SIP) in a wireless system.

>>
>> I would be happy to save some bytes during a VoIP call setup too.
> 
> I don't know what context you're referring to but there's an enormous
> difference between per-packet overhead and one-time overhead. Any
> reasonable media plane protocol is going to push >> 600 bytes over
> its lifetime.
> 
> 
> 
>>> And as others have stated, it complicates things to optimize this.
>>> You are well aware of the risks in complicating security protocols.
>> Yes, but we have the expertise too, thankfully.
> 
> I'm not convinced we do, actually. The implications of having only
> occasional binding of the signalling to the media strike me as 
> quite difficult to analyze--not least the question of how a 
> reasonable implementation would know which one to do.
> 
> 
>> Anyway, I will sign-off here on this.  I am beginning to get the sense 
>> that we all understand the use case and its applicability.
> 
> Well, I don't, at least if the implication is that you don't need to
> authenticate both sides. On the contrary, as I've observed several
> times, even where the callee has some in-band authentication
> mechanism, it's desirable to cryptographically bind the media to the
> signalling.

Where do these requirements that are universally applicable to all 
scenarios come from?  What if the callee (calling card gateway) does not 
care which phone the calling card user may be using?  That is a real 
scenario!

regards,
Lakshminath

> 
> -Ekr
> 
>

headers

Matt Lepinski | 14 Jun 2007 21:43

On the benefit of the a=fingerprint attribute [was Re: DTLS-SRTP harming GETS]

Lakshminath,

I think that you and EKR are talking past each other in regards to the 
benefits of the a=fingerprint attribute and the subsequent use of a 
self-signed certificate in the DTLS handshake. 

Let us consider your example of using a device to call a calling card 
gateway and then sending a PIN to authenticate the user to the gateway. 
You claim that the caller does need to use the a=fingerprint attribute 
with a self-signed certificate in this case because the gateway doesn't 
care which device (phone) the user is using. However, the point of the 
self-signed certificate is NOT to assert the identity of the calling 
device to the callee. (If you wanted to assert the identity of the 
calling device you would not use a self-signed cert, but instead a cert 
signed by a 3rd party whom the callee trusts.) The point of using the 
self-signed certificate is to bind the media to the signaling.

Let us consider what might happen (in your calling card use-case) if 
there was no a=fingerprint attribute in the SIP Invite. (Here the 
calling user is the client in the DTLS handshake.) The user sends a SIP 
Invite to the gateway. The gateway then sends a HelloRequest to the 
user. The user then attempts to send a ClientHello to the gateway. 
However, an attacker (man in the middle) intercepts the message and 
replaces it with his own ClientHello message. The gateway then sends a 
ServerHello message, which the attacker replaces with his own 
ServerHello message. The handshake continues in this manner with the 
attacker sending Server messages to the user and sending Client messages 
to the gateway. The end result is that two session keys are generated 
and both are known to the attacker. (One is shared by the user device 
and the attacker, and the other is shared by the attacker and the 
gateway). This means that when the user device starts sending media 
packets, the attacker can relay these packets to the gateway until the 
user has finished sending the PIN. Once the PIN has been relayed to the 
gateway, the attacker will drop all media packets sent by the user 
device and have a PIN-authenticated session with the calling card gateway.

In summary, without use of the a=fingerprint attribute, an attacker who 
can play "man in the middle" in the media path can hijack the user's 
session and maliciously use the user's PIN. However, if the calling 
device uses the a=fingerprint attribute along with a self-signed 
certificate, then in order to pull off such an attack, the attacker must 
be able to play "man in the middle" in both the signaling path and the 
media path. (And of course playing "man in the middle" in the signaling 
path is difficult if all signalling proxies use TLS or IPSEC to 
transport their SIP messages, and is even more difficult if SIP Identity 
to gaurantee the integrity of the SIP INVITE).

Now perhaps there are deployment scenarios where one is willing to 
accept vulnerability to the attack described above in exchange for a 
one-time savings of up to 600 bytes. (Indeed, I can imagine scenarios 
where such a man in the middle attack is difficult to pull off). My 
point is merely that there are meaningful security gaurantees that are 
provided by the a=fingerprint attribute, even in cases where the called 
party doesn't care about the identity of the calling device.

[Although my personal bias is that attacks like those described above 
are sufficient to justify the one-time use of a self-signed certificate]

- Matt Lepinski :->

Lakshminath Dondeti wrote:

>>
>> Well, I don't, at least if the implication is that you don't need to
>> authenticate both sides. On the contrary, as I've observed several
>> times, even where the callee has some in-band authentication
>> mechanism, it's desirable to cryptographically bind the media to the
>> signalling.
>
>
> Where do these requirements that are universally applicable to all 
> scenarios come from?  What if the callee (calling card gateway) does 
> not care which phone the calling card user may be using?  That is a 
> real scenario!

headers

Eric Rescorla | 13 Jun 2007 14:06

Re: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


At Tue, 12 Jun 2007 21:20:55 -0700,
Lakshminath Dondeti wrote:
> 
> Someone at the IETF recently said that I don't try enough :) , so I 
> guess I will continue on since you don't understand what I am trying to say.

Much appreciated.

> On 6/12/2007 8:38 PM, Eric Rescorla wrote:
> > At Tue, 12 Jun 2007 20:24:55 -0700,
> > Lakshminath Dondeti wrote:
> >> On 6/12/2007 7:55 PM, Dan Wing wrote:
> >>> That's reasonable.  But it is an optimization that saves ~600 bytes 
> >> Ah, the luxury!  This reminds me of the time when a few of us were given 
> >> a budget of 40 octets after some serious kicking and screaming :). 
> >> Different context for sure.
> 
> It looks like the 40 octet number was confusing, but I was just giving a 
> real example of a budget I got for each message of a security protocol 
> (unrelated to SRTP or SIP) in a wireless system.

And I was just pointing out that the analogy was likely to be inappropriate.

 
> > Well, I don't, at least if the implication is that you don't need to
> > authenticate both sides. On the contrary, as I've observed several
> > times, even where the callee has some in-band authentication
> > mechanism, it's desirable to cryptographically bind the media to the
> > signalling.
> 
> Where do these requirements that are universally applicable to all 
> scenarios come from? What if the callee (calling card gateway) does not 
> care which phone the calling card user may be using?  That is a real 
> scenario!

Yes, I've already addressed the reasons why it's still desirable to
tie the signalling to the media in this case several times.

-Ekr

headers

Dan Wing | 13 Jun 2007 07:06

RE: DTLS-SRTP harming GETS [was RE: Additional use cases? (Re: Plan for moving forward)]


> What if the callee (calling card 
> gateway) does not care which phone the calling card user may be 
> using?  That is a real scenario!

Then it could omit asking for its peer's certificate in DTLS.

-d

headers

Eric Rescorla | 13 Jun 2007 00:54

Re: Additional use cases? (Re: Plan for moving forward)

At Tue, 12 Jun 2007 15:45:52 -0700,
Lakshminath Dondeti wrote:
> Interesting ...  I wondered about the reasoning of multiple 
> serverhellos. Is the argument that multiple clienthellos are alright 
> since that amounts to lower overhead than multiple serverhellos (if the 
> expected response is HelloVerifyRequest, then the overhead might be 
> similar)? 

Huh?

Most likely the calling party does DTLS handshakes with every peer who
answers. This is true no matter who is the client or the server.

> But that seems to optimize for the forking use case and 
> ignores other use cases.

It's not an optimization. It's the basic operating mode of DTLS.

> Why is the ClientHello going out-of-band a problem?

As I said, there are two problems. The first is that it's not how
DTLS was designed to work so it makes the layering a lot more complicated.
In programming terms you need to somehow grab the ClientHello and
shove it into the SIP message. The second problem is that if it's
going in the INVITE (which it must if it's to work with early 
media) then there is the possibility of two DTLS instances 
with the same ClientHello, which is not something that DTLS
was designed to do, and so would need a new security analysis.

> As to why to do this: it seems to allow the use case I was talking about 
> and Dan was making a case for it too earlier today.

I don't really understand what use case you're talking about, but the
situation Dan is talking about can be solved perfectly well with
directional signalling in the SIP and then the entire DTLS handshake
in the media plane.

If you have some use case you think this doesn't work for, please explain
what that is.

-Ekr

headers

Lakshminath Dondeti | 13 Jun 2007 01:06

Re: Additional use cases? (Re: Plan for moving forward)


On 6/12/2007 3:54 PM, Eric Rescorla wrote:
> At Tue, 12 Jun 2007 15:45:52 -0700,
> Lakshminath Dondeti wrote:
>> Interesting ...  I wondered about the reasoning of multiple 
>> serverhellos. Is the argument that multiple clienthellos are alright 
>> since that amounts to lower overhead than multiple serverhellos (if the 
>> expected response is HelloVerifyRequest, then the overhead might be 
>> similar)? 
> 
> Huh?
> 
> Most likely the calling party does DTLS handshakes with every peer who
> answers. This is true no matter who is the client or the server.

Good, then there is no issue of overhead in comparing the two approaches.

> 
> 
>> But that seems to optimize for the forking use case and 
>> ignores other use cases.
> 
> It's not an optimization. It's the basic operating mode of DTLS.
> 
> 
>> Why is the ClientHello going out-of-band a problem?
> 
> As I said, there are two problems. The first is that it's not how
> DTLS was designed to work so it makes the layering a lot more complicated.

Well, aren't we already modifying the basic operation of TLS anyway to 
facilitate the SRTP use case?

> In programming terms you need to somehow grab the ClientHello and
> shove it into the SIP message. The second problem is that if it's
> going in the INVITE (which it must if it's to work with early 
> media) then there is the possibility of two DTLS instances 
> with the same ClientHello, which is not something that DTLS
> was designed to do, and so would need a new security analysis.

I am not sure I understand the two DTLS instances with the same ClientHello.

> 
> 
>> As to why to do this: it seems to allow the use case I was talking about 
>> and Dan was making a case for it too earlier today.
> 
> I don't really understand what use case you're talking about, but the
> situation Dan is talking about can be solved perfectly well with
> directional signalling in the SIP and then the entire DTLS handshake
> in the media plane.

Ok, perhaps I don't understand this as well, but with directional 
signaling in SIP, does the caller have to wait until a response from the 
callee comes back in the SIP layer?  How is that optimal?  What happens 
to early media considerations?

> 
> If you have some use case you think this doesn't work for, please explain
> what that is.

Sigh!  Haven't we been talking about it for a long while now?  Do I have 
to start over?

Lakshminath

> 
> -Ekr
>

headers

Eric Rescorla | 13 Jun 2007 01:19

Re: Additional use cases? (Re: Plan for moving forward)

At Tue, 12 Jun 2007 16:06:13 -0700,
Lakshminath Dondeti wrote:
> >> But that seems to optimize for the forking use case and 
> >> ignores other use cases.
> > 
> > It's not an optimization. It's the basic operating mode of DTLS.
> > 
> > 
> >> Why is the ClientHello going out-of-band a problem?
> > 
> > As I said, there are two problems. The first is that it's not how
> > DTLS was designed to work so it makes the layering a lot more complicated.
> 
> Well, aren't we already modifying the basic operation of TLS anyway to 
> facilitate the SRTP use case?

Not majorly, no. We're certainly not modifying the state machine to
the point where the caller knows which handshake message is being
sent.

> > In programming terms you need to somehow grab the ClientHello and
> > shove it into the SIP message. The second problem is that if it's
> > going in the INVITE (which it must if it's to work with early 
> > media) then there is the possibility of two DTLS instances 
> > with the same ClientHello, which is not something that DTLS
> > was designed to do, and so would need a new security analysis.
> 
> I am not sure I understand the two DTLS instances with the same ClientHello.

If you send the ClientHello in the INVITE and there is forking, then
both forks will send you a ServerHello over the media plane. If this
is pre-200, then you need to DTLS negotiate with both of them. But
they (of course) have the same ClientHello.

> >> As to why to do this: it seems to allow the use case I was talking about 
> >> and Dan was making a case for it too earlier today.
> > 
> > I don't really understand what use case you're talking about, but the
> > situation Dan is talking about can be solved perfectly well with
> > directional signalling in the SIP and then the entire DTLS handshake
> > in the media plane.
> 
> Ok, perhaps I don't understand this as well, but with directional 
> signaling in SIP, does the caller have to wait until a response from the 
> callee comes back in the SIP layer? How is that optimal?  What happens 
> to early media considerations?

If he wants to be the DTLS client, then at the moment, yes. That's
why it's desirable for him to be the server. If it's really critical
for some reason for the SDP offerer to be the DTLS client, *and*
to have it work before early media, then yes, we would need to have
the answerer send a HelloRequest (this would require a modification
to the DTLS state machine, but it's a trivial one) in order to 
elicit the ClientHello.

> > If you have some use case you think this doesn't work for, please explain
> > what that is.
> 
> Sigh!  Haven't we been talking about it for a long while now? Do I have 
> to start over?

Well, I for one have never clearly understood what you're trying to achieve.
You'll note that my response was to Dan's comment about tiebreakers.
So, yes, I guess you do have to start over.

-Ekr

headers

Francois Audet | 11 Jun 2007 18:48

RE: Additional use cases? (Re: Plan for moving forward)


Hi Hannes,

I just had a careful re-read, and it seems to me that the document DOES
cover all that is needed. It seems in really good shape.

I have a few minor comments:

- Section 1: It doesn't really jump out to the sip-centric reader what
  is the role of the fingerprint. Maybe a sentence or two summarizing
  it would be useful.

- Section 5 links the offer to sip-identity, but it doesn't cover the 
  delayed offer/answer case adequately. My suggestion would be to move
  section 6.4 into section 5 and cover standard offer/answer and 
  delayed offer/answer separately. I would like a better description
  of how sip-identity is used with delayed offer/answer (both with and
  without reliable provisional responses). I think putting more 
  details on this would alleviate some of the concerns expressed on the
  list by Lakshminath. Similarly, I'd like an example in section 7 for
  delayed offer/answer.

- Section 8.2: put a reference to draft-ietf-sip-sips-04

- References: update the following references

	- I-D.ietf-mmusic-comedia-tls -> RFC 4572
	- I-D.ietf-sip-identity -> RFC 4474
	- I-D.ietf-avt-rtp-framing-contrans -> RFC 4571
	- draft-ietf-mmusic-ice-13 -> draft-ietf-mmusic-ice-15
	- I-D.ietf-mmusic-kmgmt-ext -> RFC 4567
	- I-D.ietf-mmusic-sdescriptions -> RFC 4568
	- I-D.ietf-mmusic-sdp-comedia -> RFC 4145
	- I-D.ietf-tls-rfc2246-bis -> RFC 4346
	- draft-wing-media-security-requirements-00 ->
draft-wing-media-security-requirements-03
	- draft-ietf-avt-rtp-and-rtcp-mux-03 ->
draft-ietf-avt-rtp-and-rtcp-mux-05

  Add sips:
	http://tools.ietf.org/html/draft-ietf-sip-sips-04

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig <at> gmx.net] 
> Sent: Saturday, June 09, 2007 08:59
> To: Audet, Francois (SC100:3055)
> Cc: Eric Rescorla; Lakshminath Dondeti; Dan Wing; 
> ietf-rtpsec <at> imc.org; Sam Hartman; Tim Polk; jon.peterson <at> neustar.biz
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> Hi Francois,
> 
> 
> Francois Audet wrote:
> > I agree with Eric.
> >
> > More on the "it doesn't matter who is the caller" stuff:
> >
> > On the RFC 4474 side, RFC 4474 allows for the sender of the 
> request to 
> > provide the identity assertion. Yes, indeed, this is the calling 
> > party.
> >
> > There is no "response" identity. However, the callee may 
> send its own 
> > request in the reverse direction to provide it's own 
> identity, as per 
> > draft-ietf-sip-connected-identity-05.txt.
> >
> > In other words, in SIP also there is no implied "direction" 
> to this, 
> > even if technically, the origin of the protocol used a 
> client/server 
> > model (as in, request/response).
> >
> > I think we'll have to write up a "high level" description 
> on how these 
> > pieces fit together.
> >   
> 
> http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.tx
> t is meant 
> to provide how these pieces fit together. Do you think that there is 
> something missing that needs to be added?
> 
> Ciao
> Hannes
> 
>

headers

Dan Wing | 8 Jun 2007 02:36

RE: Additional use cases? (Re: Plan for moving forward)


...
> I think we'll have to write up a "high level" description on how these
> pieces fit together.

I believe draft-fischl-sipping-media-dtls is a good start on such a 
document (although it doesn't mention SIP-Identity), but Cullen 
did indicate Jon Peterson owns the token for that work:

    > -----Original Message-----
    > From: owner-ietf-rtpsec <at> mail.imc.org 
    > [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf 
    > Of Cullen Jennings
    > Sent: Friday, May 11, 2007 10:43 AM
    > To: ietf-rtpsec <at> imc.org
    > Subject: Plan for moving forward
    ...
    >
    >  RAI/SEC  
    >  Write overview document on how SIP UA can secure
    >  media using  combination of DTLS/SRTP, SDP Fingerprint,
    >  Identity, Outbound, and  Digest and TLS for SIP. This
    >  document will not describe new  mechanisms, it just
    >  provides the roadmap of how they all fit together.  Jon
    >  Peterson has the token to start this.
    >

-d

headers

Jason Fischl | 8 Jun 2007 03:19

Re: Additional use cases? (Re: Plan for moving forward)

Actually, draft-fischl-sipping-media-dtls does mention SIP-Identity.

e.g.

  The media is transported over a mutually authenticated DTLS session
   where both sides have certificates.  The certificate fingerprints are
   sent in SDP over SIP as part of the offer/answer exchange.  The SIP
   Identity mechanism [I-D.ietf-sip-identity] is used to provide
   integrity for the fingerprints.  It is very important to note that
   certificates are being used purely as a carrier for the public keys
   of the peers.  This is required because DTLS does not have a mode for
   carrying bare keys, but it is purely an issue of formatting.  The
   certificates can be self-signed and completely self-generated.  All
   major TLS stacks have the capability to generate such certificates on
   demand.  However, third party certificates MAY also be used for extra
   security.

On 6/7/07, Dan Wing <dwing <at> cisco.com> wrote:
>
> ...
> > I think we'll have to write up a "high level" description on how these
> > pieces fit together.
>
> I believe draft-fischl-sipping-media-dtls is a good start on such a
> document (although it doesn't mention SIP-Identity), but Cullen
> did indicate Jon Peterson owns the token for that work:
>
>     > -----Original Message-----
>     > From: owner-ietf-rtpsec <at> mail.imc.org
>     > [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf
>     > Of Cullen Jennings
>     > Sent: Friday, May 11, 2007 10:43 AM
>     > To: ietf-rtpsec <at> imc.org
>     > Subject: Plan for moving forward
>     ...
>     >
>     >  RAI/SEC
>     >  Write overview document on how SIP UA can secure
>     >  media using  combination of DTLS/SRTP, SDP Fingerprint,
>     >  Identity, Outbound, and  Digest and TLS for SIP. This
>     >  document will not describe new  mechanisms, it just
>     >  provides the roadmap of how they all fit together.  Jon
>     >  Peterson has the token to start this.
>     >
>
> -d
>
>

headers

Francois Audet | 8 Jun 2007 17:05

RE: Additional use cases? (Re: Plan for moving forward)


I think just "beefing up" this draft would be the best way to address
the problem. 

> -----Original Message-----
> From: jason.fischl <at> gmail.com [mailto:jason.fischl <at> gmail.com] 
> On Behalf Of Jason Fischl
> Sent: Thursday, June 07, 2007 18:20
> To: Dan Wing
> Cc: Audet, Francois (SC100:3055); Eric Rescorla; Lakshminath 
> Dondeti; ietf-rtpsec <at> imc.org; Sam Hartman; Tim Polk; 
> jon.peterson <at> neustar.biz; Cullen Jennings
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> Actually, draft-fischl-sipping-media-dtls does mention SIP-Identity.
> 
> e.g.
> 
>   The media is transported over a mutually authenticated DTLS session
>    where both sides have certificates.  The certificate 
> fingerprints are
>    sent in SDP over SIP as part of the offer/answer exchange.  The SIP
>    Identity mechanism [I-D.ietf-sip-identity] is used to provide
>    integrity for the fingerprints.  It is very important to note that
>    certificates are being used purely as a carrier for the public keys
>    of the peers.  This is required because DTLS does not have 
> a mode for
>    carrying bare keys, but it is purely an issue of formatting.  The
>    certificates can be self-signed and completely self-generated.  All
>    major TLS stacks have the capability to generate such 
> certificates on
>    demand.  However, third party certificates MAY also be 
> used for extra
>    security.
> 
> On 6/7/07, Dan Wing <dwing <at> cisco.com> wrote:
> >
> > ...
> > > I think we'll have to write up a "high level" description on how 
> > > these pieces fit together.
> >
> > I believe draft-fischl-sipping-media-dtls is a good start on such a 
> > document (although it doesn't mention SIP-Identity), but Cullen did 
> > indicate Jon Peterson owns the token for that work:
> >
> >     > -----Original Message-----
> >     > From: owner-ietf-rtpsec <at> mail.imc.org
> >     > [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf
> >     > Of Cullen Jennings
> >     > Sent: Friday, May 11, 2007 10:43 AM
> >     > To: ietf-rtpsec <at> imc.org
> >     > Subject: Plan for moving forward
> >     ...
> >     >
> >     >  RAI/SEC
> >     >  Write overview document on how SIP UA can secure
> >     >  media using  combination of DTLS/SRTP, SDP Fingerprint,
> >     >  Identity, Outbound, and  Digest and TLS for SIP. This
> >     >  document will not describe new  mechanisms, it just
> >     >  provides the roadmap of how they all fit together.  Jon
> >     >  Peterson has the token to start this.
> >     >
> >
> > -d
> >
> >
>

headers

Hannes Tschofenig | 9 Jun 2007 18:07

Re: Additional use cases? (Re: Plan for moving forward)


Can give us a hint what needs to be improved in 
draft-fischl-sipping-media-dtls?

I re-read this mailing list discussion again and I am not sure whether I 
could add something based on what was discussed.

Ciao
Hannes

Francois Audet wrote:
> I think just "beefing up" this draft would be the best way to address
> the problem. 
>
>   
>> -----Original Message-----
>> From: jason.fischl <at> gmail.com [mailto:jason.fischl <at> gmail.com] 
>> On Behalf Of Jason Fischl
>> Sent: Thursday, June 07, 2007 18:20
>> To: Dan Wing
>> Cc: Audet, Francois (SC100:3055); Eric Rescorla; Lakshminath 
>> Dondeti; ietf-rtpsec <at> imc.org; Sam Hartman; Tim Polk; 
>> jon.peterson <at> neustar.biz; Cullen Jennings
>> Subject: Re: Additional use cases? (Re: Plan for moving forward)
>>
>> Actually, draft-fischl-sipping-media-dtls does mention SIP-Identity.
>>
>> e.g.
>>
>>   The media is transported over a mutually authenticated DTLS session
>>    where both sides have certificates.  The certificate 
>> fingerprints are
>>    sent in SDP over SIP as part of the offer/answer exchange.  The SIP
>>    Identity mechanism [I-D.ietf-sip-identity] is used to provide
>>    integrity for the fingerprints.  It is very important to note that
>>    certificates are being used purely as a carrier for the public keys
>>    of the peers.  This is required because DTLS does not have 
>> a mode for
>>    carrying bare keys, but it is purely an issue of formatting.  The
>>    certificates can be self-signed and completely self-generated.  All
>>    major TLS stacks have the capability to generate such 
>> certificates on
>>    demand.  However, third party certificates MAY also be 
>> used for extra
>>    security.
>>
>> On 6/7/07, Dan Wing <dwing <at> cisco.com> wrote:
>>     
>>> ...
>>>       
>>>> I think we'll have to write up a "high level" description on how 
>>>> these pieces fit together.
>>>>         
>>> I believe draft-fischl-sipping-media-dtls is a good start on such a 
>>> document (although it doesn't mention SIP-Identity), but Cullen did 
>>> indicate Jon Peterson owns the token for that work:
>>>
>>>     > -----Original Message-----
>>>     > From: owner-ietf-rtpsec <at> mail.imc.org
>>>     > [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf
>>>     > Of Cullen Jennings
>>>     > Sent: Friday, May 11, 2007 10:43 AM
>>>     > To: ietf-rtpsec <at> imc.org
>>>     > Subject: Plan for moving forward
>>>     ...
>>>     >
>>>     >  RAI/SEC
>>>     >  Write overview document on how SIP UA can secure
>>>     >  media using  combination of DTLS/SRTP, SDP Fingerprint,
>>>     >  Identity, Outbound, and  Digest and TLS for SIP. This
>>>     >  document will not describe new  mechanisms, it just
>>>     >  provides the roadmap of how they all fit together.  Jon
>>>     >  Peterson has the token to start this.
>>>     >
>>>
>>> -d
>>>
>>>
>>>

headers

Lakshminath Dondeti | 8 Jun 2007 02:32

Re: Additional use cases? (Re: Plan for moving forward)


On 6/7/2007 5:11 PM, Francois Audet wrote:
> I agree with Eric.
> 
> More on the "it doesn't matter who is the caller" stuff:
> 
> On the RFC 4474 side, RFC 4474 allows for the sender of the request
> to provide the identity assertion. Yes, indeed, this is the calling
> party.

But I am saying the calling party may want the called party to 
authenticate first.

> 
> There is no "response" identity. However, the callee may send its own
> request in 
> the reverse direction to provide it's own identity, as per 
> draft-ietf-sip-connected-identity-05.txt. 
> 
> In other words, in SIP also there is no implied "direction" to this,
> even if 
> technically, the origin of the protocol used a client/server model (as
> in,
> request/response).

At the DTLS level, there is an implied direction in that client 
authentication is optional and server authentication is mandatory.

> 
> I think we'll have to write up a "high level" description on how these
> pieces
> fit together.

As I noted earlier, we can allow the use case I am talking about.  The 
most efficient option I have seen so far is to allow the caller to send 
ClientHello along with the SIP INVITE message.  We can support it 
through other options too, but those are inefficient options.

Lakshminath

> 
>> -----Original Message-----
>> From: owner-ietf-rtpsec <at> mail.imc.org 
>> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of Eric Rescorla
>> Sent: Thursday, June 07, 2007 06:28
>> To: Lakshminath Dondeti
>> Cc: Dan Wing; ietf-rtpsec <at> imc.org; 'Sam Hartman'; 'Tim Polk'; 
>> jon.peterson <at> neustar.biz
>> Subject: Re: Additional use cases? (Re: Plan for moving forward)
>>
>>
>> At Wed, 06 Jun 2007 22:41:34 -0700,
>> Lakshminath Dondeti wrote:
>>> I guess I talked about the generic case a few times, so let's start 
>>> with an example.  Consider the use case of using calling cards
>>>
>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>> (Calling card Server).
>>>
>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>> current model of DTLS-SRTP works (although it reverses the 
>>> client-server relationship).
>> Why does this reverse the client-server relationship?
>>
>> 1. DTLS-SRTP requires that both sides have certificates, but 
>> EITHER side can have a self-signed cert or a third-party 
>> cert. This is true no matter which side is client or server. 
>>
>> 2. The client-server relationship in DTLS-SRTP is actually 
>> independent of who is the caller. It's controlled by 
>> passive/active attributes in the SDP. In general, it's 
>> attractive for the answerer to be the client, purely for the 
>> performance reason that if you're not using ICE you want the 
>> ClientHello to be sent immediately to minimize RTTs.
>> [With ICE, the performance issues are more complicated and 
>> depend on which side is controlling and whether you are doing 
>> aggressive or regular nomination].
>>
>>
>>> Case 2: Alice is any SIP Phone and Uma makes a call using 
>> it.  Uma may 
>>> accept Bob's identity asserted through the SIP infrastructure, but 
>>> wants to authenticate via a secure channel established with Bob 
>>> authenticated and Uma will authenticate by sending calling card 
>>> information (username, password, or just password) as DTMF tones in 
>>> the media path.  (Note: Uma may not necessarily trust Bob's 
>> identity 
>>> asserted through the SIP
>>> infrastructure.)
>>>
>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>> the calling card information as DTMF tones in the media path.
>>>
>>> In other contexts, the terms user-identity and device-identity have 
>>> also been used.
>>>
>>> Note that priority call placement use case is similar.
>> I don't understand why you think that any of these cases 
>> presents a problem. 
>>
>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake, 
>> which are all about protecting the signalling channel and 
>> binding it to the media and then you pass the DTMF or 
>> whatever in the media. This works fine.
>>
>> -Ekr
>>
>>
>>
>

headers

Francois Audet | 8 Jun 2007 17:05

RE: Additional use cases? (Re: Plan for moving forward)


> At the DTLS level, there is an implied direction in that 
> client authentication is optional and server authentication 
> is mandatory.

This is not DTLS. It is derived from DTLS, but it's not DTLS.
It's mandatory on both sides in this case to exchange keys.

headers

Lakshminath Dondeti | 8 Jun 2007 17:22

Re: Additional use cases? (Re: Plan for moving forward)


On 6/8/2007 8:05 AM, Francois Audet wrote:
>  
>> At the DTLS level, there is an implied direction in that 
>> client authentication is optional and server authentication 
>> is mandatory.
> 
> This is not DTLS. It is derived from DTLS, but it's not DTLS.
> It's mandatory on both sides in this case to exchange keys.
> 
Perhaps I missed this requirement when reading the requirements draft. 
I will check.

regards,
Lakshminath

headers

Lakshminath Dondeti | 7 Jun 2007 19:23

Re: Additional use cases? (Re: Plan for moving forward)


Actually the use cases probably won't be a big problem.  If the 
ClientHello can be sent by the caller via the signaling path, both 
cases, the caller being the client or the server can be addressed. 
Nothing else needs to change, AFAICT.

thanks,
Lakshminath

On 6/7/2007 6:28 AM, Eric Rescorla wrote:
> At Wed, 06 Jun 2007 22:41:34 -0700,
> Lakshminath Dondeti wrote:
>> I guess I talked about the generic case a few times, so let's start with 
>> an example.  Consider the use case of using calling cards
>>
>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>> (Calling card Server).
>>
>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>> current model of DTLS-SRTP works (although it reverses the client-server 
>> relationship).
> 
> Why does this reverse the client-server relationship?
> 
> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
> side can have a self-signed cert or a third-party cert. This is true
> no matter which side is client or server. 
> 
> 2. The client-server relationship in DTLS-SRTP is actually independent
> of who is the caller. It's controlled by passive/active attributes
> in the SDP. In general, it's attractive for the answerer to be the
> client, purely for the performance reason that if you're not using
> ICE you want the ClientHello to be sent immediately to minimize RTTs.
> [With ICE, the performance issues are more complicated and depend
> on which side is controlling and whether you are doing aggressive
> or regular nomination].
> 
> 
>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma may 
>> accept Bob's identity asserted through the SIP infrastructure, but wants 
>> to authenticate via a secure channel established with Bob authenticated 
>> and Uma will authenticate by sending calling card information (username, 
>> password, or just password) as DTMF tones in the media path.  (Note: Uma 
>> may not necessarily trust Bob's identity asserted through the SIP 
>> infrastructure.)
>>
>> Case 3: Bob's identity is asserted in the media path and Uma enters the 
>> calling card information as DTMF tones in the media path.
>>
>> In other contexts, the terms user-identity and device-identity have also 
>> been used.
>>
>> Note that priority call placement use case is similar.
> 
> I don't understand why you think that any of these cases presents
> a problem. 
> 
> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
> which are all about protecting the signalling channel and binding
> it to the media and then you pass the DTMF or whatever in the
> media. This works fine.
> 
> -Ekr
> 
> 
>

headers

Richard Barnes | 7 Jun 2007 20:48

Re: Additional use cases? (Re: Plan for moving forward)


To re-frame my earlier response in light of RFC 4572, the negotiation of 
roles does happen in the signaling path, but in the SDP not via a 
ClientHello:
a=setup:active	- caller is client
a=setup:passive	- caller is server
a=setup:actpass	- caller doesn't care
If the caller doesn't care, the callee MUST pick active or passive.

Anyway, the point is that the client/server roles are independent of the 
caller/callee roles.

--Richard

Lakshminath Dondeti wrote:
> 
> Actually the use cases probably won't be a big problem.  If the 
> ClientHello can be sent by the caller via the signaling path, both 
> cases, the caller being the client or the server can be addressed. 
> Nothing else needs to change, AFAICT.
> 
> thanks,
> Lakshminath
> 
> On 6/7/2007 6:28 AM, Eric Rescorla wrote:
>> At Wed, 06 Jun 2007 22:41:34 -0700,
>> Lakshminath Dondeti wrote:
>>> I guess I talked about the generic case a few times, so let's start 
>>> with an example.  Consider the use case of using calling cards
>>>
>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>> (Calling card Server).
>>>
>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>> current model of DTLS-SRTP works (although it reverses the 
>>> client-server relationship).
>>
>> Why does this reverse the client-server relationship?
>>
>> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
>> side can have a self-signed cert or a third-party cert. This is true
>> no matter which side is client or server.
>> 2. The client-server relationship in DTLS-SRTP is actually independent
>> of who is the caller. It's controlled by passive/active attributes
>> in the SDP. In general, it's attractive for the answerer to be the
>> client, purely for the performance reason that if you're not using
>> ICE you want the ClientHello to be sent immediately to minimize RTTs.
>> [With ICE, the performance issues are more complicated and depend
>> on which side is controlling and whether you are doing aggressive
>> or regular nomination].
>>
>>
>>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma 
>>> may accept Bob's identity asserted through the SIP infrastructure, 
>>> but wants to authenticate via a secure channel established with Bob 
>>> authenticated and Uma will authenticate by sending calling card 
>>> information (username, password, or just password) as DTMF tones in 
>>> the media path.  (Note: Uma may not necessarily trust Bob's identity 
>>> asserted through the SIP infrastructure.)
>>>
>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>> the calling card information as DTMF tones in the media path.
>>>
>>> In other contexts, the terms user-identity and device-identity have 
>>> also been used.
>>>
>>> Note that priority call placement use case is similar.
>>
>> I don't understand why you think that any of these cases presents
>> a problem.
>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
>> which are all about protecting the signalling channel and binding
>> it to the media and then you pass the DTMF or whatever in the
>> media. This works fine.
>>
>> -Ekr
>>
>>
>>
> 
>

headers

Lakshminath Dondeti | 7 Jun 2007 22:24

Re: Additional use cases? (Re: Plan for moving forward)


For my clarification, if the caller is client (a=setup:active in 4145 
terminology), does it have to wait until 200 OK arrives to start DTLS? 
If so, that doesn't sound like a useful option.

regards,
Lakshminath

On 6/7/2007 11:48 AM, Richard Barnes wrote:
> To re-frame my earlier response in light of RFC 4572, the negotiation of 
> roles does happen in the signaling path, but in the SDP not via a 
> ClientHello:
> a=setup:active    - caller is client
> a=setup:passive    - caller is server
> a=setup:actpass    - caller doesn't care
> If the caller doesn't care, the callee MUST pick active or passive.
> 
> Anyway, the point is that the client/server roles are independent of the 
> caller/callee roles.
> 
> --Richard
> 
> 
> 
> Lakshminath Dondeti wrote:
>>
>> Actually the use cases probably won't be a big problem.  If the 
>> ClientHello can be sent by the caller via the signaling path, both 
>> cases, the caller being the client or the server can be addressed. 
>> Nothing else needs to change, AFAICT.
>>
>> thanks,
>> Lakshminath
>>
>> On 6/7/2007 6:28 AM, Eric Rescorla wrote:
>>> At Wed, 06 Jun 2007 22:41:34 -0700,
>>> Lakshminath Dondeti wrote:
>>>> I guess I talked about the generic case a few times, so let's start 
>>>> with an example.  Consider the use case of using calling cards
>>>>
>>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>>> (Calling card Server).
>>>>
>>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>>> current model of DTLS-SRTP works (although it reverses the 
>>>> client-server relationship).
>>>
>>> Why does this reverse the client-server relationship?
>>>
>>> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
>>> side can have a self-signed cert or a third-party cert. This is true
>>> no matter which side is client or server.
>>> 2. The client-server relationship in DTLS-SRTP is actually independent
>>> of who is the caller. It's controlled by passive/active attributes
>>> in the SDP. In general, it's attractive for the answerer to be the
>>> client, purely for the performance reason that if you're not using
>>> ICE you want the ClientHello to be sent immediately to minimize RTTs.
>>> [With ICE, the performance issues are more complicated and depend
>>> on which side is controlling and whether you are doing aggressive
>>> or regular nomination].
>>>
>>>
>>>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma 
>>>> may accept Bob's identity asserted through the SIP infrastructure, 
>>>> but wants to authenticate via a secure channel established with Bob 
>>>> authenticated and Uma will authenticate by sending calling card 
>>>> information (username, password, or just password) as DTMF tones in 
>>>> the media path.  (Note: Uma may not necessarily trust Bob's identity 
>>>> asserted through the SIP infrastructure.)
>>>>
>>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>>> the calling card information as DTMF tones in the media path.
>>>>
>>>> In other contexts, the terms user-identity and device-identity have 
>>>> also been used.
>>>>
>>>> Note that priority call placement use case is similar.
>>>
>>> I don't understand why you think that any of these cases presents
>>> a problem.
>>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
>>> which are all about protecting the signalling channel and binding
>>> it to the media and then you pass the DTMF or whatever in the
>>> media. This works fine.
>>>
>>> -Ekr
>>>
>>>
>>>
>>
>>
> 
>

headers

Richard Barnes | 7 Jun 2007 19:36

Re: Additional use cases? (Re: Plan for moving forward)


There's no need to send anything through the signaling path in either 
case -- the roles are decided through media-path DTLS messages.  If one 
caller (or callee) wants to be a client, he sends a ClientHello, 
otherwise he can send a HelloRequest.

--Richard

Lakshminath Dondeti wrote:
> 
> Actually the use cases probably won't be a big problem.  If the 
> ClientHello can be sent by the caller via the signaling path, both 
> cases, the caller being the client or the server can be addressed. 
> Nothing else needs to change, AFAICT.
> 
> thanks,
> Lakshminath
> 
> On 6/7/2007 6:28 AM, Eric Rescorla wrote:
>> At Wed, 06 Jun 2007 22:41:34 -0700,
>> Lakshminath Dondeti wrote:
>>> I guess I talked about the generic case a few times, so let's start 
>>> with an example.  Consider the use case of using calling cards
>>>
>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>> (Calling card Server).
>>>
>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>> current model of DTLS-SRTP works (although it reverses the 
>>> client-server relationship).
>>
>> Why does this reverse the client-server relationship?
>>
>> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
>> side can have a self-signed cert or a third-party cert. This is true
>> no matter which side is client or server.
>> 2. The client-server relationship in DTLS-SRTP is actually independent
>> of who is the caller. It's controlled by passive/active attributes
>> in the SDP. In general, it's attractive for the answerer to be the
>> client, purely for the performance reason that if you're not using
>> ICE you want the ClientHello to be sent immediately to minimize RTTs.
>> [With ICE, the performance issues are more complicated and depend
>> on which side is controlling and whether you are doing aggressive
>> or regular nomination].
>>
>>
>>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma 
>>> may accept Bob's identity asserted through the SIP infrastructure, 
>>> but wants to authenticate via a secure channel established with Bob 
>>> authenticated and Uma will authenticate by sending calling card 
>>> information (username, password, or just password) as DTMF tones in 
>>> the media path.  (Note: Uma may not necessarily trust Bob's identity 
>>> asserted through the SIP infrastructure.)
>>>
>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>> the calling card information as DTMF tones in the media path.
>>>
>>> In other contexts, the terms user-identity and device-identity have 
>>> also been used.
>>>
>>> Note that priority call placement use case is similar.
>>
>> I don't understand why you think that any of these cases presents
>> a problem.
>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
>> which are all about protecting the signalling channel and binding
>> it to the media and then you pass the DTMF or whatever in the
>> media. This works fine.
>>
>> -Ekr
>>
>>
>>
> 
>

headers

Lakshminath Dondeti | 7 Jun 2007 20:13

Re: Additional use cases? (Re: Plan for moving forward)


Isn't HelloRequest adding one more message to call setup?

Lakshminath

On 6/7/2007 10:36 AM, Richard Barnes wrote:
> 
> There's no need to send anything through the signaling path in either 
> case -- the roles are decided through media-path DTLS messages.  If one 
> caller (or callee) wants to be a client, he sends a ClientHello, 
> otherwise he can send a HelloRequest.
> 
> --Richard
> 
> 
> 
> Lakshminath Dondeti wrote:
>>
>> Actually the use cases probably won't be a big problem.  If the 
>> ClientHello can be sent by the caller via the signaling path, both 
>> cases, the caller being the client or the server can be addressed. 
>> Nothing else needs to change, AFAICT.
>>
>> thanks,
>> Lakshminath
>>
>> On 6/7/2007 6:28 AM, Eric Rescorla wrote:
>>> At Wed, 06 Jun 2007 22:41:34 -0700,
>>> Lakshminath Dondeti wrote:
>>>> I guess I talked about the generic case a few times, so let's start 
>>>> with an example.  Consider the use case of using calling cards
>>>>
>>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>>> (Calling card Server).
>>>>
>>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>>> current model of DTLS-SRTP works (although it reverses the 
>>>> client-server relationship).
>>>
>>> Why does this reverse the client-server relationship?
>>>
>>> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
>>> side can have a self-signed cert or a third-party cert. This is true
>>> no matter which side is client or server.
>>> 2. The client-server relationship in DTLS-SRTP is actually independent
>>> of who is the caller. It's controlled by passive/active attributes
>>> in the SDP. In general, it's attractive for the answerer to be the
>>> client, purely for the performance reason that if you're not using
>>> ICE you want the ClientHello to be sent immediately to minimize RTTs.
>>> [With ICE, the performance issues are more complicated and depend
>>> on which side is controlling and whether you are doing aggressive
>>> or regular nomination].
>>>
>>>
>>>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma 
>>>> may accept Bob's identity asserted through the SIP infrastructure, 
>>>> but wants to authenticate via a secure channel established with Bob 
>>>> authenticated and Uma will authenticate by sending calling card 
>>>> information (username, password, or just password) as DTMF tones in 
>>>> the media path.  (Note: Uma may not necessarily trust Bob's identity 
>>>> asserted through the SIP infrastructure.)
>>>>
>>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>>> the calling card information as DTMF tones in the media path.
>>>>
>>>> In other contexts, the terms user-identity and device-identity have 
>>>> also been used.
>>>>
>>>> Note that priority call placement use case is similar.
>>>
>>> I don't understand why you think that any of these cases presents
>>> a problem.
>>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
>>> which are all about protecting the signalling channel and binding
>>> it to the media and then you pass the DTMF or whatever in the
>>> media. This works fine.
>>>
>>> -Ekr
>>>
>>>
>>>
>>
>>
> 
>

headers

Richard Barnes | 7 Jun 2007 20:23

Re: Additional use cases? (Re: Plan for moving forward)


Technically, yes; a small, fast (media-path) message.  And if an 
endpoint doesn't want to be a client, it doesn't really need to send a 
HelloRequest, it can just not send a ClientHello (and wait for the other 
end to do so).

Speaking more broadly, there should be a standard way for the endpoints 
to figure out who plays which role.  I'm not sure if this is addressed 
in the current DTLS-SRTP documents (it seems not after a brief scan).

--Richard

Lakshminath Dondeti wrote:
> 
> Isn't HelloRequest adding one more message to call setup?
> 
> Lakshminath
> 
> On 6/7/2007 10:36 AM, Richard Barnes wrote:
>>
>> There's no need to send anything through the signaling path in either 
>> case -- the roles are decided through media-path DTLS messages.  If 
>> one caller (or callee) wants to be a client, he sends a ClientHello, 
>> otherwise he can send a HelloRequest.
>>
>> --Richard
>>
>>
>>
>> Lakshminath Dondeti wrote:
>>>
>>> Actually the use cases probably won't be a big problem.  If the 
>>> ClientHello can be sent by the caller via the signaling path, both 
>>> cases, the caller being the client or the server can be addressed. 
>>> Nothing else needs to change, AFAICT.
>>>
>>> thanks,
>>> Lakshminath
>>>
>>> On 6/7/2007 6:28 AM, Eric Rescorla wrote:
>>>> At Wed, 06 Jun 2007 22:41:34 -0700,
>>>> Lakshminath Dondeti wrote:
>>>>> I guess I talked about the generic case a few times, so let's start 
>>>>> with an example.  Consider the use case of using calling cards
>>>>>
>>>>> Alice is a SIP Phone, and Uma wants to use it to make a call to Bob 
>>>>> (Calling card Server).
>>>>>
>>>>> Case 1: Uma registers Alice as an authorized phone with Bob.  The 
>>>>> current model of DTLS-SRTP works (although it reverses the 
>>>>> client-server relationship).
>>>>
>>>> Why does this reverse the client-server relationship?
>>>>
>>>> 1. DTLS-SRTP requires that both sides have certificates, but EITHER
>>>> side can have a self-signed cert or a third-party cert. This is true
>>>> no matter which side is client or server.
>>>> 2. The client-server relationship in DTLS-SRTP is actually independent
>>>> of who is the caller. It's controlled by passive/active attributes
>>>> in the SDP. In general, it's attractive for the answerer to be the
>>>> client, purely for the performance reason that if you're not using
>>>> ICE you want the ClientHello to be sent immediately to minimize RTTs.
>>>> [With ICE, the performance issues are more complicated and depend
>>>> on which side is controlling and whether you are doing aggressive
>>>> or regular nomination].
>>>>
>>>>
>>>>> Case 2: Alice is any SIP Phone and Uma makes a call using it.  Uma 
>>>>> may accept Bob's identity asserted through the SIP infrastructure, 
>>>>> but wants to authenticate via a secure channel established with Bob 
>>>>> authenticated and Uma will authenticate by sending calling card 
>>>>> information (username, password, or just password) as DTMF tones in 
>>>>> the media path.  (Note: Uma may not necessarily trust Bob's 
>>>>> identity asserted through the SIP infrastructure.)
>>>>>
>>>>> Case 3: Bob's identity is asserted in the media path and Uma enters 
>>>>> the calling card information as DTMF tones in the media path.
>>>>>
>>>>> In other contexts, the terms user-identity and device-identity have 
>>>>> also been used.
>>>>>
>>>>> Note that priority call placement use case is similar.
>>>>
>>>> I don't understand why you think that any of these cases presents
>>>> a problem.
>>>> You just do the ordinary SIP-Identity + DTLS-SRTP handshake,
>>>> which are all about protecting the signalling channel and binding
>>>> it to the media and then you pass the DTMF or whatever in the
>>>> media. This works fine.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>

headers

Eric Rescorla | 7 Jun 2007 20:28

Re: Additional use cases? (Re: Plan for moving forward)


At Thu, 07 Jun 2007 14:23:29 -0400,
Richard Barnes wrote:
> 
> Technically, yes; a small, fast (media-path) message.  And if an 
> endpoint doesn't want to be a client, it doesn't really need to send a 
> HelloRequest, it can just not send a ClientHello (and wait for the other 
> end to do so).
> 
> Speaking more broadly, there should be a standard way for the endpoints 
> to figure out who plays which role.  I'm not sure if this is addressed 
> in the current DTLS-SRTP documents (it seems not after a brief scan).

It's defined in RFC 4572.

-Ekr

headers

Sam Hartman | 5 Jun 2007 13:23

Re: Plan for moving forward


Another thing to consider is that rtpsec is only one model of how the
technology we're developing can be used today.  In the future, if
there is interest, we may specify how you can interoperably use certs
in a PKI to get authentication of the media even if you don't have
authentication of the signaling path.

Yes, that looks easy.  However it's more complicated than it first
appears.  My preference is that we develop one mandatory to implement
architecture for the use case we've been discussing today.  We do
future work in the future.

If you want to build a future where you can use something other than
certs in TLS for one of the authentication directions then work with
the TLS community to build that support into TLS.

headers

Lakshminath Dondeti | 7 Jun 2007 08:16

Re: Plan for moving forward

Sam,

Thanks for your note.  One of the successful models with certs and PKI 
we have is the https model.  The use case I am putting forth works along 
those lines.  The caller is the client and the callee is the server; the 
server, e.g., a calling card server or a priority call processing 
server, authenticates itself first; the client authentication is 
optional as DTLS allows and within the secure tunnel the caller sends 
DTMF tones as RTP packets to enter the calling card information or 
priority codes.

That use case came up in a discussion recently.  It is not "future work" 
in my opinion.  It is also not dramatically different from what we have 
been discussing either.

regards,
Lakshminath

On 6/5/2007 4:23 AM, Sam Hartman wrote:
> Another thing to consider is that rtpsec is only one model of how the
> technology we're developing can be used today.  In the future, if
> there is interest, we may specify how you can interoperably use certs
> in a PKI to get authentication of the media even if you don't have
> authentication of the signaling path.
> 
> Yes, that looks easy.  However it's more complicated than it first
> appears.  My preference is that we develop one mandatory to implement
> architecture for the use case we've been discussing today.  We do
> future work in the future.
> 
> If you want to build a future where you can use something other than
> certs in TLS for one of the authentication directions then work with
> the TLS community to build that support into TLS.
> 
>

headers

Cullen Jennings | 7 Jun 2007 16:51

Re: Plan for moving forward


As far as I understand this case, it is covered with in a current  
requirements and solutions. This type of  use case is typically  
considered a subset of the conferencing use case which received  
considerable attention.

On Jun 6, 2007, at 11:16 PM, Lakshminath Dondeti wrote:

> Sam,
>
> Thanks for your note.  One of the successful models with certs and  
> PKI we have is the https model.  The use case I am putting forth  
> works along those lines.  The caller is the client and the callee  
> is the server; the server, e.g., a calling card server or a  
> priority call processing server, authenticates itself first; the  
> client authentication is optional as DTLS allows and within the  
> secure tunnel the caller sends DTMF tones as RTP packets to enter  
> the calling card information or priority codes.
>
> That use case came up in a discussion recently.  It is not "future  
> work" in my opinion.  It is also not dramatically different from  
> what we have been discussing either.
>
> regards,
> Lakshminath
>
> On 6/5/2007 4:23 AM, Sam Hartman wrote:
>> Another thing to consider is that rtpsec is only one model of how the
>> technology we're developing can be used today.  In the future, if
>> there is interest, we may specify how you can interoperably use certs
>> in a PKI to get authentication of the media even if you don't have
>> authentication of the signaling path.
>> Yes, that looks easy.  However it's more complicated than it first
>> appears.  My preference is that we develop one mandatory to implement
>> architecture for the use case we've been discussing today.  We do
>> future work in the future.
>> If you want to build a future where you can use something other than
>> certs in TLS for one of the authentication directions then work with
>> the TLS community to build that support into TLS.

headers

Eric Rescorla | 7 Jun 2007 15:10

Re: Plan for moving forward

At Wed, 06 Jun 2007 23:16:58 -0700,
Lakshminath Dondeti wrote:
> Thanks for your note.  One of the successful models with certs and PKI 
> we have is the https model.  The use case I am putting forth works along 
> those lines.  The caller is the client and the callee is the server; the 
> server, e.g., a calling card server or a priority call processing 
> server, authenticates itself first; the client authentication is 
> optional as DTLS allows and within the secure tunnel the caller sends 
> DTMF tones as RTP packets to enter the calling card information or 
> priority codes.
> 
> That use case came up in a discussion recently.  It is not "future work" 
> in my opinion.  It is also not dramatically different from what we have 
> been discussing either.

It's also totally compatible with DTLS-SRTP as-is.

Remember, the DTLS client and serve authentication here are for
the purposes of binding the DTLS handshake to SIP not necessarily
for the purposes of binding the DTLS-SRTP to an identity. So,
in this case, what would happen is that both parties would
DTLS authenticate with their self-signed certs. Optionally,
callee could use their third-party cert instead. Once the media
stream is established the client enters DTMF over the secure media
stream.

Note that this works no matter which side takes on the DTLS client/server
role, which, btw, is an issue totally orthogonal to who is the callee
or caller.

-Ekr

headers

Lakshminath Dondeti | 7 Jun 2007 19:21

Re: Plan for moving forward


Eric,

I definitely understand the mode of operation you are talking about, but 
the point is that the caller has to authenticate twice, first with a 
self-signed cert and then later using DTMF digits.  In some cases, the 
first authentication has no real purpose, so why can't we skip it? 
That's what I am getting at.

regards,
Lakshminath

On 6/7/2007 6:10 AM, Eric Rescorla wrote:
> At Wed, 06 Jun 2007 23:16:58 -0700,
> Lakshminath Dondeti wrote:
>> Thanks for your note.  One of the successful models with certs and PKI 
>> we have is the https model.  The use case I am putting forth works along 
>> those lines.  The caller is the client and the callee is the server; the 
>> server, e.g., a calling card server or a priority call processing 
>> server, authenticates itself first; the client authentication is 
>> optional as DTLS allows and within the secure tunnel the caller sends 
>> DTMF tones as RTP packets to enter the calling card information or 
>> priority codes.
>>
>> That use case came up in a discussion recently.  It is not "future work" 
>> in my opinion.  It is also not dramatically different from what we have 
>> been discussing either.
> 
> It's also totally compatible with DTLS-SRTP as-is.
> 
> Remember, the DTLS client and serve authentication here are for
> the purposes of binding the DTLS handshake to SIP not necessarily
> for the purposes of binding the DTLS-SRTP to an identity. So,
> in this case, what would happen is that both parties would
> DTLS authenticate with their self-signed certs. Optionally,
> callee could use their third-party cert instead. Once the media
> stream is established the client enters DTMF over the secure media
> stream.
> 
> Note that this works no matter which side takes on the DTLS client/server
> role, which, btw, is an issue totally orthogonal to who is the callee
> or caller.
> 
> -Ekr
> 
> 
> 
>

headers

Eric Rescorla | 7 Jun 2007 20:02

Re: Plan for moving forward

At Thu, 07 Jun 2007 10:21:14 -0700,
Lakshminath Dondeti wrote:
> I definitely understand the mode of operation you are talking about, but 
> the point is that the caller has to authenticate twice, first with a 
> self-signed cert and then later using DTMF digits.  In some cases, the 
> first authentication has no real purpose, so why can't we skip it? 
> That's what I am getting at.

It does have a purpose: it ties the signalling to the media so
that (for instance) ANI works properly.

Moreover, what's the purpose of skipping it? As far as I can tell
it just saves a signature...

-Ekr

headers

Lakshminath Dondeti | 7 Jun 2007 20:22

Re: Plan for moving forward


That was one savings I was looking for.  Where it is unnecessary, 
battery-powered devices might want to skip it.  Once there is 
flexibility, we can think of other optimizations too.

thanks,
Lakshminath

On 6/7/2007 11:02 AM, Eric Rescorla wrote:
> At Thu, 07 Jun 2007 10:21:14 -0700,
> Lakshminath Dondeti wrote:
>> I definitely understand the mode of operation you are talking about, but 
>> the point is that the caller has to authenticate twice, first with a 
>> self-signed cert and then later using DTMF digits.  In some cases, the 
>> first authentication has no real purpose, so why can't we skip it? 
>> That's what I am getting at.
> 
> It does have a purpose: it ties the signalling to the media so
> that (for instance) ANI works properly.
> 
> Moreover, what's the purpose of skipping it? As far as I can tell
> it just saves a signature...
> 
> -Ekr
> 	
>

headers

Eric Rescorla | 7 Jun 2007 21:05

Re: Plan for moving forward

At Thu, 07 Jun 2007 11:22:21 -0700,
Lakshminath Dondeti wrote:
> That was one savings I was looking for.  Where it is unnecessary, 
> battery-powered devices might want to skip it.  Once there is 
> flexibility, we can think of other optimizations too.

This strikes me as an extraordinatrily modest optimization
and one that will add considerable UI and implementation
complexity, since it's nearly impossible for the user to
know whether their handset should be authenticating or not.

-Ekr

headers

Richard Barnes | 7 Jun 2007 19:40

Re: Plan for moving forward


Lakshminath,

The first authentication does have a purpose. It authenticates that DTLS 
endpoint is the same as the signaling endpoint by providing a 
certificate that matches the a=fingerprint attribute in the signaling. 
That cert could be self-signed or signed by a third party, but the 
binding works becuase the same cert was used in the a=fingerprint and in 
the DTLS exchange.

--Richard

Lakshminath Dondeti wrote:
> 
> Eric,
> 
> I definitely understand the mode of operation you are talking about, but 
> the point is that the caller has to authenticate twice, first with a 
> self-signed cert and then later using DTMF digits.  In some cases, the 
> first authentication has no real purpose, so why can't we skip it? 
> That's what I am getting at.
> 
> regards,
> Lakshminath
> 
> On 6/7/2007 6:10 AM, Eric Rescorla wrote:
>> At Wed, 06 Jun 2007 23:16:58 -0700,
>> Lakshminath Dondeti wrote:
>>> Thanks for your note.  One of the successful models with certs and 
>>> PKI we have is the https model.  The use case I am putting forth 
>>> works along those lines.  The caller is the client and the callee is 
>>> the server; the server, e.g., a calling card server or a priority 
>>> call processing server, authenticates itself first; the client 
>>> authentication is optional as DTLS allows and within the secure 
>>> tunnel the caller sends DTMF tones as RTP packets to enter the 
>>> calling card information or priority codes.
>>>
>>> That use case came up in a discussion recently.  It is not "future 
>>> work" in my opinion.  It is also not dramatically different from what 
>>> we have been discussing either.
>>
>> It's also totally compatible with DTLS-SRTP as-is.
>>
>> Remember, the DTLS client and serve authentication here are for
>> the purposes of binding the DTLS handshake to SIP not necessarily
>> for the purposes of binding the DTLS-SRTP to an identity. So,
>> in this case, what would happen is that both parties would
>> DTLS authenticate with their self-signed certs. Optionally,
>> callee could use their third-party cert instead. Once the media
>> stream is established the client enters DTMF over the secure media
>> stream.
>>
>> Note that this works no matter which side takes on the DTLS client/server
>> role, which, btw, is an issue totally orthogonal to who is the callee
>> or caller.
>>
>> -Ekr
>>
>>
>>
>>
> 
>

headers

Lakshminath Dondeti | 7 Jun 2007 19:52

Re: Plan for moving forward


I agree that it has a purpose when it is necessary to identify the 
device, but I am making the case that identifying the device is not 
necessary in all cases.

regards,
Lakshminath

On 6/7/2007 10:40 AM, Richard Barnes wrote:
> Lakshminath,
> 
> The first authentication does have a purpose. It authenticates that DTLS 
> endpoint is the same as the signaling endpoint by providing a 
> certificate that matches the a=fingerprint attribute in the signaling. 
> That cert could be self-signed or signed by a third party, but the 
> binding works becuase the same cert was used in the a=fingerprint and in 
> the DTLS exchange.
> 
> --Richard
> 
> 
> 
> Lakshminath Dondeti wrote:
>>
>> Eric,
>>
>> I definitely understand the mode of operation you are talking about, 
>> but the point is that the caller has to authenticate twice, first with 
>> a self-signed cert and then later using DTMF digits.  In some cases, 
>> the first authentication has no real purpose, so why can't we skip it? 
>> That's what I am getting at.
>>
>> regards,
>> Lakshminath
>>
>> On 6/7/2007 6:10 AM, Eric Rescorla wrote:
>>> At Wed, 06 Jun 2007 23:16:58 -0700,
>>> Lakshminath Dondeti wrote:
>>>> Thanks for your note.  One of the successful models with certs and 
>>>> PKI we have is the https model.  The use case I am putting forth 
>>>> works along those lines.  The caller is the client and the callee is 
>>>> the server; the server, e.g., a calling card server or a priority 
>>>> call processing server, authenticates itself first; the client 
>>>> authentication is optional as DTLS allows and within the secure 
>>>> tunnel the caller sends DTMF tones as RTP packets to enter the 
>>>> calling card information or priority codes.
>>>>
>>>> That use case came up in a discussion recently.  It is not "future 
>>>> work" in my opinion.  It is also not dramatically different from 
>>>> what we have been discussing either.
>>>
>>> It's also totally compatible with DTLS-SRTP as-is.
>>>
>>> Remember, the DTLS client and serve authentication here are for
>>> the purposes of binding the DTLS handshake to SIP not necessarily
>>> for the purposes of binding the DTLS-SRTP to an identity. So,
>>> in this case, what would happen is that both parties would
>>> DTLS authenticate with their self-signed certs. Optionally,
>>> callee could use their third-party cert instead. Once the media
>>> stream is established the client enters DTMF over the secure media
>>> stream.
>>>
>>> Note that this works no matter which side takes on the DTLS 
>>> client/server
>>> role, which, btw, is an issue totally orthogonal to who is the callee
>>> or caller.
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>
>>
> 
>

headers

Francois Audet | 8 Jun 2007 02:12

RE: Plan for moving forward


It does not identify the device, but the user. 

> -----Original Message-----
> From: owner-ietf-rtpsec <at> mail.imc.org 
> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
> Lakshminath Dondeti
> Sent: Thursday, June 07, 2007 10:53
> To: Richard Barnes
> Cc: Eric Rescorla; Sam Hartman; Dan Wing; 'Cullen Jennings'; 
> ietf-rtpsec <at> imc.org; 'Tim Polk'; jon.peterson <at> neustar.biz
> Subject: Re: Plan for moving forward
> 
> 
> I agree that it has a purpose when it is necessary to 
> identify the device, but I am making the case that 
> identifying the device is not necessary in all cases.

headers

Matt Lepinski | 7 Jun 2007 20:09

Re: Plan for moving forward


Lakshminath,

If I understand correctly, you're saying that there are use cases where 
the UAS does not care whether the entity with whom he's conducting a 
DTLS exchange is the same entity who sent the SIP INVITE. (Because the 
UAS knows that immediately following the DTLS exchange, the UAS will 
authenticate using "legacy methods").

I do not know how common such use cases are.

My question is: In such use cases, is it really too much of a burden to 
ask the UAC to generate a self-signed cert to use in the a=fingerprint 
attribute and the DTLS exchange? That is, perhaps there are use cases 
where the security guarantees provided by tying the signaling to the 
DTLS exchange are not needed. However, to avoid adding an additional 
special case to the specifications that we will produce, perhaps it is 
reasonable to ask the UAC to generate a self-signed cert for use in the 
a=fingerprint attribute (and subsequent DTLS exchange)?

My bias is that unless the use-cases in question are quite common, and 
the computational burden is excessive, it is better to provide the 
additional security guarantees in all cases (even if in some cases the 
guarantees are strictly necessary).

- Matt Lepinski :->

Lakshminath Dondeti wrote:

>
> I agree that it has a purpose when it is necessary to identify the 
> device, but I am making the case that identifying the device is not 
> necessary in all cases.
>
> regards,
> Lakshminath
>
> On 6/7/2007 10:40 AM, Richard Barnes wrote:
>
>> Lakshminath,
>>
>> The first authentication does have a purpose. It authenticates that 
>> DTLS endpoint is the same as the signaling endpoint by providing a 
>> certificate that matches the a=fingerprint attribute in the 
>> signaling. That cert could be self-signed or signed by a third party, 
>> but the binding works becuase the same cert was used in the 
>> a=fingerprint and in the DTLS exchange.
>>
>> --Richard
>>
>>
>>
>> Lakshminath Dondeti wrote:
>>
>>>
>>> Eric,
>>>
>>> I definitely understand the mode of operation you are talking about, 
>>> but the point is that the caller has to authenticate twice, first 
>>> with a self-signed cert and then later using DTMF digits.  In some 
>>> cases, the first authentication has no real purpose, so why can't we 
>>> skip it? That's what I am getting at.
>>>
>>> regards,
>>> Lakshminath
>>>
>>> On 6/7/2007 6:10 AM, Eric Rescorla wrote:
>>>
>>>> At Wed, 06 Jun 2007 23:16:58 -0700,
>>>> Lakshminath Dondeti wrote:
>>>>
>>>>> Thanks for your note.  One of the successful models with certs and 
>>>>> PKI we have is the https model.  The use case I am putting forth 
>>>>> works along those lines.  The caller is the client and the callee 
>>>>> is the server; the server, e.g., a calling card server or a 
>>>>> priority call processing server, authenticates itself first; the 
>>>>> client authentication is optional as DTLS allows and within the 
>>>>> secure tunnel the caller sends DTMF tones as RTP packets to enter 
>>>>> the calling card information or priority codes.
>>>>>
>>>>> That use case came up in a discussion recently.  It is not "future 
>>>>> work" in my opinion.  It is also not dramatically different from 
>>>>> what we have been discussing either.
>>>>
>>>>
>>>> It's also totally compatible with DTLS-SRTP as-is.
>>>>
>>>> Remember, the DTLS client and serve authentication here are for
>>>> the purposes of binding the DTLS handshake to SIP not necessarily
>>>> for the purposes of binding the DTLS-SRTP to an identity. So,
>>>> in this case, what would happen is that both parties would
>>>> DTLS authenticate with their self-signed certs. Optionally,
>>>> callee could use their third-party cert instead. Once the media
>>>> stream is established the client enters DTMF over the secure media
>>>> stream.
>>>>
>>>> Note that this works no matter which side takes on the DTLS 
>>>> client/server
>>>> role, which, btw, is an issue totally orthogonal to who is the callee
>>>> or caller.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

headers

Lakshminath Dondeti | 7 Jun 2007 20:26

Re: Plan for moving forward


Thanks Matt.  I know of cases where skipping the self-signed cert on the 
UAC side would be considered necessary.  Broadly speaking whereas 
verifying server-side certs as in case of https is alright, client-side 
certs, self-signed or not, are not really viable at the moment.  Perhaps 
in the distant future, we don't need such optimizations, but for now 
optimizations at call set-up are good.

regards,
Lakshminath

On 6/7/2007 11:09 AM, Matt Lepinski wrote:
> 
> Lakshminath,
> 
> If I understand correctly, you're saying that there are use cases where 
> the UAS does not care whether the entity with whom he's conducting a 
> DTLS exchange is the same entity who sent the SIP INVITE. (Because the 
> UAS knows that immediately following the DTLS exchange, the UAS will 
> authenticate using "legacy methods").
> 
> I do not know how common such use cases are.
> 
> My question is: In such use cases, is it really too much of a burden to 
> ask the UAC to generate a self-signed cert to use in the a=fingerprint 
> attribute and the DTLS exchange? That is, perhaps there are use cases 
> where the security guarantees provided by tying the signaling to the 
> DTLS exchange are not needed. However, to avoid adding an additional 
> special case to the specifications that we will produce, perhaps it is 
> reasonable to ask the UAC to generate a self-signed cert for use in the 
> a=fingerprint attribute (and subsequent DTLS exchange)?
> 
> My bias is that unless the use-cases in question are quite common, and 
> the computational burden is excessive, it is better to provide the 
> additional security guarantees in all cases (even if in some cases the 
> guarantees are strictly necessary).
> 
> - Matt Lepinski :->
> 
> Lakshminath Dondeti wrote:
> 
>>
>> I agree that it has a purpose when it is necessary to identify the 
>> device, but I am making the case that identifying the device is not 
>> necessary in all cases.
>>
>> regards,
>> Lakshminath
>>
>> On 6/7/2007 10:40 AM, Richard Barnes wrote:
>>
>>> Lakshminath,
>>>
>>> The first authentication does have a purpose. It authenticates that 
>>> DTLS endpoint is the same as the signaling endpoint by providing a 
>>> certificate that matches the a=fingerprint attribute in the 
>>> signaling. That cert could be self-signed or signed by a third party, 
>>> but the binding works becuase the same cert was used in the 
>>> a=fingerprint and in the DTLS exchange.
>>>
>>> --Richard
>>>
>>>
>>>
>>> Lakshminath Dondeti wrote:
>>>
>>>>
>>>> Eric,
>>>>
>>>> I definitely understand the mode of operation you are talking about, 
>>>> but the point is that the caller has to authenticate twice, first 
>>>> with a self-signed cert and then later using DTMF digits.  In some 
>>>> cases, the first authentication has no real purpose, so why can't we 
>>>> skip it? That's what I am getting at.
>>>>
>>>> regards,
>>>> Lakshminath
>>>>
>>>> On 6/7/2007 6:10 AM, Eric Rescorla wrote:
>>>>
>>>>> At Wed, 06 Jun 2007 23:16:58 -0700,
>>>>> Lakshminath Dondeti wrote:
>>>>>
>>>>>> Thanks for your note.  One of the successful models with certs and 
>>>>>> PKI we have is the https model.  The use case I am putting forth 
>>>>>> works along those lines.  The caller is the client and the callee 
>>>>>> is the server; the server, e.g., a calling card server or a 
>>>>>> priority call processing server, authenticates itself first; the 
>>>>>> client authentication is optional as DTLS allows and within the 
>>>>>> secure tunnel the caller sends DTMF tones as RTP packets to enter 
>>>>>> the calling card information or priority codes.
>>>>>>
>>>>>> That use case came up in a discussion recently.  It is not "future 
>>>>>> work" in my opinion.  It is also not dramatically different from 
>>>>>> what we have been discussing either.
>>>>>
>>>>>
>>>>> It's also totally compatible with DTLS-SRTP as-is.
>>>>>
>>>>> Remember, the DTLS client and serve authentication here are for
>>>>> the purposes of binding the DTLS handshake to SIP not necessarily
>>>>> for the purposes of binding the DTLS-SRTP to an identity. So,
>>>>> in this case, what would happen is that both parties would
>>>>> DTLS authenticate with their self-signed certs. Optionally,
>>>>> callee could use their third-party cert instead. Once the media
>>>>> stream is established the client enters DTMF over the secure media
>>>>> stream.
>>>>>
>>>>> Note that this works no matter which side takes on the DTLS 
>>>>> client/server
>>>>> role, which, btw, is an issue totally orthogonal to who is the callee
>>>>> or caller.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 
>

headers

Eric Rescorla | 7 Jun 2007 21:04

Re: Plan for moving forward

At Thu, 07 Jun 2007 11:26:44 -0700,
Lakshminath Dondeti wrote:
> 
> 
> Thanks Matt.  I know of cases where skipping the self-signed cert on the 
> UAC side would be considered necessary.  Broadly speaking whereas 
> verifying server-side certs as in case of https is alright, client-side 
> certs, self-signed or not, are not really viable at the moment.

Can you provide more support for this claim?

The problems with client auth in HTTPS are almost entirely due
to user interface, but in the of DTLS-SRTP, they client auth
is hidden under the covers of the implementation and so this
is not an issue.

-Ekr

headers

Lakshminath Dondeti | 12 Jun 2007 21:48

Re: Plan for moving forward

Eric,

I have double checked with people about where things are in 3GPP and 
3GPP2 and since you care to know the details, it is a somewhat complex 
story (actually not that complex).  If DRM is involved, there are client 
certs, PKI and everything (although in case of broadcast TV, the story 
is different, the mobile operators may be trying to do away with PKIs in 
that context).  But, clearly there is someone to pay for it so to speak; 
content business is a value-add.

For other purposes, people tell me that there were attempts in the past 
and they went no where (I haven't seen them and so I don't know the 
story for sure).  Someone could try to make a proposal and build 
consensus now; the burden then is on the merits of the proposal.  It 
doesn't hurt too much is not an incentive.

There are folks on this list who also contribute to PP and PP2.  If you 
disagree with my notes above, please do let us know.

regards,
Lakshminath

On 6/7/2007 12:04 PM, Eric Rescorla wrote:
> At Thu, 07 Jun 2007 11:26:44 -0700,
> Lakshminath Dondeti wrote:
>>
>> Thanks Matt.  I know of cases where skipping the self-signed cert on the 
>> UAC side would be considered necessary.  Broadly speaking whereas 
>> verifying server-side certs as in case of https is alright, client-side 
>> certs, self-signed or not, are not really viable at the moment.
> 
> Can you provide more support for this claim?
> 
> The problems with client auth in HTTPS are almost entirely due
> to user interface, but in the of DTLS-SRTP, they client auth
> is hidden under the covers of the implementation and so this
> is not an issue.
> 
> -Ekr
> 
>

headers

Dan Wing | 12 Jun 2007 22:26

RE: Plan for moving forward


I don't understand your reference to PKI.

As was explained at length -- I thought -- in Prague, DTLS-SRTP does not
require (nor recommend) that the endpoint's certificate (used for DTLS-SRTP)
be made available in any kind of certificate store ("PKI"), anywhere, by
anybody.  Taken to an extreme, One Might Say that a new certificate could be
created by the endpoints for every DTLS-SRTP call, if the endpoint was
interested in doing such a thing.

-d

> -----Original Message-----
> From: owner-ietf-rtpsec <at> mail.imc.org 
> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
> Lakshminath Dondeti
> Sent: Tuesday, June 12, 2007 12:48 PM
> To: Eric Rescorla
> Cc: Matt Lepinski; ietf-rtpsec <at> imc.org
> Subject: Re: Plan for moving forward
> 
> 
> Eric,
> 
> I have double checked with people about where things are in 3GPP and 
> 3GPP2 and since you care to know the details, it is a 
> somewhat complex 
> story (actually not that complex).  If DRM is involved, there 
> are client 
> certs, PKI and everything (although in case of broadcast TV, 
> the story 
> is different, the mobile operators may be trying to do away 
> with PKIs in 
> that context).  But, clearly there is someone to pay for it 
> so to speak; 
> content business is a value-add.
> 
> For other purposes, people tell me that there were attempts 
> in the past 
> and they went no where (I haven't seen them and so I don't know the 
> story for sure).  Someone could try to make a proposal and build 
> consensus now; the burden then is on the merits of the proposal.  It 
> doesn't hurt too much is not an incentive.
> 
> There are folks on this list who also contribute to PP and 
> PP2.  If you 
> disagree with my notes above, please do let us know.
> 
> regards,
> Lakshminath
> 
> On 6/7/2007 12:04 PM, Eric Rescorla wrote:
> > At Thu, 07 Jun 2007 11:26:44 -0700,
> > Lakshminath Dondeti wrote:
> >>
> >> Thanks Matt.  I know of cases where skipping the 
> self-signed cert on the 
> >> UAC side would be considered necessary.  Broadly speaking whereas 
> >> verifying server-side certs as in case of https is 
> alright, client-side 
> >> certs, self-signed or not, are not really viable at the moment.
> > 
> > Can you provide more support for this claim?
> > 
> > The problems with client auth in HTTPS are almost entirely due
> > to user interface, but in the of DTLS-SRTP, they client auth
> > is hidden under the covers of the implementation and so this
> > is not an issue.
> > 
> > -Ekr
> > 
> >

headers

Lakshminath Dondeti | 12 Jun 2007 22:29

Re: Plan for moving forward


Dan

Of course I understand that.  Please read my note closely :) .  I was 
only referring to PKI in the context of DRM.

Lakshminath

On 6/12/2007 1:26 PM, Dan Wing wrote:
> I don't understand your reference to PKI.
> 
> As was explained at length -- I thought -- in Prague, DTLS-SRTP does not
> require (nor recommend) that the endpoint's certificate (used for DTLS-SRTP)
> be made available in any kind of certificate store ("PKI"), anywhere, by
> anybody.  Taken to an extreme, One Might Say that a new certificate could be
> created by the endpoints for every DTLS-SRTP call, if the endpoint was
> interested in doing such a thing.
> 
> -d
> 
>> -----Original Message-----
>> From: owner-ietf-rtpsec <at> mail.imc.org 
>> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
>> Lakshminath Dondeti
>> Sent: Tuesday, June 12, 2007 12:48 PM
>> To: Eric Rescorla
>> Cc: Matt Lepinski; ietf-rtpsec <at> imc.org
>> Subject: Re: Plan for moving forward
>>
>>
>> Eric,
>>
>> I have double checked with people about where things are in 3GPP and 
>> 3GPP2 and since you care to know the details, it is a 
>> somewhat complex 
>> story (actually not that complex).  If DRM is involved, there 
>> are client 
>> certs, PKI and everything (although in case of broadcast TV, 
>> the story 
>> is different, the mobile operators may be trying to do away 
>> with PKIs in 
>> that context).  But, clearly there is someone to pay for it 
>> so to speak; 
>> content business is a value-add.
>>
>> For other purposes, people tell me that there were attempts 
>> in the past 
>> and they went no where (I haven't seen them and so I don't know the 
>> story for sure).  Someone could try to make a proposal and build 
>> consensus now; the burden then is on the merits of the proposal.  It 
>> doesn't hurt too much is not an incentive.
>>
>> There are folks on this list who also contribute to PP and 
>> PP2.  If you 
>> disagree with my notes above, please do let us know.
>>
>> regards,
>> Lakshminath
>>
>> On 6/7/2007 12:04 PM, Eric Rescorla wrote:
>>> At Thu, 07 Jun 2007 11:26:44 -0700,
>>> Lakshminath Dondeti wrote:
>>>> Thanks Matt.  I know of cases where skipping the 
>> self-signed cert on the 
>>>> UAC side would be considered necessary.  Broadly speaking whereas 
>>>> verifying server-side certs as in case of https is 
>> alright, client-side 
>>>> certs, self-signed or not, are not really viable at the moment.
>>> Can you provide more support for this claim?
>>>
>>> The problems with client auth in HTTPS are almost entirely due
>>> to user interface, but in the of DTLS-SRTP, they client auth
>>> is hidden under the covers of the implementation and so this
>>> is not an issue.
>>>
>>> -Ekr
>>>
>>>
>

headers

Dan Wing | 12 Jun 2007 23:04

RE: Plan for moving forward


Your email was not at all clear, so careful re-reading does not add clarity.
Specifically, when you wrote:

     For other purposes, people tell me that there were attempts 
     in the past and they went no where (I haven't seen them and 
     so I don't know the story for sure).

did you mean:

      For other [non-DRM] purposes, ... there were attempts ... 
      [to have certificates on endpoints?] and they went no 
      where.

-d

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> Sent: Tuesday, June 12, 2007 1:29 PM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
> Subject: Re: Plan for moving forward
> 
> Dan
> 
> Of course I understand that.  Please read my note closely :) .  I was 
> only referring to PKI in the context of DRM.
> 
> Lakshminath
> 
> On 6/12/2007 1:26 PM, Dan Wing wrote:
> > I don't understand your reference to PKI.
> > 
> > As was explained at length -- I thought -- in Prague, 
> DTLS-SRTP does not
> > require (nor recommend) that the endpoint's certificate 
> (used for DTLS-SRTP)
> > be made available in any kind of certificate store ("PKI"), 
> anywhere, by
> > anybody.  Taken to an extreme, One Might Say that a new 
> certificate could be
> > created by the endpoints for every DTLS-SRTP call, if the 
> endpoint was
> > interested in doing such a thing.
> > 
> > -d
> > 
> >> -----Original Message-----
> >> From: owner-ietf-rtpsec <at> mail.imc.org 
> >> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
> >> Lakshminath Dondeti
> >> Sent: Tuesday, June 12, 2007 12:48 PM
> >> To: Eric Rescorla
> >> Cc: Matt Lepinski; ietf-rtpsec <at> imc.org
> >> Subject: Re: Plan for moving forward
> >>
> >>
> >> Eric,
> >>
> >> I have double checked with people about where things are 
> in 3GPP and 
> >> 3GPP2 and since you care to know the details, it is a 
> >> somewhat complex 
> >> story (actually not that complex).  If DRM is involved, there 
> >> are client 
> >> certs, PKI and everything (although in case of broadcast TV, 
> >> the story 
> >> is different, the mobile operators may be trying to do away 
> >> with PKIs in 
> >> that context).  But, clearly there is someone to pay for it 
> >> so to speak; 
> >> content business is a value-add.
> >>
> >> For other purposes, people tell me that there were attempts 
> >> in the past 
> >> and they went no where (I haven't seen them and so I don't 
> know the 
> >> story for sure).  Someone could try to make a proposal and build 
> >> consensus now; the burden then is on the merits of the 
> proposal.  It 
> >> doesn't hurt too much is not an incentive.
> >>
> >> There are folks on this list who also contribute to PP and 
> >> PP2.  If you 
> >> disagree with my notes above, please do let us know.
> >>
> >> regards,
> >> Lakshminath
> >>
> >> On 6/7/2007 12:04 PM, Eric Rescorla wrote:
> >>> At Thu, 07 Jun 2007 11:26:44 -0700,
> >>> Lakshminath Dondeti wrote:
> >>>> Thanks Matt.  I know of cases where skipping the 
> >> self-signed cert on the 
> >>>> UAC side would be considered necessary.  Broadly 
> speaking whereas 
> >>>> verifying server-side certs as in case of https is 
> >> alright, client-side 
> >>>> certs, self-signed or not, are not really viable at the moment.
> >>> Can you provide more support for this claim?
> >>>
> >>> The problems with client auth in HTTPS are almost entirely due
> >>> to user interface, but in the of DTLS-SRTP, they client auth
> >>> is hidden under the covers of the implementation and so this
> >>> is not an issue.
> >>>
> >>> -Ekr
> >>>
> >>>
> >

headers

Lakshminath Dondeti | 12 Jun 2007 23:43

Re: Plan for moving forward


Apologies.  I had another email in my head and I wrote a shorter version 
(since Eric asked I have sent some emails to people asking for their 
recollection of the history, just in case I don't have my facts straight).

Yes, apparently for non-DRM purposes there were attempts to propose the 
use of client certificates with and even without PKIs (I have not looked 
at the relevant contributions so please treat this information as such; 
some of the discussions may have happened in offline discussions. 
People socialize contributions with other companies to see if they can 
build support) and I am told nothing came of it.

thanks,
Lakshminath

On 6/12/2007 2:04 PM, Dan Wing wrote:
> Your email was not at all clear, so careful re-reading does not add clarity.
> Specifically, when you wrote:
> 
>      For other purposes, people tell me that there were attempts 
>      in the past and they went no where (I haven't seen them and 
>      so I don't know the story for sure).
> 
> did you mean:
> 
>       For other [non-DRM] purposes, ... there were attempts ... 
>       [to have certificates on endpoints?] and they went no 
>       where.
> 
> -d
> 
> 
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
>> Sent: Tuesday, June 12, 2007 1:29 PM
>> To: Dan Wing
>> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
>> Subject: Re: Plan for moving forward
>>
>> Dan
>>
>> Of course I understand that.  Please read my note closely :) .  I was 
>> only referring to PKI in the context of DRM.
>>
>> Lakshminath
>>
>> On 6/12/2007 1:26 PM, Dan Wing wrote:
>>> I don't understand your reference to PKI.
>>>
>>> As was explained at length -- I thought -- in Prague, 
>> DTLS-SRTP does not
>>> require (nor recommend) that the endpoint's certificate 
>> (used for DTLS-SRTP)
>>> be made available in any kind of certificate store ("PKI"), 
>> anywhere, by
>>> anybody.  Taken to an extreme, One Might Say that a new 
>> certificate could be
>>> created by the endpoints for every DTLS-SRTP call, if the 
>> endpoint was
>>> interested in doing such a thing.
>>>
>>> -d
>>>
>>>> -----Original Message-----
>>>> From: owner-ietf-rtpsec <at> mail.imc.org 
>>>> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
>>>> Lakshminath Dondeti
>>>> Sent: Tuesday, June 12, 2007 12:48 PM
>>>> To: Eric Rescorla
>>>> Cc: Matt Lepinski; ietf-rtpsec <at> imc.org
>>>> Subject: Re: Plan for moving forward
>>>>
>>>>
>>>> Eric,
>>>>
>>>> I have double checked with people about where things are 
>> in 3GPP and 
>>>> 3GPP2 and since you care to know the details, it is a 
>>>> somewhat complex 
>>>> story (actually not that complex).  If DRM is involved, there 
>>>> are client 
>>>> certs, PKI and everything (although in case of broadcast TV, 
>>>> the story 
>>>> is different, the mobile operators may be trying to do away 
>>>> with PKIs in 
>>>> that context).  But, clearly there is someone to pay for it 
>>>> so to speak; 
>>>> content business is a value-add.
>>>>
>>>> For other purposes, people tell me that there were attempts 
>>>> in the past 
>>>> and they went no where (I haven't seen them and so I don't 
>> know the 
>>>> story for sure).  Someone could try to make a proposal and build 
>>>> consensus now; the burden then is on the merits of the 
>> proposal.  It 
>>>> doesn't hurt too much is not an incentive.
>>>>
>>>> There are folks on this list who also contribute to PP and 
>>>> PP2.  If you 
>>>> disagree with my notes above, please do let us know.
>>>>
>>>> regards,
>>>> Lakshminath
>>>>
>>>> On 6/7/2007 12:04 PM, Eric Rescorla wrote:
>>>>> At Thu, 07 Jun 2007 11:26:44 -0700,
>>>>> Lakshminath Dondeti wrote:
>>>>>> Thanks Matt.  I know of cases where skipping the 
>>>> self-signed cert on the 
>>>>>> UAC side would be considered necessary.  Broadly 
>> speaking whereas 
>>>>>> verifying server-side certs as in case of https is 
>>>> alright, client-side 
>>>>>> certs, self-signed or not, are not really viable at the moment.
>>>>> Can you provide more support for this claim?
>>>>>
>>>>> The problems with client auth in HTTPS are almost entirely due
>>>>> to user interface, but in the of DTLS-SRTP, they client auth
>>>>> is hidden under the covers of the implementation and so this
>>>>> is not an issue.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>

headers

Dan Wing | 13 Jun 2007 00:55

RE: Plan for moving forward


> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> Sent: Tuesday, June 12, 2007 2:44 PM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
> Subject: Re: Plan for moving forward
> 
> Apologies.  I had another email in my head and I wrote a 
> shorter version (since Eric asked I have sent some emails 
> to people asking for their recollection of the history, 
> just in case I don't have my facts straight).

I'll wait for that additional detail.  Without that, I don't
see a substantive argument against self-signed certificates.

-d

> Yes, apparently for non-DRM purposes there were attempts to 
> propose the 
> use of client certificates with and even without PKIs (I have 
> not looked 
> at the relevant contributions so please treat this 
> information as such; 
> some of the discussions may have happened in offline discussions. 
> People socialize contributions with other companies to see if 
> they can 
> build support) and I am told nothing came of it.
> 
> thanks,
> Lakshminath
> 
> On 6/12/2007 2:04 PM, Dan Wing wrote:
> > Your email was not at all clear, so careful re-reading does 
> not add clarity.
> > Specifically, when you wrote:
> > 
> >      For other purposes, people tell me that there were attempts 
> >      in the past and they went no where (I haven't seen them and 
> >      so I don't know the story for sure).
> > 
> > did you mean:
> > 
> >       For other [non-DRM] purposes, ... there were attempts ... 
> >       [to have certificates on endpoints?] and they went no 
> >       where.
> > 
> > -d
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> >> Sent: Tuesday, June 12, 2007 1:29 PM
> >> To: Dan Wing
> >> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
> >> Subject: Re: Plan for moving forward
> >>
> >> Dan
> >>
> >> Of course I understand that.  Please read my note closely 
> :) .  I was 
> >> only referring to PKI in the context of DRM.
> >>
> >> Lakshminath
> >>
> >> On 6/12/2007 1:26 PM, Dan Wing wrote:
> >>> I don't understand your reference to PKI.
> >>>
> >>> As was explained at length -- I thought -- in Prague, 
> >> DTLS-SRTP does not
> >>> require (nor recommend) that the endpoint's certificate 
> >> (used for DTLS-SRTP)
> >>> be made available in any kind of certificate store ("PKI"), 
> >> anywhere, by
> >>> anybody.  Taken to an extreme, One Might Say that a new 
> >> certificate could be
> >>> created by the endpoints for every DTLS-SRTP call, if the 
> >> endpoint was
> >>> interested in doing such a thing.
> >>>
> >>> -d
> >>>
> >>>> -----Original Message-----
> >>>> From: owner-ietf-rtpsec <at> mail.imc.org 
> >>>> [mailto:owner-ietf-rtpsec <at> mail.imc.org] On Behalf Of 
> >>>> Lakshminath Dondeti
> >>>> Sent: Tuesday, June 12, 2007 12:48 PM
> >>>> To: Eric Rescorla
> >>>> Cc: Matt Lepinski; ietf-rtpsec <at> imc.org
> >>>> Subject: Re: Plan for moving forward
> >>>>
> >>>>
> >>>> Eric,
> >>>>
> >>>> I have double checked with people about where things are 
> >> in 3GPP and 
> >>>> 3GPP2 and since you care to know the details, it is a 
> >>>> somewhat complex 
> >>>> story (actually not that complex).  If DRM is involved, there 
> >>>> are client 
> >>>> certs, PKI and everything (although in case of broadcast TV, 
> >>>> the story 
> >>>> is different, the mobile operators may be trying to do away 
> >>>> with PKIs in 
> >>>> that context).  But, clearly there is someone to pay for it 
> >>>> so to speak; 
> >>>> content business is a value-add.
> >>>>
> >>>> For other purposes, people tell me that there were attempts 
> >>>> in the past 
> >>>> and they went no where (I haven't seen them and so I don't 
> >> know the 
> >>>> story for sure).  Someone could try to make a proposal and build 
> >>>> consensus now; the burden then is on the merits of the 
> >> proposal.  It 
> >>>> doesn't hurt too much is not an incentive.
> >>>>
> >>>> There are folks on this list who also contribute to PP and 
> >>>> PP2.  If you 
> >>>> disagree with my notes above, please do let us know.
> >>>>
> >>>> regards,
> >>>> Lakshminath
> >>>>
> >>>> On 6/7/2007 12:04 PM, Eric Rescorla wrote:
> >>>>> At Thu, 07 Jun 2007 11:26:44 -0700,
> >>>>> Lakshminath Dondeti wrote:
> >>>>>> Thanks Matt.  I know of cases where skipping the 
> >>>> self-signed cert on the 
> >>>>>> UAC side would be considered necessary.  Broadly 
> >> speaking whereas 
> >>>>>> verifying server-side certs as in case of https is 
> >>>> alright, client-side 
> >>>>>> certs, self-signed or not, are not really viable at the moment.
> >>>>> Can you provide more support for this claim?
> >>>>>
> >>>>> The problems with client auth in HTTPS are almost entirely due
> >>>>> to user interface, but in the of DTLS-SRTP, they client auth
> >>>>> is hidden under the covers of the implementation and so this
> >>>>> is not an issue.
> >>>>>
> >>>>> -Ekr
> >>>>>
> >>>>>
> >

headers

Lakshminath Dondeti | 13 Jun 2007 02:04

Re: Plan for moving forward


Dan,

I resumed this thread after collecting additional feedback.  If you are 
looking for a concrete reference, there isn't any to my knowledge.  I am 
not saying you have to take my word for it.  I am just pointing to 
places where I have checked.

thanks,
Lakshminath

On 6/12/2007 3:55 PM, Dan Wing wrote:
>  
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
>> Sent: Tuesday, June 12, 2007 2:44 PM
>> To: Dan Wing
>> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
>> Subject: Re: Plan for moving forward
>>
>> Apologies.  I had another email in my head and I wrote a 
>> shorter version (since Eric asked I have sent some emails 
>> to people asking for their recollection of the history, 
>> just in case I don't have my facts straight).
> 
> I'll wait for that additional detail.  Without that, I don't
> see a substantive argument against self-signed certificates.
> 
> -d
>

headers

Dan Wing | 13 Jun 2007 02:39

RE: Plan for moving forward


> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> Sent: Tuesday, June 12, 2007 5:05 PM
> To: Dan Wing
> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
> Subject: Re: Plan for moving forward
> 
> Dan,
> 
> I resumed this thread after collecting additional feedback.  
> If you are looking for a concrete reference, there isn't any 
> to my knowledge.  I am not saying you have to take my word for 
> it.  I am just pointing to places where I have checked.

I am sorry to hear there were failures in the past in some 
unspecified standards organization.  As it seems we can't learn 
anything from this previous failure due to lack of detail 
about it, we can only forge onward with the information at hand:
that creating a public/private key on a device and wrapping 
a certificate around it is easy and can be done on any device 
capable of being a VoIP endpoint.

-d

> thanks,
> Lakshminath
> 
> On 6/12/2007 3:55 PM, Dan Wing wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
> >> Sent: Tuesday, June 12, 2007 2:44 PM
> >> To: Dan Wing
> >> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
> >> Subject: Re: Plan for moving forward
> >>
> >> Apologies.  I had another email in my head and I wrote a 
> >> shorter version (since Eric asked I have sent some emails 
> >> to people asking for their recollection of the history, 
> >> just in case I don't have my facts straight).
> > 
> > I'll wait for that additional detail.  Without that, I don't
> > see a substantive argument against self-signed certificates.
> > 
> > -d
> >

headers

Lakshminath Dondeti | 13 Jun 2007 03:59

Re: Plan for moving forward


Dan,

In a few of the emails in this thread, I mentioned 3GPP and 3GPP2.  So 
it is inaccurate to say "unspecified organization."  Anyway, it appears 
that we have moved past having a professional conversation.

Lakshminath

On 6/12/2007 5:39 PM, Dan Wing wrote:
> 
> 
>> -----Original Message-----
>> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
>> Sent: Tuesday, June 12, 2007 5:05 PM
>> To: Dan Wing
>> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
>> Subject: Re: Plan for moving forward
>>
>> Dan,
>>
>> I resumed this thread after collecting additional feedback.  
>> If you are looking for a concrete reference, there isn't any 
>> to my knowledge.  I am not saying you have to take my word for 
>> it.  I am just pointing to places where I have checked.
> 
> I am sorry to hear there were failures in the past in some 
> unspecified standards organization.  As it seems we can't learn 
> anything from this previous failure due to lack of detail 
> about it, we can only forge onward with the information at hand:
> that creating a public/private key on a device and wrapping 
> a certificate around it is easy and can be done on any device 
> capable of being a VoIP endpoint.
> 
> -d
> 
> 
>> thanks,
>> Lakshminath
>>
>> On 6/12/2007 3:55 PM, Dan Wing wrote:
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com] 
>>>> Sent: Tuesday, June 12, 2007 2:44 PM
>>>> To: Dan Wing
>>>> Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec <at> imc.org
>>>> Subject: Re: Plan for moving forward
>>>>
>>>> Apologies.  I had another email in my head and I wrote a 
>>>> shorter version (since Eric asked I have sent some emails 
>>>> to people asking for their recollection of the history, 
>>>> just in case I don't have my facts straight).
>>> I'll wait for that additional detail.  Without that, I don't
>>> see a substantive argument against self-signed certificates.
>>>
>>> -d
>>>
>

headers

Dan Wing | 13 Jun 2007 04:20

RE: Plan for moving forward


> In a few of the emails in this thread, I mentioned 3GPP and 
> 3GPP2.  So it is inaccurate to say "unspecified organization."  
> Anyway, it appears that we have moved past having a professional 
> conversation.

Yes, I have been waiting for additional information and am 
frustrated to have received only FUD about previous attempts to
something that also attempted to use certificates.  I'm sorry it
devolved, too, but details and moving forward is helpful.  Holding
back progress with FUD about previous attempts is not.

-d

headers

Lakshminath Dondeti | 13 Jun 2007 04:40

Re: Plan for moving forward

Dan,

That was not my intention.  I am surprised too that you see it that way. 
  Suppose people in another standards organization propose X to take to 
the IETF and let us say I know of some work along the same lines of X 
that didn't go anywhere in the IETF.  Sometimes we have public records 
such as this exchange and other times all I may have are vague private 
emails from ADs.  Wouldn't I be in about the same situation as I am in now?

I could keep quiet and let them find out themselves or if I am 
interested in making forward progress, I would try and communicate.

Anyway, sorry this has been a useless exercise.

best wishes,
Lakshminath

On 6/12/2007 7:20 PM, Dan Wing wrote:
>> In a few of the emails in this thread, I mentioned 3GPP and 
>> 3GPP2.  So it is inaccurate to say "unspecified organization."  
>> Anyway, it appears that we have moved past having a professional 
>> conversation.
> 
> Yes, I have been waiting for additional information and am 
> frustrated to have received only FUD about previous attempts to
> something that also attempted to use certificates.  I'm sorry it
> devolved, too, but details and moving forward is helpful.  Holding
> back progress with FUD about previous attempts is not.
> 
> -d
>

headers

Cullen Jennings | 14 Jun 2007 00:24

Re: Plan for moving forward


There are several people that have been subscribed to this mailing  
list for a long time that have an excellent understanding of 3GPP and  
3GPP2. I'm working on the assumption that if they had clear  
information that would help us not repeat a mistake that happened  
elsewhere, they would probably have passed on that information. If  
someone has a concrete problem, I'm sure the folks here would be very  
happy to understand it. I will also note that this work was never  
scoped to deal with IPTV type security - the requirements for that  
would be much different and would be more likely to include DRM in  
the requirements.

Cullen <with my AD hat on>

headers

Eric Rescorla | 12 Jun 2007 23:50

Re: Plan for moving forward


At Tue, 12 Jun 2007 14:43:46 -0700,
Lakshminath Dondeti wrote:
> Apologies.  I had another email in my head and I wrote a shorter version 
> (since Eric asked I have sent some emails to people asking for their 
> recollection of the history, just in case I don't have my facts straight).
> 
> Yes, apparently for non-DRM purposes there were attempts to propose the 
> use of client certificates with and even without PKIs (I have not looked 
> at the relevant contributions so please treat this information as such; 
> some of the discussions may have happened in offline discussions. 
> People socialize contributions with other companies to see if they can 
> build support) and I am told nothing came of it.

I'm having a lot of trouble understanding how this bears on the 
situation with DTLS-SRTP.

-Ekr

headers

Dan Wing | 2 Jun 2007 20:14

RE: Plan for moving forward


> > Yes, but in conjunction with SIP-Identity (RFC4474) you get
> > authentication -- if, of course, you trust the entity that 
> > created that RFC4474 signature.  I don't usually think of DTLS-SRTP
> > without SIP-Identity, myself -- without SIP-Identity, you're getting
> > little more than opportunistic encryption (unless you store the
> > certificate you used last time with that same party, and/or read 
> > each other's certificate fingerprints or something akin to that).
> 
> Totally agree. I'm just saying that we ought to think of the 
> authentication as happening in the signalling and being transferred
> into the media. We should try to avoid having authentication 
> mechanisms which authenticate only the media and not the signalling.

I agree.

-d