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

From: "B, Nataraju" <[email-masked]>
Date: Tue, 29 Aug 2006 11:32:00 +0530

Hi Sparks, 

My original important comment was that, an un-authenticated NOTIFY should not terminate any dialog. 

The other one was of less priority one, which you addressed in your mail earlier... 

Thanks,
Nataraju A B
> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, August 29, 2006 2:11 AM
> To: Paul Kyzivat
> Cc: B, Nataraju; [email-masked]
> Subject: Re: [Sipping] Re: [Sip] comments on draft-ietf-sipping-
> dialogusage-02.txt
> 
> 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:
> >
> >    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
> >
> >> 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

_______________________________________________
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