Subject: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Sep 2008 08:35:40 +0100

I received no feedback in the changes made in draft-05 concerning the
forward compatibility mechanism, nor on the particular issue I asked for
comments on:
http://www.ietf.org/mail-archive/web/sipping/current/msg16105.html
Therefore I assume these changes are acceptable.

So we have the one remaining issue concerning response authentication.
We had some list discussion on this, the last one being on 20th August:
http://www.ietf.org/mail-archive/web/sipping/current/msg16121.html

The use of PAI in responses is something that needs clarifying, because
RFC 3325 is ambiguous (sometimes it talks about SIP messages, other
times it specifically talks about requests). In one place it actually
states "message (request or response)".

So I think we have the following options:

1. Say nothing about responses at all, thereby leaving us with the
ambiguity that exists in RFC 3325. I don't think this is a sensible
option. A lot of the value of updating RFC 3325 is lost if we don't
tackle the response ambiguity issue.

2. Clarify the situation by stating that PAI (and PPI) MUST NOT be used
in responses. I would be very reluctant to go down this path, since I
know there is a lot of use of PAI in responses (e.g., in 3GPP).

3. Devise a mechanism that exploits TLS to achieve authenticated
response identity and use this in the update-pai draft. As Cullen
pointed out, this needs to be a separate and non-trivial piece of work,
probably done in the SIP WG. Waiting for this would hold up update-pai
for a considerable time.

4. Go ahead with the present update-pai draft, leaving it open how to
achieve authentication of a response. The present example of how to do
this (towards the end of section 3.3) is broken, so would have to be
removed, or at least qualified.

Any other options?

My preference is for option 4. Please let me know which options you
would prefer and which you would definitely not be happy with.

John

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 3 Sep 2008 10:14:34 -0600

> Therefore I assume these changes are acceptable.

Uh, be careful with this sort of assumption. Unless you have consensus  
for significant technical changes, you should not be making them to WG  
documents. I'm trying to separating technical changes from editorial  
changes here - obviously I think the editor should just make editorial  
changes and technical changes which either have, or clearly would  
have, census.  This change is not backwards compatible with some 3325  
implementations and I don't think you have consensus one way or the  
other on it. Silence does not necessarily imply people agree - I  
suspect few people have read this. Perhaps my recollection of how this  
went in the meeting is wrong - I have not gone back and looked at the  
notes.
> removed, or at least qualified.
Saying is "MUST NOT be used"  is not the right path since at least  
some people want to leave the door open to adding this in future  
specifications. Describing how to do is not something that should be  
done as an update to 3325 because the solution to response identity  
have a wider implication than just PAI - if we are going to do that,  
we should do it in some separate draft in SIP. If folks agree with  
that, it seems like something along lines of option 4 is the right  
path where we say that PAI is not currently defined for responses but  
future specifications may do so. I think it is also important for the  
draft to document some of the reasons around why it is not defined for  
responses.
> would prefer and which you would definitely not be happy with.

Cullen <in my individual contributor roll>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 03 Sep 2008 17:37:13 +0100

Cullen, 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 03 September 2008 17:15
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] Further proceeding with 
> draft-ietf-sipping-update-pai--05
> 
> 
> > forward compatibility mechanism, nor on the particular 
> issue I asked  
> > for
> > comments on:
> documents.
> I'm trying to separating technical changes from editorial  
[JRE] I hope the changes reflect what we seemed to be reaching consensus
on in the meeting. Obviously I wanted to confirm that consensus on the
mailing list, as well as confirming that I had implemented it correctly
in draft-05.
However, looking at the minutes, I see it states "Another draft can
address forward-compatibility issues...". I came away with the feeling
that people wanted a forward compatibility requirement placed in the
document right now, i.e., in the next draft, draft-05. I see now that
the minutes can be interpreted a different way, i.e., in a completely
separate draft. If I had misinterpreted the mood of the meeting on this
aspect, we can certainly go back to the text of 04. Other opinions?
Nobody shouted when draft-05 appeared, which is why I sent the reminder
today.

> draft to document some of the reasons around why it is not 
[JRE] Your proposal seems to be a toned down version of option 4, but
basically I agree - its just a matter of finding the right words. Let's
see what other opinions we get.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Sep 2008 12:48:55 -0400

Given that (3) looks to be a lot of work, I think that (4) is the best 
alternative.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 3 Sep 2008 14:01:53 -0600

> Nobody shouted when draft-05 appeared, which is why I sent the  

