[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Decision needed on final issue with draft-ietf-sipping-update-pai-07
Keith,
We are talking about requests received from outside a trust domain.
John
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> Sent: 24 October 2008 14:03
> To: Elwell, John; Dean Willis
> Cc: sipping at ietf.org
> Subject: RE: [Sipping] Decision needed on final issue with
> draft-ietf-sipping-update-pai-07
>
> In regard to the example given, I think the restrictions on the
> authenticator and the end point of the binding being one and the same
> are inherent in establishing a trust domain for RFC 3325 in the first
> place. The entity doing the the trust domain must be the first proxy
> reached and the entity doing the authentication, and is also the
> endpoint of any TLS session.
>
> How is this set up, well there are SIP extensions that allow one to do
> this, but I don't think we need to go into details of how
> trust domains
> are configured and used in this document.
>
> If these restructions are not always the case, and I have a hard time
> evisaging something that is not, then I have no problem in
> stating that
> as a condition for use in responses.
>
> Regards
>
> Keith
>
> > -----Original Message-----
> > From: sipping-bounces at ietf.org
> > [mailto:sipping-bounces at ietf.org] On Behalf Of Elwell, John
> > Sent: Friday, October 24, 2008 1:56 PM
> > To: DRAGE, Keith (Keith); Dean Willis
> > Cc: sipping at ietf.org
> > Subject: Re: [Sipping] Decision needed on final issue with
> > draft-ietf-sipping-update-pai-07
> >
> >
> >
> > > -----Original Message-----
> > > From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> > > Sent: 24 October 2008 12:19
> > > To: Elwell, John; Dean Willis
> > > Cc: sipping at ietf.org
> > > Subject: RE: [Sipping] Decision needed on final issue with
> > > draft-ietf-sipping-update-pai-07
> > >
> > > To try and put it into words.
> > >
> > > If you have a proxy acting as both inbound proxy and
> outbound proxy
> > > and providing authentication of the user (all of which are
> > pretty much
> > > a given for RFC 3325 usage of P-Preferred/Asserted), and if on
> > > authenticating a user on a previous request you create
> some sort of
> > > security binding for that user (e.g. a TLS session), then any
> > > responses received over that binding presumably relate to that
> > > authenticated user.
> > > That binding can be created at any time (although at least some
> > > implementations will do it at registration), and I believe
> > TLS session
> > > reuse is not uncommon, indeed preferred.
> > [JRE] This was the example given in earlier drafts, and
> > removed because it is broken. There is nothing to bind
> > together the entity authenticated by digest and the entity
> > terminating TLS. A request certainly has to come via the
> > entity that terminates TLS, but this need not be the same
> > entity that originates the request. So we could have the following
> > situation:
> >
> > +-----+
> > | UA1 +--------+
> > +-----+ | +---------+ +---------+
> > +--------+ | | |
> > | Proxy 1 +--------+ Proxy 2 |
> > +--------| | | |
> > +-----+ | +---------+ +---------+
> > | UA2 +--------+
> > +-----+
> >
> > Proxy 2 accepts an inbound TLS connection and over that
> > receives a SIP request, which it challenges. The next SIP
> > request contain correct credentials for UA1. Proxy 2 then
> > receives a further SIP request. How does it know that it
> > comes from UA1 and not UA2, say? In other words, how does
> > proxy 2 know that there is a proxy 1 (or some other form of SIP
> > intermediary) between it and UA1?
> >
> > >
> > > I guess there is still one more assumption here in that the
> > > authenticated identity of the user relates to all
> transactions used
> > > within that binding, but I guess that is the reason why we have
> > > P-Preferred in the first place, so that if there are three valid
> > > identities for that user, the user can indicate which one
> > is in use.
> > > So if this mechanism is used, the authentication and
> binding should
> > > exist for all valid identities for that user, and not just
> > for the one
> > > used in the request that created it.
> > >
> > > As Dean indicated, this would seem to work for both
> > responses, and for
> > > CANCEL/ACK, although personally I am not interested in
> > CANCEL and ACK
> > > carrying an identity.
> > >
> > > Have I missed any other implicit assumptions.
> > >
> > > I would note by the way that even for request
> > authentication, if you
> > > want to use straight digest authentication on requests
> with nothing
> > > else, then you must do it on every request for which you issue an
> > > identity otherwise it is meaningless. I understand that
> many digest
> > > implementations do not challenge every request.
> > [JRE] Understood.
> >
> > John
> >
> > >
> > > Regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: sipping-bounces at ietf.org
> > > > [mailto:sipping-bounces at ietf.org] On Behalf Of Elwell, John
> > > > Sent: Friday, October 24, 2008 7:11 AM
> > > > To: Dean Willis
> > > > Cc: sipping at ietf.org
> > > > Subject: Re: [Sipping] Decision needed on final issue with
> > > > draft-ietf-sipping-update-pai-07
> > > >
> > > > Dean,
> > > >
> > > > It seemed that to get the draft through IESG, it needed
> > to cite at
> > > > least one mechanism by which a response can be authenticated
> > > > (likewise ACK and CANCEL). The mechanism in earlier
> > drafts, whereby
> > > > the response is received over a TLS connection over
> which digest
> > > > authentication had previously taken place, was shown to
> > be flawed.
> > > > Nobody seemed able to offer a robust and standardised
> > alternative.
> > > > If somebody can put forward a robust and standardised
> alternative
> > > > that can convince those with concerns, I would be happy to
> > > > re-instate the response stuff.
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Dean Willis [mailto:dean.willis at softarmor.com]
> > > > > Sent: 23 October 2008 19:46
> > > > > To: Elwell, John
> > > > > Cc: sipping at ietf.org
> > > > > Subject: Re: [Sipping] Decision needed on final issue with
> > > > > draft-ietf-sipping-update-pai-07
> > > > >
> > > > >
> > > > > On Oct 23, 2008, at 9:18 AM, Elwell, John wrote:
> > > > >
> > > > > > I need a decision on one outstanding issue. We previously
> > > > > agreed that
> > > > > > PAI could be used in any request. We recently agreed
> > to remove
> > > > > > specification of PAI in responses because there is no
> > > > standardised
> > > > > > means of authenticating a UAS. Brett Tate pointed out that
> > > > > likewise there is
> > > > > > no standardised means of authenticating a UAC when it sends
> > > > > CANCEL or
> > > > > > ACK (these cannot be challenged, and cannot be rejected if
> > > > > > authentication is wrong). I have so far received no further
> > > > > opinions
> > > > > > on
> > > > > > this. To be consistent I believe we have to make exceptions
> > > > > of CANCEL
> > > > > > and ACK and say that PAI cannot be used with these methods.
> > > > > >
> > > > > > If I receive no objections by 26th October I will update
> > > > > the draft on
> > > > > > 27th.
> > > > >
> > > > > The problems is that some network architectures DO allow
> > > > > authentication of both responses and CANCEL/ACK.
> > > > >
> > > > > PAI is quite widely used in those networks. In fact, it
> > > > came to us as
> > > > > a P-header for use specifically in those networks.
> > > > >
> > > > > What is probably needed is an applicability statement
> > > that explains
> > > > > the environment in which PAI is usable in "digest
> authenticable
> > > > > requests" , and goes on to explain the environment in
> > > which PAI is
> > > > > usable in other requests and responses.
> > > > >
> > > > > --
> > > > > Dean
> > > > >
> > > > >
> > > > _______________________________________________
> > > > Sipping mailing list
> > https://www.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use
> > > > sip-implementors at cs.columbia.edu for questions on
> current sip Use
> > > > sip at ietf.org for new developments of core SIP
> > > >
> > >
> > _______________________________________________
> > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors at cs.columbia.edu for questions on current
> > sip Use sip at ietf.org for new developments of core SIP
> >
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP