[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)
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> 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: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