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

[Shida Schubert <shida at ntt-at.com>]

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