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

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Oct 2006 20:56:45 +0100

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 11 October 2006 17:56
> To: Cullen Jennings
> Cc: Elwell, John; Jon Peterson; SIP; Dan Wing; Jonathan Rosenberg
> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: 
> draft-ietf-si p-connecte d-id entity-01 comments)
> 
> 
> 
> 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.
[JRE] Equally 436 is difficult. An Identity Service the caller can't control
is inserting a signature based on a certificate that a verifier that the
callee can't control can't dereference. IMO, the only response code in RFC
4474 that perhaps does justify an unconditional MUST is 438.

John
> 
> 	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:[email-masked]] 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:[email-masked]] 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:[email-masked]] 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:[email-masked]] 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:[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