Comments on draft-wing-sip-identity-media-01

$Id: draft-wing-sip-identity-media-01-rev.txt,v 1.1
2007/11/28 01:26:28 ekr Exp $

This draft seems to do two distinct things:

- One specify a variant of RFC 4474 which signs a lot fewer
headers.
- Specify a set of mechanisms to cryptographically prove
that a given media
  stream corresponds to a given SDP offer/answer.

As I understand it, the rationale for the first of these is
that
SBCs will break RFC 4474 signatures and won't have the
public
keys required to generate new ones. I'm not really a SIP
expert,
but I thought that the party line was the SBCs were B2BUAs
and so whatever the identity of the SBC was was the UAC,
so if that SBC doesn't have the right credentials to sign
an RFC 4474 identity for "aliceexample.com" then it
shouldn't
be attesting to it. But again, I could be totally
misunderstanding
3261, etc.

That said, as I read S 3.1.3, the SBC signs
"alice%example.comsbc.com". I don't really understand
what the recipient of such an identity is to make of this,
since surely we wouldn't want anyone to be able to attest
to other people's identities like this. So, this means
that the relying party needs to have some list of the
form "the following SBC cert can sign for the following

domains". How does this get communicated? Is this
really
easier than giving the SBC the private key?


With regard to the second issue, I agree this is important,
but this is an orthogonal issue to which headers get
signed,
right? In general, we certainly do want a way to tie media
to keying cryptographically, but as you note, DTLS-SRTP
already provides this. I don't quite see why you *always*
need this proof. What about requests that don't come
with media? Anyway, are you claiming this is also a problem
for RFC 4474?

-Ekr


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> -----Original Message-----
> From: Eric Rescorla [mailto:ekrnetworkresonance.com]
> Sent: Tuesday, November 27, 2007 8:30 PM
>
> This draft seems to do two distinct things:
>
> - One specify a variant of RFC 4474 which signs a lot
fewer headers.

Yup, and thereby increase its chance of success.


> - Specify a set of mechanisms to cryptographically
prove that a given
> media
>   stream corresponds to a given SDP offer/answer.

Yup, but it may need this second part to compensate for the
first part. (for some cases)


> As I understand it, the rationale for the first of
these is that
> SBCs will break RFC 4474 signatures and won't have the
public
> keys required to generate new ones. I'm not really a
SIP expert,
> but I thought that the party line was the SBCs were
B2BUAs
> and so whatever the identity of the SBC was was the
UAC,
> so if that SBC doesn't have the right credentials to
sign
> an RFC 4474 identity for "aliceexample.com" then it shouldn't
> be attesting to it. But again, I could be totally
misunderstanding
> 3261, etc.

Yeah so this is going to go into a big black hole methinks,
and like all good black holes, trying to shed light on it
won't make things clearer.   I mean we
would get into some philosophical debate about the meaning
of "identity" and what "attesting to it"
means.

I don't think we need to talk about this in the context of
B2BUA's and the identity they do or don't represent, though.
 Maybe we can just talk about the draft's mechanism as being
palatable or not based on whether it addresses the same
issues 4474 did, with similar benefits, in a reasonably
secure a fashion, albeit in a different way?

So for example, comparing this mechanism to 4474, is it as
legit?  What additional weaknesses does it create, and are
they untenable? (I can think of a few, mostly MITM related
of course)


> That said, as I read S 3.1.3, the SBC signs
> "alice%example.comsbc.com". I don't
really understand
> what the recipient of such an identity is to make of
this,
> since surely we wouldn't want anyone to be able to
attest
> to other people's identities like this. So, this means
> that the relying party needs to have some list of the
> form "the following SBC cert can sign for the
following
> domains". How does this get communicated? Is this
really
> easier than giving the SBC the private key?

Actually that example was meant to demonstrate the
unpalatable way to address the problem without this draft. 
In other words, it's a "this is how crazy 4474 would
become" type thing.  It wasn't about how the draft's
proposed mechanism would work, nor how 4474 should work. 



> With regard to the second issue, I agree this is
important,
> but this is an orthogonal issue to which headers get
signed,
> right?

I'll leave that to Dan, but I think you need this second
issue addressed to explain why not signing the c=/m= is ok.


> In general, we certainly do want a way to tie media
> to keying cryptographically, but as you note,
DTLS-SRTP
> already provides this. I don't quite see why you
*always*
> need this proof. What about requests that don't come
> with media? Anyway, are you claiming this is also a
problem
> for RFC 4474?

