[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Rejecting connected identity (was RE: draft-ietf-sip-connected-id entity-01 comments)
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:pkyzivat at cisco.com]
> 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:fluffy at cisco.com]
>
> >> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip