Subject: [Sipping] RE: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt

From: "B, Nataraju" <[email-masked]>
Date: Fri, 18 Aug 2006 11:57:18 +0530

I was thinking making it explicit would be better. 

At least shall we mention this one as normative information? 
Otherwise many more others might think the same way (which I thought earlier) and develop the buggy software... 

Thanks,
Nataraju A B

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, August 17, 2006 6:29 PM
> To: B, Nataraju
> Cc: [email-masked]
> Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt
> 
> 
> 
> B, Nataraju wrote:
> > Paul,
> >
> > What I meant to mention here was that, in the scenarios which might lead
> to these responses must be authenticated before we call for this
> Reponses...
> > 	I mean if we receive a NOTIFY(un-authenticated) 404 should not be
> sent out which will terminate the dialog/usage.
> >
> > 		Authenticate the NTFY request first then only it could be
> rejected with 404 or any other appropriate replies which would result in
> dialog termination.
> 
> If I understand you, this is just standard procedure, applicable
> regardless of dialog usages. Authentication is supposed to be done
> first, so no extra information is given to unauthenticated callers.
> 
> 	Paul
> 
> > Thanks,
> > Nataraju A B
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: Monday, August 14, 2006 7:34 PM
> >> To: B, Nataraju
> >> Cc: [email-masked]
> >> Subject: Re: [Sip] comments on draft-ietf-sipping-dialogusage-02.txt
> >>
> >>
> >>
> >> B, Nataraju wrote:
> >>
> >>> 1. Sec 4 describes what the effects on dialog are and its usages when
> >>> particular responses are received for NOTIFY message, the responses
> 404,
> >>> 410, 416, lead to dialog and its usage termination.
> >>>
> >>>       a. I feel we should have mentioned ONLY the authenticated NOTIFY
> >>> requests will have this effect on the dialogs/usages. Otherwise any
> >>> middle men can trace the message and send the NOTIFY messages which
> >>> terminate the dialogs, which is undesirable ☹. If the entity sending
> >>> NOTIFY really intend to do that it can resend NOTIFY with
> authorization
> >>> credentials which will help to terminate the associated dialogs.
> >> I agree we wouldn't want to enable a MITM attack here.
> >>
> >> But I think that is already covered. If the request isn't properly
> >> authenticated, then the response will be 401, not 404, 410, or 416.
> >>
> >> 	Paul
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Subject:
> > [Sip] comments on draft-ietf-sipping-dialogusage-02.txt
> > From:
> > "B, Nataraju" <[email-masked]>
> > Date:
> > Mon, 14 Aug 2006 12:04:19 +0530
> > To:
> > <[email-masked]>
> >
> > To:
> > <[email-masked]>
> >
> >
> > Hi Sparks,
> >
> >
> >
> > I had gone through the document, here are few comments.
> >
> >
> >
> > Note: I assume the behavior mentioned in sec 4 applies both at client
> receiving these responses (Notifier) and server generating these replies
> (Subscriber). If this was meant to be only @ sender of NOTIFY shall we
> need to mention the similar set of actions @ Subscriber side too?
> >
> >
> >
> > 1. Sec 4 describes what the effects on dialog are and its usages when
> particular responses are received for NOTIFY message, the responses 404,
> 410, 416, lead to dialog and its usage termination.
> >
> >       a. I feel we should have mentioned ONLY the authenticated NOTIFY
> requests will have this effect on the dialogs/usages. Otherwise any middle
> men can trace the message and send the NOTIFY messages which terminate the
> dialogs, which is undesirable ☹. If the entity sending NOTIFY really
> intend to do that it can resend NOTIFY with authorization credentials
> which will help to terminate the associated dialogs.
> >
> >
> >
> >       b. Other alternative would be that let those responses have no
> effect on the dialog/usages, eventually the subscription duration would
> take care of dialog termination or the actual entity would terminate or
> extend the subscription. Any way the request from actual notifier would
> have the proper URIs or credentials which will never lead to these
> responses.
> >
> >
> >
> > The same logic would need to extend for replies 481, 483, 484, 489 and
> 604 also.
> >
> >
> >
> > 2. Sec 4 of the draft
> >
> >
> >
> >     <<<   423 Interval Too Brief: This response won't happen in our
> example
> >
> >       scenario, but if it came in response to a reSUBSCRIBE, the
> >
> >       subscribe usage is not destroyed (or otherwise affected).  No
> >
> >       other usages of the dialog are affected. >>>
> >
> >
> >
> >       In the above Para the meaning of last part of 1st sentence (I
> mean, the subscribe usage is not destroyed (or otherwise affected)) and
> 2nd sentence is not clear, both mention the same meaning? Can we make it
> explicit about what we really mean here ?
> >
> >
> >
> > Thanks,
> >
> > Nataraju A B
> >
> > Sonus Networks India Pvt Ltd
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of 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: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Aug 2006 09:12:57 -0400

> Otherwise many more others might think the same way (which I thought earlier) and develop the buggy software... 

Well, I *thought* it was clear in 3261. But I went back to check, and it 
is far from clear.

Section 8.2 says:

    UASs SHOULD process the requests in the order of the steps that
    follow in this section (that is, starting with authentication, then
    inspecting the method, the header fields, and so on throughout the
    remainder of this section).

which certainly implies that authentication should be done first. 
Unfortunately, the subsections that follow this intro don't mention 
authentication at all. :-(

And, this section pertains to requests outside a dialog, so it doesn't 
really apply anyway.

Section 12, which defines behavior for dialog establishment and requests 
within dialogs doesn't mention authentication or authorization at all.

So I guess it isn't at all clear that that if 401 is applicable to a 
request then it should be issued in preference to 404, 410, or 416, and 
that this should be true inside a dialog as well as outside.

It would be good to get some input from others on this.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Aug 2006 15:40:49 -0500

Sorry for the lag on replying to this thread.

To Nataraju's  primary concern (as I understand it) : We don't really  
have such a thing as
response authentication in SIP (see the many long discussions during  
work on Identity).
The concern you express about a MitM injecting a response that tears  
things down is a known
risk and work on mitigating that risk does not belong in this  
document. I _can_ call it out in the
security considerations section to remind implementer's that it is  
there and that they need to think
about the implications.

Paul's response is pointing to a different place in the handshake -  
that something shouldn't
legitimately issue a 404/410/etc. when a 401 would be more  
appropriate. I'm going through
the document today to prep a version for last call early next month.  
I'll look for a place to call
this out, but off the top of my head, I don't see anywhere that it  
would naturally fit.

RjS

On Aug 18, 2006, at 8:12 AM, Paul Kyzivat wrote:

>
>
> B, Nataraju wrote:
>> I was thinking making it explicit would be better. At least shall  
>> we mention this one as normative information? Otherwise many more  
>> others might think the same way (which I thought earlier) and  
>> develop the buggy software...
>
> Well, I *thought* it was clear in 3261. But I went back to check,  
> and it is far from clear.
>
> Section 8.2 says:
>
> And, this section pertains to requests outside a dialog, so it  
> doesn't really apply anyway.
>
> Section 12, which defines behavior for dialog establishment and  
> requests within dialogs doesn't mention authentication or  
> authorization at all.
>
> So I guess it isn't at all clear that that if 401 is applicable to  
> a request then it should be issued in preference to 404, 410, or  
> 416, and that this should be true inside a dialog as well as outside.
>