headers
Hadriel Kaplan | 1 Aug 2008 02:54
Favicon

Re: Thoughts on SIP Identity issues


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr <at> networkresonance.com]
>
> Funny you should mention that.
>
> It's becoming increasingly clear that VBR codecs leak a fair
> amount of information, even when they are encrypted [WBC+08].
> So, if, for instance, you were planning to use a fixed-rate
> codec and an attacker could force you into a VBR codec, that
> might leak information.

Fascinating paper. (truly)  But it sounds more like just a reason to fix SRTP for VBR, through random padding
or whatever.

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 22 comments |
headers
Eric Rescorla | 1 Aug 2008 03:02

Re: Thoughts on SIP Identity issues

At Thu, 31 Jul 2008 20:54:43 -0400,
Hadriel Kaplan wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr <at> networkresonance.com]
> >
> > Funny you should mention that.
> >
> > It's becoming increasingly clear that VBR codecs leak a fair
> > amount of information, even when they are encrypted [WBC+08].
> > So, if, for instance, you were planning to use a fixed-rate
> > codec and an attacker could force you into a VBR codec, that
> > might leak information.
> 
> Fascinating paper. (truly) But it sounds more like just a reason to
> fix SRTP for VBR, through random padding or whatever.

I haven't studied the problem, but I suspect random padding
is of limited use because it averages out. Probably better
to use a fixed length codec.

However, I think focusing on that misses the larger point: the UAC and
UAS have certain desires as expressed in the messages/SDP
To the extent to which we allow the intermediaries to change
those messages, we need to carefully analyze each instance,
and this analysis may actually depend on facts yet to be 
discovered.
-Ekr
(Continue reading)

Permalink | Reply | 21 comments |
headers
Dan Wing | 1 Aug 2008 10:36
Picon
Favicon

Re: Thoughts on SIP Identity issues

> At Thu, 31 Jul 2008 20:54:43 -0400,
> Hadriel Kaplan wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Eric Rescorla [mailto:ekr <at> networkresonance.com]
> > >
> > > Funny you should mention that.
> > >
> > > It's becoming increasingly clear that VBR codecs leak a fair
> > > amount of information, even when they are encrypted [WBC+08].
> > > So, if, for instance, you were planning to use a fixed-rate
> > > codec and an attacker could force you into a VBR codec, that
> > > might leak information.
> > 
> > Fascinating paper. (truly) But it sounds more like just a reason to
> > fix SRTP for VBR, through random padding or whatever.
> 
> I haven't studied the problem, but I suspect random padding
> is of limited use because it averages out. Probably better
> to use a fixed length codec.
> 
> However, I think focusing on that misses the larger point: the UAC and
> UAS have certain desires as expressed in the messages/SDP
> To the extent to which we allow the intermediaries to change
> those messages, we need to carefully analyze each instance,
> and this analysis may actually depend on facts yet to be 
> discovered.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Hadriel Kaplan | 1 Aug 2008 10:47
Favicon

Re: Alternative SIP Identity Approach (was re: Thoughts on SIP Identity)


> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of Dan
> Wing
>
> The chain would be good, but I would be happy with the first link:
> who (claims to have) injected the message into the SIP network.  Even
> if the message transited over some itty-bitty ITSP in a country I had
> never heard of, it wouldn't matter if I could verify the identity of
> who injected the message into the SIP 'cloud'.

That was kinda my thought for the P-Asserter draft - as much as preventing all mitm cases would be great, not
having anything is far worse.  Most of my customers don't care about preventing mitm for identity; if
there's a malicious mitm, wrong identity is the *least* of their problems.  What they care more about (I
think) is lying originators, open relays, and the like.

In other words they want to prevent SPAM and Phishing and such.  Having a proof of signaling originator
Identity alone (ie, the From or something similar) with replay protection and non-repudiation is
sufficient for them - they don't need SDP identity, or Call-Id Identity, or CSeq Identity.

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 1 Aug 2008 11:40
Picon
Favicon

Re: Comments on draft-ietf-sip-body-handling-02

Hi Keith,

per our conversation, I guess we can just leave the text as it is right 
now. The thing is that nesting was already defined for email and we do 
not really want to change those definitions and recommendations. The 
only thing we are doing here is stressing that you should not just 
perform nesting for fun. You need a reason to do that.

Thanks,

Gonzalo

Paul Kyzivat wrote:
> 
> 
> DRAGE, Keith (Keith) wrote:
> 
>> I know we do have this paragraph in section 4.1:
>>
>>    Nested MIME bodies are yet another useful tool to build and combine
>>    SIP extensions.  Using the extensions in the previous examples, a UA
>>    that supported a new session description format and that needed to
>>    include a location object in an INVITE request would include a
>>    'multipart/mixed' body with two body parts: a location object and a
>>    'multipart/alternative'.  The 'multipart/alternative' body part
>>    would, in turn, have two body parts: a session description written in
>>    SDP and a session description written in the newer session
>>    description format.
>>
>> But thinking about this, I suspect we define no semantics anywhere
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gonzalo Camarillo | 1 Aug 2008 11:46
Picon
Favicon

Re: WGLC for draft-ietf-sip-body-handling

Hi,

