Subject: RE: [Sip] Re: Rejecting connected identity (was RE: draft-ietf-si p-connected-id entity-01 comments)

From: "Elwell, John" <[email-masked]>
Date: Sun, 24 Sep 2006 09:55:19 +0100

Shida,

When I said 428 was not a problem, what I meant was that RFC 4474 leaves it
as a matter of policy whether to send 428. So in connected-identity we could
recommend use of a policy that avoids sending 428 to mid-dialog requests.
This would not be a problem in that it would not violate RFC 4474.

So your scenario would work if policy at the caller's UA is not to send 428
to a mid-dialog request that does not contain Identity. 

John

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 23 September 2006 03:42
> To: Paul Kyzivat
> Cc: Elwell, John; Cullen Jennings; SIP
> Subject: Re: [Sip] Re: Rejecting connected identity (was RE: 
> draft-ietf-sip-connected-id entity-01 comments)
> 
> 
> Hi;
> 
> I thought about this a bit, and with connected-identity even 428
> seems to be somewhat problematic.
> 
> Imagine a scenario where call with SIP-identity+"id-change" tag
> gets forked to 2UAs served by different domains. UA1 whose
> domain provides Identity service and UA2 whose domain does not
> provide identity service. (Both UAs are compliant to 
> connected-identity)
> 
> UA2 beats the race and established the call and sends back an UPDATE
> without SIP-identity and gets rejected with 428 because its 
> domain does
> not provide identity services.
> 
> If there was a way to indicate the need of sip-identity in return, we
> might be able to avoid this problem as call can be forwarded 
> using this
> indication to the domain supporting the identity services but 
> as of now I
> don't think there is anything we can do to avoid this. So I am leaning
> towards
> changing the verifier's behavior a bit more lenient when it's 
> dealing with
> mid-dialog identity.
> 
> Regards
> Shida
> 
> 
> Paul Kyzivat wrote:
> > John,
> >
> > I want to hear what others, especially Jon and Cullen, have to say
> > about this.
> >
> > It is of some concern to me that a call might fail because of some
> > problem with the identity mechanism when the same call might have
> > succeeded in the absence of any identity.
> >
> > But possibly the solution to this is policy in the implementation of
> > the verifier. What to do in the case of the conditions that lead to
> > these errors could be configurable in the verifier: either 
> to generate
> > the error or simply to remove the identity info from the 
> message. And
> > the policy could conceivably vary based on attributes of 
> the message,
> > such as whether it is in-dialog or not.
> >
> > Does it require a change to 4474 to permit that kind of policy?
> >
> > It would be annoying if the end user had no control over 
> the insertion
> > and verification of identity, and it resulted in calls failing that
> > the user would like to permit. But I suppose that is itself a policy
> > decision. There are certainly enterprises that want to 
> exert that kind
> > of control over what users are permitted to do.
> >
> > Paul
> >
> > Elwell, John wrote:
> >> Paul,
> >>
> >> I agree with most of your points, and on reflection I think I agree
> >> that the
> >> solution has to be with the verifier.
> >>
> >> I think RFC 4474 is not a problem as far as sending a 428 
> 'Use Identity
> >> Header' response is concerned, because that is left to 
> policy, so we
> >> could
> >> say in connected-identity that policy should be to not send 428.
> >>
> >> However, 436, 437 and 438 responses are all a problem, because RFC
> >> 4474 says
> >> that they MUST be sent under respective conditions. Interestingly,
> >> though,
> >> there are other failure scenarios that can arise from the 
> procedures of
> >> section 6 of RFC 4474 for which no normative statement is given on
> >> how to
> >> respond, e.g. invalid Date header field, signer not 
> authoritative for
> >> the
> >> domain.
> >>
> >> So one way to solve the present problem would be for the
> >> connected-identity
> >> draft to modify verifier behaviour in RFC 4474 in the case 
> of mid-dialog
> >> requests. I guess this would mean that it would update RFC 4474 as
> >> well as
> >> updating RFC 3261. But I don't like this, because it seems 
> to remove
> >> some of
> >> the security properties of RFC 4474.
> >>
> >> Another way would be to accept that 436, 437 and 438 responses will
> >> be sent,
> >> and failure to verify a signature will therefore result in 
> inability to
> >> process the UPDATE or re-INVITE request, and hence if the UPDATE or
> >> re-INVITE request was for some other purpose such as session timer
> >> refresh
> >> or modifying the session, that action will fail. Then the call will
> >> fail (in
> >> the case of inability to refresh the session timer) or the session
> >> modification will fail. I guess this is somewhat analogous 
> to caller ID
> >> verification failure in an INVITE request - it is impossible to
> >> establish a
> >> call if verification fails. Moreover, the UAC has no ability to
> >> rectify the
> >> situation, since it is at the mercy of a proxy-based Authentication
> >> Service
> >> that puts a rogue Identity header field in every request. In the
> >> connected
> >> identity case, the only difference is that the call is already
> >> established
> >> but is likely to fail if verification fails.
> >>
> >> Of course, if the mid-dialog request is indeed from the 
> wrong source,
> >> then
> >> sending a 436, 437 or 438 response is indeed the correct 
> thing to do,
> >> and
> >> overriding the verification procedures of RFC 4474 would indeed be
> >> the wrong
> >> thing to do. So perhaps we just have to accept that these response
> >> codes can
> >> be received and will lead to failure.
> >>
> >> So, my preferred way forward is simply to recommend not 
> sending a 428
> >> and
> >> accept the consequences of other responses that the 
> verifier might send.
> >>
> >> John
> >>
> >>> -----Original Message-----
> >>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 22 September
> >>> 2006 15:13
> >>> To: Elwell, John
> >>> Cc: Cullen Jennings; SIP
> >>> Subject: Re: [Sip] RE: 
> draft-ietf-sip-connected-identity-01 comments
> >>>
> >>>
> >>>
> >>> Elwell, John wrote:
> >>>>> From: Cullen Jennings [mailto:[email-masked]] When an 
> Update is
> >>>>> sent. Are there any conditions under which it might be rejected.
> >>>>> Bad identity for example. I think that might need a little
> >>>>> discussion and also what the UA does when it sends 
> >>> an update
> >>>>> with a no identity and it gets rejected.
> >>>> [JRE] A very good point. We don't want to get to a 
> >>> situation where it is
> >>>> impossible to perform a mid-dialog request (e.g., for 
> >>> purposes such as
> >>>> session timer refresh or session re-negotiation) just 
> >>> because connected
> >>>> identity fails.
> >>>> My proposed fix is as follows:
> >>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request 
> >>> with 428 'Use
> >>>> Identity Header'.
> >>> I'm not sure about this. At the least I think this one needs some
> >>> clear explanation of the SHOULD NOT - about the conditions when it
> >>> can be violated.
> >>>
> >>> I see this as somewhat analogous to doing a digest challenge on an
> >>> in-dialog request. In some cases it is the right thing to do.
> >>>
> >>> A UA that imposes such a requirement will be limited in 
> what it can
> >>> do, but that may still be right in some cases.
> >>>
> >>>> 2. Say that an Authentication Service MUST NOT add an 
> >>> Identity header field
> >>>> to a mid-dialog request if a previous request on that 
> >>> dialog has resulted in
> >>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or 
> >>> 438 'Invalid
> >>>> Identity Header'.
> >>> This requirement would force the authentication service 
> to be dialog
> >>> stateful, which is not ideal. Better to push the state 
> back into the
> >>> sender of the request. This may require a way for the UAC to tell
> >>> the authentication service not to act.
> >>>
> >>>> 3. Say that a UAC MUST repeat a mid-dialog request that 
> >>> results in one of
> >>>> these responses if the mid-dialog request was not solely 
> >>> for the purpose of
> >>>> connected identity. If solely for the purpose of connected 
> >>> identity there is
> >>>> no point in repeating it, so I will say "SHOULD NOT take 
> any further
> >>>> action".
> >>> This seems wrong to me.
> >>>
> >>> I think that the remedy to these is in the verifier. The 
> purpose of
> >>> the verifier is ultimately to drive an authorization decision. If
> >>> authorization would succeed in the absence of the 
> identity, then the
> >>> request should be permitted to continue as if the identity was not
> >>> present.
> >>>
> >>> Unfortunately this would seem to require a revision to 4474 even
> >>> though the paint is hardly dry on it.
> >>>
> >>> If this is done, then there is no need of a mechanism to cause the
> >>> authentication service *not* to authenticate. If this is 
> *not* done,
> >>> then that need remains, which will still require a change to 4474.
> >>>
> >>> Paul
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>
> >
> > _______________________________________________
> > 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
> >
> >
> 

_______________________________________________
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

---

From: Shida Schubert <[email-masked]>
Date: Sun, 24 Sep 2006 21:27:34 -0700

Hi John;

I agree to your statement.
What you noted below would solve my concern.

Thanks
Shida