Subject: Re: [Sipping] [Sipping]Questions on draft-ietf-sipping-connect-re use-reqs-00

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Jun 2003 17:48:17 -0700

Hi Nicole,

On Thursday, May 22, 2003, at 05:12 AM, Nicole Johnson wrote:

> Thanks for the clarification.
>
> I have two comments about the second security mechanism discussed in 
> section
> 4.1 of this draft.
>
> 1. The draft states that, for a server to accept an alias, the target
> address of that alias must previously have been registered with the 
> server.
> However, this mechanism is only as secure as the REGISTER itself.  For
> example, if the REGISTER is not integrity-checked, a man-in-the-middle 
> could
> alter the contact address in the REGISTER.

the attack you describe is on the Registration function.  The alias is 
at least as secure as the registration policy of the registrar.

> I think the draft should recommend that the REGISTER also be
> integrity-checked using S/MIME and a sipfrag bodypart containing the
> Contact.  I would be happy to propose some text.  Alternatively, if I 
> have
> misunderstood the proposed mechanism, please let me know where I have 
> gone
> wrong.

Digest actually works fine here.

> 2.  It is not clear how this mechanism could be used to reuse 
> connections
> between two proxies in a secure manner.  Would each proxy have to 
> REGISTER
> its address with the other?

no, TLS mutual authentication is more than sufficient in this case.

thanks,
-rohan

> Thanks,
> Nicole
>
> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, May 20, 2003 9:09 PM
> To: Nicole Johnson
> Cc: [email-masked]'
> Subject: Re: [Sipping] [Sipping]Questions on
> draft-ietf-sipping-connect-reuse-reqs-00
>
>
> Hi,
>
> On Thursday, May 15, 2003, at 07:23 AM, Nicole Johnson wrote:
>
>> I have a couple of questions about
>> draft-ietf-sipping-connect-reuse-reqs-00.
>
>> 1.  Intended scope of alias parameter.
>>
>> Is the aim of this draft to enable connections to be reused within a
>> single
>> dialog, or across multiple dialogs, i.e. can an alias learned within
>> the
>> scope of one dialog be used in another?  Is the alias parameter valid
>> on
>> out-of-dialog requests?
>
> across multiple dialogs.  it would work on out-of-dialog requests (ex:
> OPTIONS).
> perhaps these should be explicit requirements?
>
>> 2.  Target address fails to authenticate.
>>
>> If a server receives a request containing the alias parameter and the
>> target
>> address of the request fails authentication, how should the server
>> react?
>
> it should not create the alias.
>
>> It could drop the message, respond to the target address with a "not
>> authorized" response, or continue processing the request as if the
>> "alias"
>> parameter was not present.  Is there a recommended behaviour?
>
> the behavior for handling the request should then do whatever normally
> happens when a request without an alias parameter arrives with failed
> or missing authentication.  frequently this is fine and will result in
> a digest authentication challenge (401 or 407).
>
> hope this makes sense.
>
> thanks,
> -rohan
>
>> Thanks,
>> Nicole
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Nicole Johnson <[email-masked]>
Date: Fri, 13 Jun 2003 11:45:47 +0100

Rohan,

Thanks for these answers.  A couple of comments below.  

Thanks,
Nicole

>Sent: Saturday, June 07, 2003 1:48 AM
>To: Nicole Johnson
>Cc: [email-masked]'
>draft-ietf-sipping-connect-re use-reqs-00>
>
>
>Hi Nicole,
>
>

Agreed, but I suggest that the second mechanism could be clarified by adding
"If Digest authentication is used, integrity protection should be applied
and the client should add a sipfrag bodypart containing the contact header."

<snip>

> a digest authentication challenge (401 or 407).

Following on from this, on receipt of the challenge response the client will
send another request with an Authorization header.  My concern is that even
if the credentials in the Authorization header are OK the target address has
still not been authenticated so the server will respond with another
401/407.  In this case, wouldn't it be better for the server to respond to
the original request with, for example, 403 Forbidden?

Thanks,
Nicole