the handling parameter appears registered as defined by RFC 3261:
http://www.iana.org/assignments/sip-parameters

I will look into this and add the appropriate IANA actions so that the 
IANA's register is correct.

Thanks,

Gonzalo

DRAGE, Keith (Keith) wrote:
>> On Keith's point that body-handling updates 3204, that works 
>> for me if this draft updates the rules for ISUP.  However, if 
>> it updates the meaning of "handling", then it is 3459 that 
>> gets the update, as 3459 updates 3204 already.
> 
> Well if this is the case, then it should have added its own reference to
> the IANA registration of the handling parameter, which it did not.
> Suggest therefore that sip-body-handling also updates the IANA registry
> to include RFC 3459 as well as its own RFC number.
> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On 
>> Behalf Of Eric Burger
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 1 Aug 2008 11:50
Picon
Favicon

Re: Comments on draft-ietf-sip-body-handling-02

Hi Keith,

sure, I can add a sentence per your suggestion below.

Thanks,

Gonzalo

DRAGE, Keith (Keith) wrote:
> My personal preference would be to add a disclaimer sentence to indicate that such semantics are not
defined in any SIP RFC (so far), so any interpretation of the relationship between multiple parts when
they are nested or otherwise is solely dependent on the interpretation of the MIME values, and that the
examples imply no specific definition of semantics for SIP. 
> 
> As this is an interpretation, different vendors may have different interpretations.
> 
> I could live without this, but something conveying this sense would be better.
> 
> Keith
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> ericsson.com] 
>> Sent: Friday, August 01, 2008 10:40 AM
>> To: Paul Kyzivat
>> Cc: DRAGE, Keith (Keith); SIP IETF
>> Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02
>>
>> Hi Keith,
>>
>> per our conversation, I guess we can just leave the text as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Willis | 1 Aug 2008 12:05
Favicon

Re: Alternative SIP Identity Approach (was re: Thoughts on SIP Identity)


On Jul 31, 2008, at 2:14 PM, Adam Roach wrote:

> On 7/31/08 1:49 PM, Dean Willis wrote:
>>
>> Here's an example:
>>
>> 1) alice <at> example.com calls bob <at> example.net
>>
>> 2) The example.com AS authenticates Alice using a mechanism such as  
>> proxy-authenticate, then adds an appropriate Identity and Identity- 
>> Info header field.
>>
>> 3) Bob's B2BUA verifies the Identity header field
>>
>> 4) Bob's B2BUA checks the Identity value value against Bob's  
>> whitelist and chooses to allow the call.
>>
>> 5) But Bob is out, so the B2BUA wants to forward the call to Bob's  
>> mobile phone. But Bob's administrative policy requires recording  
>> the call.
>>
>> Since Bob's administrative policy requires  recording the call,  
>> Bob's b2bua steers the media through a recorder. This requires  
>> either "editing the SDP"  or termination of media on the SBC. in  
>> either case, it is not reasonable to send the existing Identity  
>> header on to Bob, since it's going to be broken.
>>
>> 6) Bob's B2BUA elides the previous Identity and Identity-Info and  
>> adds a new Reasserted-Identity and Reasserted-Identity-Info header
(Continue reading)

Permalink | Reply | 5 comments |
headers
DRAGE, Keith (Keith | 1 Aug 2008 11:48
Favicon

Re: Comments on draft-ietf-sip-body-handling-02

My personal preference would be to add a disclaimer sentence to indicate that such semantics are not
defined in any SIP RFC (so far), so any interpretation of the relationship between multiple parts when
they are nested or otherwise is solely dependent on the interpretation of the MIME values, and that the
examples imply no specific definition of semantics for SIP. 

As this is an interpretation, different vendors may have different interpretations.

I could live without this, but something conveying this sense would be better.

Keith

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> ericsson.com] 
> Sent: Friday, August 01, 2008 10:40 AM
> To: Paul Kyzivat
> Cc: DRAGE, Keith (Keith); SIP IETF
> Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02
> 
> Hi Keith,
> 
> per our conversation, I guess we can just leave the text as 
> it is right now. The thing is that nesting was already 
> defined for email and we do not really want to change those 
> definitions and recommendations. The only thing we are doing 
> here is stressing that you should not just perform nesting 
> for fun. You need a reason to do that.
> 
> Thanks,
> 
> Gonzalo
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Roach | 1 Aug 2008 12:08
Favicon

Re: Alternative SIP Identity Approach (was re: Thoughts on SIP Identity)

On 8/1/08 11:05 AM, Dean Willis wrote:
>
>>
>> Here's the problem... if I trust a B2BUA, it doesn't necessarily mean 
>> that I'll trust everything it trusts. If Bob's UA is going to make an 
>> informed choice, we need it to be able to examine a chain of custody 
>> for the identity, at the very least.
>>
>
> Is the stack of "verified by" parameters in history-Info adequate, or 
> do you want to be able to check each transitive crypto operation?
>
> If the latter, we'd have to do something like add each pre-edit 
> message as a sipfrag body onto the current message. That could make 
> for some rather large SIP requests.  Maybe a diff format could make it 
> better, but it is still going to get chunky.

How many editing boxes do you expect in the middle here?

/a
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 4 comments |

Gmane