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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Wed, 18 Oct 2006 16:04:05 +0200

I would suggest the problem is not the making of the new assertion.

The issue is the removal of the assertion that some other entity made,
that may be equally valid.

Note that this may particularly be an issue in emergency calls, where
PSAPs object to the removal of any information about the user (correct
or incorrect), and in some countries, they may want to believe the
asserter in the trust domain before they believe the user and his
certificate server owner.

Regards

Keith 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 18 October 2006 14:09
> To: [email-masked]
> Cc: Cullen Jennings; SIP; Elwell,John; Jon Peterson; Dan Wing
> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: 
> draft-ietf-sip-connecte d-id entity-01 comments)
> 
> 
> 
> Shida Schubert wrote:
> > 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.
> 
> I don't think this *is* changing the semantics of P-A-ID.
> 
> The semantics are very simple: something in the trust domain 
> determines the identity of the message and inserts to header 
> for the benefit of others in the trust domain. The entity 
> doing the assertion has full latitude about how it determines 
> the identity it asserts.
> 
> What this is doing is providing a new way to make that determination.
> The new way may not be appropriate in all environments, and 
> that's fine.
> 
> > Also, it may generates some issues when P-A-ID already 
> exists in the 
> > message along with connected-identity.
> 
> That part needs to be clarified.
> 
> > Following illustrates potential problems.
> > 
> > connected-id(FROM): [email-masked]
> > P-A-ID: [email-masked]
> > 
> > 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.
> 
> I guess here you are assuming:
> - the P-A-ID was present before the verifier got the message
> - the verifier leaves it in the message when verification fails
> 
> These are assumptions about the interaction of preexisting 
> P-A-ID and connected identity verification. There is an issue 
> there, but there are other possible answers to it.
> 
> > 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.
> 
> IMO the presence of the P-A-ID is not evidence that the 
> verification worked. It is merely in indication that someone 
> in the trust domain asserted this identity. It could be 
> because the verification of the Identity worked, or because 
> some other kind of authentication worked, or it could be 
> because some bogus party within the trust domain lied.
> 
> If you choose to trust the P-A-ID, it means you choose to 
> believe in the trust model. Nothing more.
> 
> > 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:[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
> >>
> >>
> > 
> 
> _______________________________________________
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 10:36:56 -0400

I guess I no longer know exactly what behavior is being proposed.

I thought we were talking about a verifier that would add P-A-ID 
corresponding to an identity that it has successfully verified. I don't 
see how *that* causes any problems. Did someone also talk about removing 
P-A-ID?

If there are other mechanisms for inserting P-A-ID, then there are some 
possible interactions:

- if the verification fails, and there is *already* a P-A-ID present for 
the identity being verified, then if the verifier removes that P-A-ID 
then some problems may result.

- if the verification succeeds, and there is already a P-A-ID with some 
*different* sip identity, then the verifier must remove that old 
identity if it is to add one reflecting the new identity.

These problems can be defined away by saying that in both of these cases 
the verifier should not modify the existing P-A-ID. However that may 
blunt the value of the verifier.

This kind specification for how to handle the interaction probably 
doesn't belong in an ietf document. It seems like a policy for a 
particular trust domain. A draft could state that in these cases the 
verifier should act in accord with local policy.

	Paul