Who knows what the minutes meant, as you point out could have been  
either :-) I assumed that it a different draft not a revision. I did  
not mean to make a big deal of it one way or other - I have not gone  
back looked an minutes, meeting recordings, mailing traffic, or even  
the changes made from 04 to 05. I just meant to say in general be  
careful of assuming silence is agrement - particular when it is prime  
vacation time and right after a meeting. Some times it is agreement,  
while other times that assumptions results in the draft getting  
exploded at the next meeting.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 19 Sep 2008 16:58:05 -0500

Hi all, 

There was not tremendous response to John's query for consensus on this
document (perhaps due to summer holidays as Cullen suggested). 

At this point, with two responses (Paul and Cullen), text (TBD) around
option 4 is the most popular, but we really need feedback from others to
move this forward. I will ping the other past reviewers in another email
(so that responses to the thread don't get too many addressees) but we
would really appreciate if others would respond. 

Thanks, 
Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Wednesday, September 03, 2008 11:37 AM
To: Cullen Jennings
Cc: sipping
Subject: Re: [Sipping] Further proceeding with
draft-ietf-sipping-update-pai--05

Cullen, 

> documents.
> I'm trying to separating technical changes from editorial changes here

> - obviously I think the editor should just make editorial changes and 
> technical changes which either have, or clearly would have, census.  
> This change is not backwards compatible with some 3325 implementations

> and I don't think you have consensus one way or the other on it. 
> Silence does not necessarily imply people agree - I suspect few people

> have read this. Perhaps my recollection of how this went in the 
> meeting is wrong - I have not gone back and looked at the notes.

> > The use of PAI in responses is something that needs clarifying, 
> > because RFC 3325 is ambiguous (sometimes it talks about SIP 
> > messages, other times it specifically talks about requests). In one 
> > place
> it actually
> > 2. Clarify the situation by stating that PAI (and PPI) MUST NOT be 
> > used in responses. I would be very reluctant to go down this
> path, since I
> > pointed out, this needs to be a separate and non-trivial piece of 
> > work, probably done in the SIP WG. Waiting for this would hold up
> update-pai
> > for a considerable time.
> >

John
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 19 Sep 2008 17:55:36 -0500

I think we really need to see the exact words...

This is what we say in RFC 4916 (for connected identity for RFC 4474):

   The provision of the identity of the responder in a response
   (commonly called "response identity") is outside the scope of this
   document.

      Note that even if identity were to be conveyed somehow in a
      response, there would in general be difficulty authenticating the
      UAS.  Providing identity in a separate request allows normal
      authentication techniques to be used.

Is this statement useful? I don't think so.

I am not sure why we believe that response identity IN THIS CONTEXT is any
more vulnerable than request indentity. For RFC4474-style secure request
identity, sure, but in the case of PAI, requests are not authenticated in
the first place.

I re-read section 2.2 of  http://tools.ietf.org/html/draft-peterson-sipping-retarget-00 which described the problem of response-identity, and they
really dealt with forking and it's negative impact on authenticated
response identity. I hardly see why this is relevant here with P-AID since
it's not like we will use P-AID with RFC 4474 in the first place.

Or am I missing something?

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Barnes, Mary 
> (RICH2:AR00)
> Sent: Friday, September 19, 2008 14:58
> To: Elwell, John; Cullen Jennings
> Cc: sipping
> There was not tremendous response to John's query for 
> consensus on this document (perhaps due to summer holidays as 
> Cullen suggested). 
> 
> At this point, with two responses (Paul and Cullen), text 
> (TBD) around option 4 is the most popular, but we really need 
> feedback from others to move this forward. I will ping the 
> other past reviewers in another email (so that responses to 
> the thread don't get too many addressees) but we would really 
> appreciate if others would respond. 
> 
> Thanks,
> Mary.
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> changes here
> [JRE] I hope the changes reflect what we seemed to be 
> reaching consensus on in the meeting. Obviously I wanted to 
> confirm that consensus on the mailing list, as well as 
> confirming that I had implemented it correctly in draft-05.
> However, looking at the minutes, I see it states "Another 
> draft can address forward-compatibility issues...". I came 
> away with the feeling that people wanted a forward 
> compatibility requirement placed in the document right now, 
> i.e., in the next draft, draft-05. I see now that the minutes 
> can be interpreted a different way, i.e., in a completely 
> separate draft. If I had misinterpreted the mood of the 
> meeting on this aspect, we can certainly go back to the text 
> of 04. Other opinions?
> Nobody shouted when draft-05 appeared, which is why I sent 
> the reminder today.
> 
> > >
> > >
> [JRE] Your proposal seems to be a toned down version of 
> option 4, but basically I agree - its just a matter of 
> finding the right words. Let's see what other opinions we get.
> 
> John
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Sep 2008 16:47:13 +0100

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 19 September 2008 23:56
> To: Mary Barnes; Elwell, John; Cullen Jennings
> Cc: sipping
> Subject: RE: [Sipping] Further proceeding with 
[JRE] OK, I will try to propose some.

> identity, sure, but in the case of PAI, requests are not 
[JRE] They are supposed to be. Unless a proxy has authenticated the UA,
it has no right to assert an identity (unless just passing on an
assertion from an upstream entity that is trusted in accordance with
Spec(T)). Now whether this is adhered to in practice is another matter,
but I don't think we should relax this in an RFC.

John

> 
> I re-read section 2.2 of  
> http://tools.ietf.org/html/draft-peterson-sipping-retarget-00 
> which described the problem of response-identity, and they

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Sep 2008 16:48:20 +0100

Although there have been very few opinions expressed, those that have
been expressed seem to be roughly along the lines of my earlier option 4
("Go ahead with the present update-pai draft, leaving it open how to
achieve authentication of a response. The present example of how to do
this (towards the end of section 3.3) is broken, so would have to be
removed, or at least qualified.")

In draft-05, section 3.3 states:
"      <t>Section 5 of RFC 3325 requires a proxy to authenticate the
originator of a message before adding a P-Asserted-Identity header field
to the forwarded message. In practice there is no SIP means to
authenticate the sender of a SIP response message. However,
authentication may be possible by other means. For example, if the proxy
has TLS connectivity with the originator of the response and has
previously authenticated the connected entity (e.g., using SIP digest
authentication at registration time), then the originator of the
response can be considered to be authenticated. In such circumstances it
is permissible for a proxy to insert a P-Asserted-Identity header field
in a SIP response.</t>"

I would propose to change this to:
"      <t>Section 5 of RFC 3325 requires a proxy to authenticate the
originator of a message before adding a P-Asserted-Identity header field
to the forwarded message. How this is achieved is outside the scope of
this document.</t>"

And then in 4.2.2 it states:
"        <t>The proxy behaviour specified in RFC 3325 is applicable to
responses with the following qualifications. A proxy that receives a
response from a node outside the Trust Domain cannot directly
authenticate the UAS by SIP means. Therefore it MUST NOT include a
P-Asserted-Identity header field when forwarding the response unless it
has authenticated the UAS by other means.</t>
        <t><list>
          <t>One possible circumstance in which a proxy can include a
P-Asserted-Identity header field when forwarding a response from a node
outside the Trust Domain is when the proxy has direct TLS connectivity
with the UAS and has authenticated the UA by some other means (e.g., SIP
digest authentication) during that same TLS session.</t>
        </list></t>"

I would propose to change this to:
"        <t>The proxy behaviour specified in RFC 3325 is applicable to
responses with the following qualifications. A proxy MUST NOT include a
P-Asserted-Identity header field when forwarding the response unless it
has authenticated the UAS by some means. The means to authenticate the
UAS is outside the scope of this document.</t>

Comments?

John

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 22 Sep 2008 11:21:53 -0500

> > I am not sure why we believe that response identity IN THIS 
> CONTEXT is 
> > any more vulnerable than request indentity. For 
> RFC4474-style secure 
> > request identity, sure, but in the case of PAI, requests are not 
> > authenticated in the first place.
> [JRE] They are supposed to be. Unless a proxy has 
> authenticated the UA, it has no right to assert an identity 
> (unless just passing on an assertion from an upstream entity 
> that is trusted in accordance with Spec(T)). Now whether this 
> is adhered to in practice is another matter, but I don't 
> think we should relax this in an RFC.

So are we talking about HTTP-digest here?

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 22 Sep 2008 11:25:08 -0500

I think we need to be a little more specific on what we mean by
authentication.

I don't believe the reader will get a good feel of why a response
is different from a request in regards to authentication.

So if we added something like "Unlike requests, responses are
not authenticated using bla-bla". And then keep the rest the
same as per John's text. 

> Sent: Monday, September 22, 2008 08:48
> To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> Cullen Jennings
> Cc: sipping
> Subject: [Sipping] Proposed text for update-pai concerning 
> response identity (was RE: Further proceeding with 
> draft-ietf-sipping-update-pai--05)
> 
> Although there have been very few opinions expressed, those 
> that have been expressed seem to be roughly along the lines 
> of my earlier option 4 ("Go ahead with the present update-pai 
> draft, leaving it open how to achieve authentication of a 
> response. The present example of how to do this (towards the 
> end of section 3.3) is broken, so would have to be removed, 
> or at least qualified.")
> 
> originator of a message before adding a P-Asserted-Identity 
> header field to the forwarded message. In practice there is 
> no SIP means to authenticate the sender of a SIP response 
> message. However, authentication may be possible by other 
> means. For example, if the proxy has TLS connectivity with 
> the originator of the response and has previously 
> authenticated the connected entity (e.g., using SIP digest 
> authentication at registration time), then the originator of 
> the response can be considered to be authenticated. In such 
> circumstances it is permissible for a proxy to insert a 
> P-Asserted-Identity header field in a SIP response.</t>"
> 
> originator of a message before adding a P-Asserted-Identity 
> header field to the forwarded message. How this is achieved 
> is outside the scope of this document.</t>"
> 
> responses with the following qualifications. A proxy that 
> receives a response from a node outside the Trust Domain 
> cannot directly authenticate the UAS by SIP means. Therefore 
> it MUST NOT include a P-Asserted-Identity header field when 
> forwarding the response unless it has authenticated the UAS 
> by other means.</t>
>         <t><list>
>           <t>One possible circumstance in which a proxy can 
> include a P-Asserted-Identity header field when forwarding a 
> response from a node outside the Trust Domain is when the 
> proxy has direct TLS connectivity with the UAS and has 
> authenticated the UA by some other means (e.g., SIP digest 
> authentication) during that same TLS session.</t>
>         </list></t>"
> 
> responses with the following qualifications. A proxy MUST NOT 
> include a P-Asserted-Identity header field when forwarding 
> the response unless it has authenticated the UAS by some 
> means. The means to authenticate the UAS is outside the scope 
> of this document.</t>
> 
> Comments?
> 
> John
> 
> 
> 
> > which described the problem of response-identity, and they really 
> > dealt with forking and it's negative impact on 
> authenticated response 
> > identity. I hardly see why this is relevant here with P-AID 
> since it's 
> > not like we will use P-AID with RFC 4474 in the first place.
> > 
> consensus on 
> > > this document (perhaps due to summer holidays as Cullen 
> suggested).
> > > 
> > > feedback from others to move this forward. I will ping the other 
> > > past reviewers in another email (so that responses to the thread 
> > > don't get too many addressees) but we would really appreciate if 
> > > others would respond.
> > > 
> > > Thanks,
> > > Mary.
> > > 
> > > [JRE] I hope the changes reflect what we seemed to be reaching 
> > > consensus on in the meeting. Obviously I wanted to confirm that 
> > > consensus on the mailing list, as well as confirming that I had 
> > > implemented it correctly in draft-05.
> draft can 
> > > address forward-compatibility issues...". I came away with the 
> > > feeling that people wanted a forward compatibility requirement 
> > > placed in the document right now, i.e., in the next 
> draft, draft-05. 
> > > I see now that the minutes can be interpreted a different 
> way, i.e., 
> > > in a completely separate draft. If I had misinterpreted 
> the mood of 
> > > the meeting on this aspect, we can certainly go back to 
> the text of 
> > > 04. Other opinions?
> > > Nobody shouted when draft-05 appeared, which is why I sent the 
> > > reminder today.
> > > 
> > > > >
> > > > >
> > > > > We had some list discussion on this, the last one 
> being on 20th
> > > > > August:
> > > > > 
> > > [JRE] Your proposal seems to be a toned down version of option 4, 
> > > but basically I agree - its just a matter of finding the right 
> > > words. Let's see what other opinions we get.
> > > 
> > > John
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Sep 2008 13:42:09 -0500

Elwell, John wrote:
>  been expressed seem to be roughly along the lines of my earlier
> option 4 ("Go ahead with the present update-pai draft, leaving it
> open how to achieve authentication of a response.

John: I went back and re-read the thread.  By and large, I would
also put myself in the camp of option 4.  But more inline.

> The present example of how to do this (towards the end of section
> 3.3) is broken, so would have to be removed, or at least qualified.")
> 
> In draft-05, section 3.3 states: "      <t>Section 5 of RFC 3325
> requires a proxy to authenticate the originator of a message before
> adding a P-Asserted-Identity header field to the forwarded message.
> In practice there is no SIP means to authenticate the sender of a SIP
> response message. However, authentication may be possible by other
> means. For example, if the proxy has TLS connectivity with the
> originator of the response and has previously authenticated the
> connected entity (e.g., using SIP digest authentication at
> registration time), then the originator of the response can be
> considered to be authenticated. In such circumstances it is
> permissible for a proxy to insert a P-Asserted-Identity header field 
> in a SIP response.</t>"
> 
> I would propose to change this to: "      <t>Section 5 of RFC 3325
> requires a proxy to authenticate the originator of a message before
> adding a P-Asserted-Identity header field to the forwarded message.
> How this is achieved is outside the scope of this document.</t>"

S3.3 is about inclusion of PAI and PPI in responses.  With your
suggested change, it still remains unclear on whether you are
referring to a request or response when you write "Section 5 of
RFC3325 requires a proxy to authenticate the originator of
a message ..."

You then go on to say that a UAS can insert a PAI/PPI in
responses, so I assume that the gist of the problem we
are grappling with whether or not a proxy can insert PAI/PPI?

To that extent, I think it will be much cleaner if you
completely took out the paragraph "Section 5 of RFC 3325 ... in
a SIP response", and instead, defer the discussion of a proxy
inserting PAI/PPI responses in S4.2.2 where it really belongs.

If you have to insert some text about proxies inserting PAI/PPI
headers in response in S3.3, say something along these lines:

   This section explores the inclusion of a PAI/PPI header
   in a response by a UAS; the analogous discussion on whether
   or not a proxy can include such headers in a response is
   in S4.2.2.

> And then in 4.2.2 it states: "        <t>The proxy behaviour
> specified in RFC 3325 is applicable to responses with the following
> qualifications. A proxy that receives a response from a node outside
> the Trust Domain cannot directly authenticate the UAS by SIP means.
> Therefore it MUST NOT include a P-Asserted-Identity header field when
> forwarding the response unless it has authenticated the UAS by other
> means.</t> <t><list> <t>One possible circumstance in which a proxy
> can include a P-Asserted-Identity header field when forwarding a
> response from a node outside the Trust Domain is when the proxy has
> direct TLS connectivity with the UAS and has authenticated the UA by
> some other means (e.g., SIP digest authentication) during that same
> TLS session.</t> </list></t>"
> 
> I would propose to change this to: "        <t>The proxy behaviour
> specified in RFC 3325 is applicable to responses with the following
> qualifications. A proxy MUST NOT include a P-Asserted-Identity header
> field when forwarding the response unless it has authenticated the
> UAS by some means. The means to authenticate the UAS is outside the
> scope of this document.</t>

I would suggest something along these lines, including Francois'
comments:

   <t>Section 5 of RFC 3325 requires a proxy to authenticate the
   originator of a message before adding a P-Asserted-Identity
   header field  to the forwarded message.  While this works for
   requests, it does not for responses since unlike requests,
   responses are not challenged by a proxy, nor is the authenticity
   of the sender of the response established.  In practice, there
   is no authoritative manner by which a SIP proxy can authenticate
   the originator of the response.  Therefore, a proxy MUST NOT
   include a P-Asserted-Identity header field when forwarding the
   response unless it has authenticated the UAS by some means.
   The means to authenticate the UAS is currently outside the
   scope of this document; however future documents may further
   define techniques for response authentication.</t>

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Sep 2008 10:57:14 +0100

Vijay,

Thanks for your detailed proposals. See below. 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 22 September 2008 19:42
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] Proposed text for update-pai 
> concerning response identity (was RE: Further proceeding with 
> that have
[JRE] I think 3.3 would be incomplete without saying something about
proxy insertion of PAI in a response, but I agree it could be clearer.

>    or not a proxy can include such headers in a response is
[JRE] I would prefer not to do it this way, since section 3 is the
discussion section and section 4 is the normative part. I think it would
be better to substructure 3.3, such that 3.3 itself talks about response
identity in general, 3.3.1 talks about insertion of PAI/PPI by a UAS,
and 3.3.2 talks about insertion of PPI by a proxy.

>    define techniques for response authentication.</t>
[JRE] I think words similar to these would fit better into the new
3.3.2. I am not sure about the word "authoritative" - perhaps
"standardised" would be better.

I will post a new version and take further comments on that.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Sep 2008 10:57:33 +0100

Francois,

I agree in principle, but see also Vijay's comments and my response. I
will post a new version.

John 

> Sent: 22 September 2008 17:25
> To: Elwell, John; Mary Barnes; Cullen Jennings
> Cc: sipping
> Subject: RE: [Sipping] Proposed text for update-pai 
> > >       response, there would in general be difficulty 
> authenticating 
> > > the
> option 4,

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Sep 2008 11:44:41 +0100

> Sent: 22 September 2008 17:22
[JRE] Not necessarily.

John

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Sep 2008 17:27:03 -0600

Just as a note on what I have often seen from security ADs ...

If the document has a statement like, "Before exploding the phone, the  
UA MUST authenticate the request", often ADs look for there to be at  
least one way to authenticate the request that is mandatory to  
implement.

Cullen