[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments)
Paul,
Your message arrived just after I had submitted 02, so your comments are not
taken into account in that version. However, I felt it was useful to get 02
out as a baseline for further discussion.
It seems the remaining issue is whether to add an explicit indication of
removal of the Identity header field by a verifier that has been unable to
verify the signature. Whilst this may make sense, I am concerned it starts
to go beyond the scope of connected-identity, so I would like other
opinions, especially from the chairs and from the authors of Identity.
John
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 05 October 2006 16:29
> To: Elwell, John
> Cc: Cullen Jennings; Jon Peterson; SIP
> Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
> draft-ietf-si p-connecte d-id entity-01 comments)
>
>
>
> Elwell, John wrote:
> > Paul,
> >
> > So your proposal is that the connected-identity RFC should
> update RFC 4474
> > to somehow relax rules at a verifier. Correct?
>
> Yeah, I think so.
>
> > So the next question concerns the way in which these rules should be
> > relaxed. One problem with the verifier not being located at
> the UAS but at
> > some proxy is that the UAS might be configured always to
> trust identities
> > received in requests via the verifier's proxy if an
> Identity header field is
> > present, on the assumption that the signature has been
> checked by the
> > verifier. Therefore it sounds like the verifier, if it does
> not reject a
> > request with a bad signature, should remove the Identity
> header field (and
> > also Identity-Info) before forwarding the request towards
> the target.
>
> (I think I have seen someone propose combining the use of
> Identity and
> P-Asserted-Identity, though I don't recall the details, or
> which draft
> it was. So what I am about to say might bear no relationship to that.)
>
> I could see how Identity might be used between trust domains, while
> P-Asserted-Identity is used within a trust domain. In that case, a
> verifier might run at the entry point to a trust domain and if
> verification succeeds, insert a P-Asserted-Identity header with a
> corresponding identity. It then might, or might not, remove
> the Identity
> header. Recipients within the trust domain could then use
> P-Asserted-Identity as the source of identity info. (In this
> scenario,
> an identity header would only be added to requests when they
> leave the
> trust domain.)
>
> In this kind of environment, it is only necessary for the verifier to
> omit the P-Asserted-Identity header when verification fails.
>
> > Under what conditions should a verifier remove an Identity
> header field
> > rather than rejecting with 436/437/438? My inclination
> would be to leave it
> > as a matter of policy as far as the update to RFC 4474 is
> concerned, and
> > then make more precise statements concerning mid-dialog requests.
> > Alternatively the update to RFC 4474 could just relax the rules for
> > mid-dialog requests. I think there is some merit in
> relaxing the rules in
> > general, because otherwise there might be situations where
> a legitimate
> > caller cannot establish a call because an Authentication
> Service (outside
> > the UAC's control) is inserting an unverifiable signature (e.g., in
> > Identity-Info placing a URL that the Verifier cannot
> dereference for some
> > reason).
>
> What you say sounds reasonable to me.
>
> There is however some risk to having a verifier remove identity. The
> problem would be when there are potentially multiple verifiers that
> don't trust one another. If an early one removes the header, then it
> prevents a subsequent verifier from doing its own verification.
>
> This could come up if a request transits a domain on the way
> to another
> domain. Each domain may wish to do its own verification.
>
> That is an advantage to having the verifier add something to
> the request
> to indicate the result of its verification.
>
> > One consequence of the Verifier being separated from the
> UAS is that we
> > don't want to rely on stateful behaviour at the Verifier or
> its proxy (for
> > similar reasons that you cited for the Authentication
> Service earlier). So
> > for mid-dialog requests we would need to mandate, or at
> least recommend,
> > that 436/437/438 should not be sent.
>
> Right.
>
> Paul
>
> > John
> >
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> >> Sent: 03 October 2006 01:44
> >> To: Elwell, John
> >> Cc: Cullen Jennings; Jon Peterson; SIP
> >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
> >> draft-ietf-sip-connecte d-id entity-01 comments)
> >>
> >>
> >>
> >> Elwell, John wrote:
> >>> Thinking further on this, perhaps there is a 4th way:
> >>>
> >>> 4. Specify that if a UAS rejects a mid-dialog request with
> >> 436, 437 or 438,
> >>> then it MUST NOT invoke the verifier for a subsequent request
> >> This assumes that the verifier is invoked by the UAS, and
> not by some
> >> proxy in front of the UAS. Isn't it valid to have a verifier
> >> in a proxy
> >> before the UAS? This rule would forbid that, because it would
> >> cause that
> >> proxy to be call stateful.
> >>
> >> I think it would just be better to update the RFC, even
> >> though that is a
> >> bit more trouble than not to.
> >>
> >> Paul
> >>
> >>> on the same
> >>> dialog unless the From header field URI has changed, and in
> >> such cases
> >>> SHOULD NOT make use of the unverified connected-identity.
> >> Then a UAC, on
> >>> receiving 436, 437 or 438, MUST repeat the request once.
> >> This would allow
> >>> business as usual on this dialog (but without the benefit
> >> of connected
> >>> identity, therefore no worse than at present). It avoids
> >> any change to RFC
> >>> 4474, because verification is optional anyway.
> >>>
> >>> Would this work?
> >>>
> >>> John
> >>>
> >>>> -----Original Message-----
> >>>> From: Elwell, John
> >>>> Sent: 26 September 2006 21:02
> >>>> To: Cullen Jennings; Jon Peterson
> >>>> Cc: SIP; Paul Kyzivat
> >>>> Subject: FW: Rejecting connected identity (was RE:
> >>>> draft-ietf-sip-connected-id entity-01 comments)
> >>>>
> >>>> Cullen, Jon,
> >>>>
> >>>> In case you missed this (it wasn't addressed directly to
> >>>> you), I would greatly appreciate an opinion from each of you
> >>>> on this remaining issue in connected-identity. Just to
> >>>> summarise, RFC 4474 leaves it up to policy whether to return
> >>>> a 428 response if Identity is missing, but mandates the
> >>>> sending of a 436, 437 or 438 response for certain errors
> >>>> arising while verifying the signature. It seems that for mid
> >>>> dialog requests this behaviour could be harmful. What does
> >>>> the UAC for the mid dialog request do if it receives 436, 437
> >>>> or 438? If the mid-dialog request was solely for the purpose
> >>>> of connected identity, it can give up and allow the call to
> >>>> continue as is. But if the request was for some other purpose
> >>>> (e.g., renegotiating the session because of hold, say, or
> >>>> session timer refresh), the UAC really wants it to work. For
> >>>> the normal case where the Authentication Service is at a
> >>>> proxy, not at the UAC, the UAC cannot force the
> >>>> Authentication Service to refrain from putting this
> >>>> unverifiable signature in the mid-dialog request, so any
> >>>> attempts to repeat the request would most likely be doomed to
> >>>> getting the same response.
> >>>>
> >>>> It seems there are three things we could do, none very
> attractive:
> >>>> 1. Get connected-identity to modify the procedures of RFC
> >>>> 4474 for a verifier by softening the requirements for sending
> >>>> 436, 437 and 438 in response to mid-dialog requests. But then
> >>>> a mid-dialog request from a rogue source would be accepted.
> >>>> 2. Say that the Authentication Service should omit the
> >>>> signing of mid-dialog requests if a previous attempt has
> >>>> resulted in 436, 437 or 438. But this implies statefulness
> >> at the AS.
> >>>> 3. Accept the fact the mid-dialog requests can fail in this
> >>>> way and therefore things like session refresh and session
> >>>> renegotiation cannot be done, probably resulting in call
> >>>> failure. Sounds bad, but it is no different from an initial
> >>>> INVITE request, where there is nothing the UAC can do if the
> >>>> AS inserts an Identity header that gets rejected with 436,
> >> 437 or 438.
> >>>> John
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> >>>>> Sent: 22 September 2006 19:26
> >>>>> To: Elwell, John
> >>>>> Cc: Cullen Jennings; SIP
> >>>>> Subject: Re: Rejecting connected identity (was RE:
> >>>>> draft-ietf-sip-connected-id entity-01 comments)
> >>>>>
> >>>>> 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: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
> >>>
> >
>
_______________________________________________
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