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

["Jesske, R" <R.Jesske at t-com.net>]

> Lastly, if P-A-ID value is used in some context, changing the value
> may cause some problem as well(Assuming P-A-ID was there but a
> different value from FROM value > verifier after verification succeeds
> change the P-A-ID value to that of FROM).

As I commented in an other mail. There should be never a change of the P-Asserted-Identity. That is not the intension of the P-Asserted-Identity to be updated because the connected-ID in the From was verified by some mechanism.
Many Services like PBX, Forwarding, billing in IMS are based on the P-Asserted-Identity as it is now and assumes that it will not be changed.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Shida Schubert [mailto:shida at ntt-at.com] 
> Gesendet: Mittwoch, 18. Oktober 2006 01:53
> An: Paul Kyzivat
> Cc: Cullen Jennings; SIP; Elwell, John; Jon Peterson; Dan Wing
> Betreff: Re: [Sip] RE: Rejecting connected identity (was RE: 
> draft-ietf-si p-connecte d-id entity-01 comments)
> 
> 
> 
> Although using P-A-ID may look like a good approach for this,
> I don't know if it's really a good idea as it seems to change the
> semantics of P-A-ID.
> 
> Also, it may generates some issues when P-A-ID already exists
> in the message along with connected-identity.
> 
> Following illustrates potential problems.
> 
> connected-id(FROM): carol at b.com
> P-A-ID: carol at b.com
> 
> Now, following the proposal by John when Case 2 is deployed,
> and assuming the verification of identity failed, it will 
> still forward
> the message as it is if we allow Case 2. When UAS receives the request
> it will see both the identity-info/header and P-A-ID with the value
> equivalent to the value in the FROM header.. If UAS has no ability
> to verify the signature itself, it will assume that the verification
> worked. P-A-ID looks like a good place to indicate the success of
> the verification but it might need something else.
> 
> As for Cullen's comments. I agree with Paul here, if the security
> policy at the verification side would allow request without identity,
> it should forward the request even if the verification fails.
> 
> Lastly, if P-A-ID value is used in some context, changing the value
> may cause some problem as well(Assuming P-A-ID was there but a
> different value from FROM value > verifier after verification succeeds
> change the P-A-ID value to that of FROM).
> 
> Regards
> Shida
> 
> Paul Kyzivat wrote:
> >
> >
> > Cullen Jennings wrote:
> >>
> >> I'm generally on board with things like you are suggesting 
> below and
> >> what is suggested in draft-rosenberg-sip-identity-coexistence.
> >> However, I want to think very carefully about the security 
> properties
> >> of not rejecting things that failed based on security properties -
> >> I'm not sure what I think of this yet.
> >>
> >> Any time you allow a security action that failed to 
> continue sending
> >> the request downstream, you run the risk that something 
> further down
> >> stream assumes that the security action worked because it must have
> >> happened upstream. Clearly from a security point of view 
> it would be
> >> better not to have upstream elements do the security 
> validation for a
> >> downstream element but we did decide long ago that when doing
> >> Identity we were going to allow for this so that we could migrate
> >> from UAs that do not support Identity to system that does.
> >>
> >> So let me flip this around the other way and ask - do we 
> really need
> >> to allow for a request that failed verification to not result in an
> >> error? 
> >
> > I think the poster child for this is when the error is 437 
> Unsupported
> > Certificate.
> >
> > In this case the caller may be trapped. It has an identity 
> service it
> > can't control, that unconditionally adds an identity. And then the
> > callee has an authentication verifier in front of it. As 
> things stand,
> > that verifier is required to reject requests with certs it doesn't
> > understand, even in cases where it will permit requests with no
> > identity at all.
> >
> > Paul
> >
> >> Are there use cases where the verification would fail and we really
> >> do want to continue with the message? If these cases would only
> >> happen in a fairly broken system, then it might not be worth the
> >> security problems they would cause. I don't know what I think but I
> >> am interested in where we might need this and if there 
> might be other
> >> ways to skin the cat in those situations.
> >>
> >> Cullen
> >>
> >>
> >> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote:
> >>
> >>> John,
> >>>
> >>> What you outline below is exactly what I had in mind.
> >>>
> >>> Paul
> >>>
> >>> Elwell, John wrote:
> >>>> Paul,
> >>>> Dan Wing made a suggestion that P-Asserted-Identity 
> would fulfil your
> >>>> requirement. I guess it would work like this.
> >>>> A Verifier not located at the UAS would attempt to verify the
> >>>> signature in
> >>>> the Identity header field.
> >>>> - Case A - verification succeeds. The Verifier inserts into the
> >>>> forwarded
> >>>> request a P-Asserted-Identity header field containing 
> the verified
> >>>> URI (from
> >>>> the From header field) in the forwarded request. The Identity and
> >>>> Identity-Info header fields will still be present and 
> available should
> >>>> another verifier be encountered downstream.
> >>>> - Case B - verification fails but request not rejected. The
> >>>> verifier is
> >>>> unable to verify (e.g., because it can't dereference the URL) but
> >>>> according
> >>>> to policy does not reject the request. It simply forwards the
> >>>> request as is.
> >>>> If there is a further verifier downstream, that too can 
> attempt to
> >>>> verify
> >>>> the signature.
> >>>> - Case C - verification fails but request is rejected. 
> The verifier is
> >>>> unable to verify (e.g., bad signature) and according to policy it
> >>>> rejects
> >>>> the request.
> >>>> A UAS that does not contain a verifier can simply use
> >>>> P-Asserted-Identity,
> >>>> if present.
> >>>> This seems to have some synergy with
> >>>> draft-rosenberg-sip-identity-coexistence. In fact the 
> relaxation of
> >>>> rules
> >>>> concerning rejection by a verifier that is unable to verify a
> >>>> signature
> >>>> might be beneficial to that proposal.
> >>>> I will omit discussion of the mechanics of documentation until I
> >>>> see what
> >>>> reaction there is to the technical proposal.
> >>>> John
> >>>>> -----Original Message-----
> >>>>> From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: 09 October
> >>>>> 2006 13:54
> >>>>> 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,
> >>>>>>
> >>>>>> 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.
> >>>>> Sure. I too am interested in seeing other inputs on 
> this subject.
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> Rather than adding something to indicate that identity has been
> >>>>> *removed* due to failure to verify, I am advocating adding
> >>>>> something to indicate that verification has *succeeded*, while
> >>>>> leaving the identity header in place. In this way, a downstream
> >>>>> element may *either* trust the info added by the verifier or do
> >>>>> its own verification of the identity header.
> >>>>>
> >>>>> Of course this is only significant if the verifier is doing work
> >>>>> for downstream elements, and not for itself.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>> 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
> >
> >
> 
> 
> _______________________________________________
> 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