[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)
Well, with just the three of us in agreement, I am not sure whether this is
consensus. Anyway, let's assume the technical solution described below,
where a verifier inserts P-Asserted-Identity in the forwarded request if
verification is successful. Where would be the appropriate place to document
this? I fear it would be stretching the scope of connected-identity too far
to add it there. It might be better to put it into a separate document that
updates RFC 4474. Such a document could in fact cover both updates to 4474:
- insertion of PAI if verification successful;
- leaving it up to policy whether to reject with 436/437/438 if error
conditions occur.
A separate document would have the advantage that it could apply to
caller-identity as well as connected-identity. Perhaps
draft-rosenberg-sip-identity-coexistence could fulfil that role.
John
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 10 October 2006 14:20
> To: Elwell, John
> Cc: Cullen Jennings; SIP; Dan Wing; Jon Peterson
> Subject: Re: [Sip] RE: Rejecting connected identity (was RE:
> draft-ietf-si p-connecte d-id entity-01 comments)
>
> 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