You mean offer-less Invites?  Yes, that's already a problem
for 4474.  If you mean for non-SDP requests (e.g., MESSAGE
or SUB/NOT), the mechanism in this draft would sign that
whole MIME body as 4474 did, except still sign fewer
headers.

-hadriel



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hadriel Kaplan wrote:
> 
>> -----Original Message-----
>> From: Eric Rescorla [mailto:ekrnetworkresonance.com]
>> Sent: Tuesday, November 27, 2007 8:30 PM
>>
>> This draft seems to do two distinct things:
>>
>> - One specify a variant of RFC 4474 which signs a
lot fewer headers.
> 
> Yup, and thereby increase its chance of success.
> 
> 
>> - Specify a set of mechanisms to cryptographically
prove that a given
>> media
>>   stream corresponds to a given SDP offer/answer.
> 
> Yup, but it may need this second part to compensate for
the first part. (for some cases)
> 
> 
>> As I understand it, the rationale for the first of
these is that
>> SBCs will break RFC 4474 signatures and won't have
the public
>> keys required to generate new ones. I'm not really
a SIP expert,
>> but I thought that the party line was the SBCs were
B2BUAs
>> and so whatever the identity of the SBC was was the
UAC,
>> so if that SBC doesn't have the right credentials
to sign
>> an RFC 4474 identity for "aliceexample.com" then it shouldn't
>> be attesting to it. But again, I could be totally
misunderstanding
>> 3261, etc.
> 
> Yeah so this is going to go into a big black hole
methinks, and like all good black holes, trying to shed
light on it won't make things clearer.   I mean we
would get into some philosophical debate about the meaning
of "identity" and what "attesting to it"
means.

I hope that isn't a black hole, because I think those issued
*need* to 
be worked out.

This is like the elephant in the living room that nobody is
willing to 
mention.

There may indeed be value in signing a set of headers that
can survive 
passing through an SBC. But the pros and cons of that need
to be discussed.

	Thanks,
	Paul

> I don't think we need to talk about this in the context
of B2BUA's and the identity they do or don't represent,
though.  Maybe we can just talk about the draft's mechanism
as being palatable or not based on whether it addresses the
same issues 4474 did, with similar benefits, in a reasonably
secure a fashion, albeit in a different way?
> 
> So for example, comparing this mechanism to 4474, is it
as legit?  What additional weaknesses does it create, and
are they untenable? (I can think of a few, mostly MITM
related of course)
> 
> 
>> That said, as I read S 3.1.3, the SBC signs
>> "alice%example.comsbc.com". I don't
really understand
>> what the recipient of such an identity is to make
of this,
>> since surely we wouldn't want anyone to be able to
attest
>> to other people's identities like this. So, this
means
>> that the relying party needs to have some list of
the
>> form "the following SBC cert can sign for the
following
>> domains". How does this get communicated? Is
this really
>> easier than giving the SBC the private key?
> 
> Actually that example was meant to demonstrate the
unpalatable way to address the problem without this draft. 
In other words, it's a "this is how crazy 4474 would
become" type thing.  It wasn't about how the draft's
proposed mechanism would work, nor how 4474 should work. 

> 
> 
>> With regard to the second issue, I agree this is
important,
>> but this is an orthogonal issue to which headers
get signed,
>> right?
> 
> I'll leave that to Dan, but I think you need this
second issue addressed to explain why not signing the c=/m=
is ok.
> 
> 
>> In general, we certainly do want a way to tie
media
>> to keying cryptographically, but as you note,
DTLS-SRTP
>> already provides this. I don't quite see why you
*always*
>> need this proof. What about requests that don't
come
>> with media? Anyway, are you claiming this is also a
problem
>> for RFC 4474?
> 
> You mean offer-less Invites?  Yes, that's already a
problem for 4474.  If you mean for non-SDP requests (e.g.,
MESSAGE or SUB/NOT), the mechanism in this draft would sign
that whole MIME body as 4474 did, except still sign fewer
headers.
> 
> -hadriel
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

...
> > With regard to the second issue, I agree this is
important,
> > but this is an orthogonal issue to which headers
get signed,
> > right?
> 
> I'll leave that to Dan, but I think you need this
second 
> issue addressed to explain why not signing the c=/m= is
ok.

RFC4474 signs the SIP body (containing the SDP and 
containing the c=/m= lines) because RFC4474 ties the IP 
address and UDP port to the identifier (From: dwingcisco.com).

SIP-Identity-Media doesn't use the IP address and UDP port
as the identifier.  SIP-Identity-Media uses the DTLS-SRTP 
certificate as the identifier (or HIP, or an ICE extension,
or TLS).

> > In general, we certainly do want a way to tie
media
> > to keying cryptographically, but as you note,
DTLS-SRTP
> > already provides this. I don't quite see why you
*always*
> > need this proof. What about requests that don't
come
> > with media? Anyway, are you claiming this is also
a problem
> > for RFC 4474?
> 
> You mean offer-less Invites?  Yes, that's already a
problem 
> for 4474. 

Right.  

(Perhaps sip-connected-identity can help with offerless 
Invites; I don't know.)

> If you mean for non-SDP requests (e.g., MESSAGE or 
> SUB/NOT), the mechanism in this draft would sign that
whole 
> MIME body as 4474 did, except still sign fewer
headers.

Right; this was a problem Paul Kyzivat pointed out in his
review of sip-identity-media-00.  sip-identity-media-01
will
sign the non-SDP body parts.

-d


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

...
> There may indeed be value in signing a set of headers
that 
> can survive passing through an SBC. But the pros and
cons 
> of that need to be discussed.

With SBCs, RFC4474 requires the SBC to create a new
identity
and sign that.  sip-identity-media shows how this would
work
with E.164s (it works alright if each hop is entrusted to 
validate and then re-sign the E.164 address with their own
domain 
name) and how this would work with email-style addresses (it

doesn't work at all).


Before we talk about SIP headers I think we need to decide
if:

  *  re-creating E.164 identities at each hop okay

  *  we need email-style SIP identities to survive through
SBCs?

as this is how RFC4474 operates with today's SBCs.


(Please see draft-wing-sip-identity-media-01, section 3,
for
details.)

-d


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At Wed, 28 Nov 2007 10:09:18 -0800,
Dan Wing wrote:
> 
> ...
> > > With regard to the second issue, I agree this
is important,
> > > but this is an orthogonal issue to which
headers get signed,
> > > right?
> > 
> > I'll leave that to Dan, but I think you need this
second 
> > issue addressed to explain why not signing the
c=/m= is ok.
> 
> RFC4474 signs the SIP body (containing the SDP and 
> containing the c=/m= lines) because RFC4474 ties the IP

> address and UDP port to the identifier (From: dwingcisco.com).

Hmm... That's necessarily a pretty weak binding compared
to the digital signature, right? 


> SIP-Identity-Media doesn't use the IP address and UDP
port
> as the identifier.  SIP-Identity-Media uses the
DTLS-SRTP 
> certificate as the identifier (or HIP, or an ICE
extension,
> or TLS).

Sorry, I'm still not getting why this is necessary.

I get an INVITE and then I establish an RTP stream. If I
care about
data origin authentication for the media , I should be using
SRTP.
If I'm not, then I don't care much. That's true with both
this
draft and RFC 4474. I still don't understand why this draft
always needs a cryptographic identity proof and RFC 4474
does 
not.

-Ekr




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Ekr,

The point is, the Wing draft only helps if media is secured
with SRTP.
The Identity-Media header field basically signs the
fingerprint of the
UA certificate that will be used to negotiate the key for
SRTP. So if
the Identity-Media header field provides cryptographic
evidence that the
remote party is Aliceexample.com, then any SRTP using a key
derived
from the certificate whose fingerprint is signed by the
Identity-Media
header field must be from Aliceexample.com (assuming you
trust the
example.com domain - an assumption applicable equally to RFC
4474 and
Identity-Media).

John 

> -----Original Message-----
> From: Eric Rescorla [mailto:ekrnetworkresonance.com] 
> Sent: 28 November 2007 18:23
> To: Dan Wing
> Cc: sipietf.org
> Subject: Re: [Sip] Comments on
draft-wing-sip-identity-media-01
> 
> At Wed, 28 Nov 2007 10:09:18 -0800,
> Dan Wing wrote:
> > 
> > ...
> > > > With regard to the second issue, I agree
this is important,
> > > > but this is an orthogonal issue to which
headers get signed,
> > > > right?
> > > 
> > > I'll leave that to Dan, but I think you need
this second 
> > > issue addressed to explain why not signing
the c=/m= is ok.
> > 
> > RFC4474 signs the SIP body (containing the SDP and

> > containing the c=/m= lines) because RFC4474 ties
the IP 
> > address and UDP port to the identifier (From:
dwingcisco.com).
> 
> Hmm... That's necessarily a pretty weak binding
compared
> to the digital signature, right? 
> 
> 
> > SIP-Identity-Media doesn't use the IP address and
UDP port
> > as the identifier.  SIP-Identity-Media uses the
DTLS-SRTP 
> > certificate as the identifier (or HIP, or an ICE
extension,
> > or TLS).
> 
> Sorry, I'm still not getting why this is necessary.
> 
> I get an INVITE and then I establish an RTP stream. If
I care about
> data origin authentication for the media , I should be
using SRTP.
> If I'm not, then I don't care much. That's true with
both this
> draft and RFC 4474. I still don't understand why this
draft
> always needs a cryptographic identity proof and RFC
4474 does 
> not.
> 
> -Ekr
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

At Wed, 28 Nov 2007 20:35:07 +0000,
Elwell, John wrote:
> 
> Ekr,
> 
> The point is, the Wing draft only helps if media is
secured with SRTP.
> The Identity-Media header field basically signs the
fingerprint of the
> UA certificate that will be used to negotiate the key
for SRTP. So if
> the Identity-Media header field provides cryptographic
evidence that the
> remote party is Aliceexample.com, then any SRTP
using a key derived
> from the certificate whose fingerprint is signed by the
Identity-Media
> header field must be from Aliceexample.com (assuming you
trust the
> example.com domain - an assumption applicable equally
to RFC 4474 and
> Identity-Media).

But it seems to me that the same argument applies to RFC
4474, right?

I.e., the semantics of 4474 are: Here is a bunch of message
data
sent by X. The semantics of Identity-media are: here is
somewhat
less message data sent by X. Why does one need a proof of
identity
and the other not?

-Ekr


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> > > > With regard to the second issue, I agree
this is important,
> > > > but this is an orthogonal issue to which
headers get signed,
> > > > right?
> > > 
> > > I'll leave that to Dan, but I think you need
this second 
> > > issue addressed to explain why not signing
the c=/m= is ok.
> > 
> > RFC4474 signs the SIP body (containing the SDP and

> > containing the c=/m= lines) because RFC4474 ties
the IP 
> > address and UDP port to the identifier (From:
dwingcisco.com).
> 
> Hmm... That's necessarily a pretty weak binding
compared
> to the digital signature, right? 

I concur.
 
> > SIP-Identity-Media doesn't use the IP address and
UDP port
> > as the identifier.  SIP-Identity-Media uses the
DTLS-SRTP 
> > certificate as the identifier (or HIP, or an ICE
extension,
> > or TLS).
> 
> Sorry, I'm still not getting why this is necessary.
> 
> I get an INVITE and then I establish an RTP stream. If
I care about
> data origin authentication for the media , I should be
using SRTP.
> If I'm not, then I don't care much. That's true with
both this
> draft and RFC 4474. I still don't understand why this
draft
> always needs a cryptographic identity proof and RFC
4474 does 
> not.

Because SIP-Identity-Media is validating the identity of
the
remote party, by making the remote party prove it knows the
private key associated with its DTLS/TLS certificate or
ICE/HIP public key.

RFC4474 doesn't.  RFC4474 only requires symmetric RTP, and 
only requires RTP packets arrive from the same IP address 
and UDP port as signed by RFC4474.  It is using the source
IP address to provide the identity.  With SBCs, which are
continually modifying the source IP address (when they
rewrite the m/c lines), you can only get a signature from
the closest SBC.  Which means you're trusting it.  It
trusted the SBC one hop away, which trusted the SBC the
next hop away, and so on, until we finally get back to
the real user agent that generated in the Invite.

-d


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> But it seems to me that the same argument applies to
RFC 4474, right?
> 
> I.e., the semantics of 4474 are: Here is a bunch of
message data
> sent by X.

RFC4474 also says that any RTP packets with the source
address
in the RFC4474-signed SDP is from X.

> The semantics of Identity-media are: here is somewhat
> less message data sent by X.

Identity-Media also says that you can do a DTLS-SRTP, TLS,
HIP, or ICE (with extensions) handshake with the source
address
in the SDP, and you can validate the certificate (or public
key) exchanged in that DTLS-SRTP/TLS/HIP/ICE exchange
matches
the Identity-Media-signed a=fingerprint of X.

> Why does one need a proof of identity and the other
not?

RFC4474 uses source transport address for proof of
identity.
Identity-Media uses certificates (DTLS-SRTP/TLS) or public
keys (HIP/ICE).  

-d


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip