Subject: [Sipping] Decision needed on final issue with draft-ietf-sipping-update-pai-07

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 15:18:03 +0100

I need a decision on one outstanding issue. We previously agreed that
PAI could be used in any request. We recently agreed to remove
specification of PAI in responses because there is no standardised means
of authenticating a UAS. Brett Tate pointed out that likewise there is
no standardised means of authenticating a UAC when it sends CANCEL or
ACK (these cannot be challenged, and cannot be rejected if
authentication is wrong). I have so far received no further opinions on
this. To be consistent I believe we have to make exceptions of CANCEL
and ACK and say that PAI cannot be used with these methods.

If I receive no objections by 26th October I will update the draft on
27th.

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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 16:47:02 +0200

> We recently 
> agreed to remove specification of PAI in responses because 
> there is no standardised means of authenticating a UAS. Brett 
> 

So what exactly is the change you are making here.

As far as I am concerned RFC 3325 allowed PAI in responses. There was
some debate a long while ago on this but that is used by many
implementations.

In the 3GPP case, it is based on the P-Called-ID header transferred
internally, i.e. the request was delivered to this terminal which was an
authenticated user based on the registration, and a security association
created at that time. Note that we are making some assumptions here, but
those assumption are valid in this scenario.

So I do not believe you should be changing the underlying RFC 3325 in
this respect.

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Thursday, October 23, 2008 3:18 PM
> To: [email-masked]
> Subject: [Sipping] Decision needed on final issue 
> withdraft-ietf-sipping-update-pai-07
> 
> I need a decision on one outstanding issue. We previously 
> agreed that PAI could be used in any request. We recently 
> agreed to remove specification of PAI in responses because 
> there is no standardised means of authenticating a UAS. Brett 
> Tate pointed out that likewise there is no standardised means 
> of authenticating a UAC when it sends CANCEL or ACK (these 
> cannot be challenged, and cannot be rejected if 
> authentication is wrong). I have so far received no further 
> opinions on this. To be consistent I believe we have to make 
> exceptions of CANCEL and ACK and say that PAI cannot be used 
> with these methods.
> 
> If I receive no objections by 26th October I will update the 
> draft on 27th.
> 
> John
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 15:57:37 +0100

Keith,

The change concerning responses is already made in 07, as a result of
what seemed to be the consensus in SIPPING a couple of weeks ago, after
one of the ADs stated that it would not stand a chance of getting
through IESG. Therefore I reluctantly made the change in 07. Nobody
seemed to be supporting the retention of the response stuff in there at
the time. It doesn't ban PAI in responses, it just does not specify
them, leaving it for a possible future update if/when a standardised
means of authenticating a UAS is available. The relevant text is:
    <t>RFC 3325 is unclear on the use of P-Asserted-Identity in
responses. In contrast to requests, there is no means in SIP to
challenge a UAS to provide SIP digest authentication in a response. As a
result, there is currently no standardised mechanism whereby a proxy can
authenticate a UAS. Since authenticating the source of a message is a
pre-requisite for asserting an identity, this document does not specify
the use of the P-Asserted-Identity header field in responses. This may
be the subject of a future update to RFC 3325. Also this document does
not specify the use of the P-Preferred-Identity header field in
responses, as this would serve no purpose in the absence of the ability
for a proxy to insert the P-Asserted-Identity header field.</t>

So now I just want to know what to do about CANCEL and ACK.

John

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 23 October 2008 15:47
> To: Elwell, John; [email-masked]
> Subject: RE: [Sipping] Decision needed on final issue

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 23 Oct 2008 19:09:42 +0200

Well I am afraid that the text you have included in the existing
version, as detailed below, is not acceptable.

I believe it is usable with constraints in responses, and the text
implies that any RFC 3325 implementation is not allowed to support it.

I do have the discussion, but don't remember a consensus call on this
issue.

Regards

Keith 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, October 23, 2008 3:58 PM
> To: DRAGE, Keith (Keith); [email-masked]
> The change concerning responses is already made in 07, as a 
> result of what seemed to be the consensus in SIPPING a couple 
> of weeks ago, after one of the ADs stated that it would not 
> stand a chance of getting through IESG. Therefore I 
> reluctantly made the change in 07. Nobody seemed to be 
> supporting the retention of the response stuff in there at 
> the time. It doesn't ban PAI in responses, it just does not 
> specify them, leaving it for a possible future update if/when 
> a standardised means of authenticating a UAS is available. 
> The relevant text is:
>     <t>RFC 3325 is unclear on the use of P-Asserted-Identity 
> in responses. In contrast to requests, there is no means in 
> SIP to challenge a UAS to provide SIP digest authentication 
> in a response. As a result, there is currently no 
> standardised mechanism whereby a proxy can authenticate a 
> UAS. Since authenticating the source of a message is a 
> pre-requisite for asserting an identity, this document does 
> not specify the use of the P-Asserted-Identity header field 
> in responses. This may be the subject of a future update to 
> RFC 3325. Also this document does not specify the use of the 
> P-Preferred-Identity header field in responses, as this would 
> serve no purpose in the absence of the ability for a proxy to 
> insert the P-Asserted-Identity header field.</t>
> 
> > > agreed to remove specification of PAI in responses 
> because there is 
> > > no standardised means of authenticating a UAS. Brett
> > > 
> > 
> > internally, i.e. the request was delivered to this terminal 
> which was 
> > an authenticated user based on the registration, and a security 
> > association created at that time. Note that we are making some 
> > assumptions here, but those assumption are valid in this scenario.
> > 
> > > I need a decision on one outstanding issue. We previously agreed 
> > > that PAI could be used in any request. We recently agreed 
> to remove 
> > > specification of PAI in responses because there is no 
> standardised 
> > > means of authenticating a UAS. Brett Tate pointed out 
> that likewise 
> > > there is no standardised means of authenticating a UAC 
> when it sends 
> > > CANCEL or ACK (these cannot be challenged, and cannot be 
> rejected if 
> > > authentication is wrong). I have so far received no 
> further opinions 
> > > on this. To be consistent I believe we have to make exceptions of 
> > > CANCEL and ACK and say that PAI cannot be used with these methods.
> > > 
> > > If I receive no objections by 26th October I will update 
> the draft 
> > > on 27th.
> > > 
> > > 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: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 18:48:57 +0100

Keith,

If this wasn't a consensus call:
http://www.ietf.org/mail-archive/web/sipping/current/msg16231.html
then what do you mean?

John

> Sent: 23 October 2008 18:10

---

From: Dean Willis <[email-masked]>
Date: Thu, 23 Oct 2008 13:46:03 -0500

> If I receive no objections by 26th October I will update the draft on

The problems is that some network architectures DO allow  
authentication of both responses and CANCEL/ACK.

PAI is quite widely used in those networks. In fact, it came to us as  
a P-header for use specifically in those networks.

What is probably needed is an applicability statement that explains  
the environment in which PAI is usable in "digest authenticable  
requests" , and goes on to explain the environment in which PAI is  
usable in other requests and responses.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 03:47:08 +0200

Wel I certainly could not find that message.

But 

That message says remove everything in update PAI on responses.

What you have actually done is put in text on responses that removes it
from RFC 3325, at least in my reading.

Regards

Keith 

> Sent: Thursday, October 23, 2008 6:49 PM
> > > The change concerning responses is already made in 07, as 
> a result 
> > > of what seemed to be the consensus in SIPPING a couple of 
> weeks ago, 
> > > after one of the ADs stated that it would not stand a chance of 
> > > getting through IESG. Therefore I reluctantly made the 
> change in 07. 
> > > Nobody seemed to be supporting the retention of the 
> response stuff 
> > > in there at the time. It doesn't ban PAI in responses, it 
> just does 
> > > not specify them, leaving it for a possible future update 
> if/when a 
> > > standardised means of authenticating a UAS is available.
> > > The relevant text is:
> > > challenge a UAS to provide SIP digest authentication in a 
> response. 
> > > As a result, there is currently no standardised mechanism 
> whereby a 
> > > proxy can authenticate a UAS. Since authenticating the 
> source of a 
> > > message is a pre-requisite for asserting an identity, 
> this document 
> > > does not specify the use of the P-Asserted-Identity 
> header field in 
> > > responses. This may be the subject of a future update to 
> RFC 3325. 
> > > Also this document does not specify the use of the 
> > > P-Preferred-Identity header field in responses, as this 
> would serve 
> > > no purpose in the absence of the ability for a proxy to 
> insert the

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Oct 2008 07:10:47 +0100

Dean,

It seemed that to get the draft through IESG, it needed to cite at least
one mechanism by which a response can be authenticated (likewise ACK and
CANCEL). The mechanism in earlier drafts, whereby the response is
received over a TLS connection over which digest authentication had
previously taken place, was shown to be flawed. Nobody seemed able to
offer a robust and standardised alternative. If somebody can put forward
a robust and standardised alternative that can convince those with
concerns, I would be happy to re-instate the response stuff.

John

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 23 October 2008 19:46
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] Decision needed on final issue with 
> draft-ietf-sipping-update-pai-07
> 
> 
> agreed that
> opinions  
> > on
> the draft on

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Oct 2008 07:15:43 +0100

> Sent: 24 October 2008 02:47
[JRE] It says that the document does not specify use of PAI in
responses, without actually saying that PAI cannot be used in responses.
We can certainly try to clarify those words. Maybe instead of "this
document does not specify the use of the P-Asserted-Identity header
field in responses" we should say that use in responses is outside
scope.

John

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 13:18:46 +0200

To try and put it into words.

If you have a proxy acting as both inbound proxy and outbound proxy and
providing authentication of the user (all of which are pretty much a
given for RFC 3325 usage of P-Preferred/Asserted), and if on
authenticating a user on a previous request you create some sort of
security binding for that user (e.g. a TLS session), then any responses
received over that binding presumably relate to that authenticated user.
That binding can be created at any time (although at least some
implementations will do it at registration), and I believe TLS session
reuse is not uncommon, indeed preferred.

I guess there is still one more assumption here in that the
authenticated identity of the user relates to all transactions used
within that binding, but I guess that is the reason why we have
P-Preferred in the first place, so that if there are three valid
identities for that user, the user can indicate which one is in use. So
if this mechanism is used, the authentication and binding should exist
for all valid identities for that user, and not just for the one used in
the request that created it.

As Dean indicated, this would seem to work for both responses, and for
CANCEL/ACK, although personally I am not interested in CANCEL and ACK
carrying an identity.

Have I missed any other implicit assumptions.

I would note by the way that even for request authentication, if you
want to use straight digest authentication on requests with nothing
else, then you must do it on every request for which you issue an
identity otherwise it is meaningless. I understand that many digest
implementations do not challenge every request.

Regards

Keith

> Sent: Friday, October 24, 2008 7:11 AM
> To: Dean Willis
> Cc: [email-masked]
> It seemed that to get the draft through IESG, it needed to 
> cite at least one mechanism by which a response can be 
> authenticated (likewise ACK and CANCEL). The mechanism in 
> earlier drafts, whereby the response is received over a TLS 
> connection over which digest authentication had previously 
> taken place, was shown to be flawed. Nobody seemed able to 
> offer a robust and standardised alternative. If somebody can 
> put forward a robust and standardised alternative that can 
> convince those with concerns, I would be happy to re-instate 
> the response stuff.
> 
> John
> 
> > > means of authenticating a UAS. Brett Tate pointed out that
> > likewise there is

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 13:22:01 +0200

The problem with the current words is that this document updates RFC
3325, and therefore by implication any statement of scoping implies a
rescoping of RFC 3325.

So you actually need to say that this document makes no change to any
existing or implied usage of identify in responses as defined by RFC
3325 - or alternatively just don't include any mention of responses at
all.

But personally I think we should solve the response issue by identifying
conditions under which it can be valid - see other mail on this subject.

Regards

Keith 

> Sent: Friday, October 24, 2008 7:16 AM
> > What you have actually done is put in text on responses 
> that removes 
> > it from RFC 3325, at least in my reading.
> [JRE] It says that the document does not specify use of PAI 
> in responses, without actually saying that PAI cannot be used 
> in responses.
> We can certainly try to clarify those words. Maybe instead of 
> "this document does not specify the use of the 
> P-Asserted-Identity header field in responses" we should say 
> that use in responses is outside scope.
> 
> John
> 
> 
> 
> > 
> > Regards
> > 
> > Keith
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Oct 2008 13:55:31 +0100

> Sent: 24 October 2008 12:19
> To: Elwell, John; Dean Willis
> Cc: [email-masked]
> Subject: RE: [Sipping] Decision needed on final issue with 
[JRE] This was the example given in earlier drafts, and removed because
it is broken. There is nothing to bind together the entity authenticated
by digest and the entity terminating TLS. A request certainly has to
come via the entity that terminates TLS, but this need not be the same
entity that originates the request. So we could have the following
situation:

+-----+
| UA1 +--------+
+-----+        |        +---------+        +---------+
               +--------+         |        |         |
                        | Proxy 1 +--------+ Proxy 2 |
               +--------|         |        |         |
+-----+        |        +---------+        +---------+
| UA2 +--------+
+-----+

Proxy 2 accepts an inbound TLS connection and over that receives a SIP
request, which it challenges. The next SIP request contain correct
credentials for UA1. Proxy 2 then receives a further SIP request. How
does it know that it comes from UA1 and not UA2, say? In other words,
how does proxy 2 know that there is a proxy 1 (or some other form of SIP
intermediary) between it and UA1?

> implementations do not challenge every request.
[JRE] Understood.

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Oct 2008 13:57:13 +0100

> Sent: 24 October 2008 12:22
> 3325 - 
[JRE] I like this suggestion.

> or alternatively just don't include any mention of responses at
> all.
> 
[JRE] I would like to, but we have to convince everyone concerned that
we have a valid solution.

John

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 24 Oct 2008 15:02:58 +0200

In regard to the example given, I think the restrictions on the
authenticator and the end point of the binding being one and the same
are inherent in establishing a trust domain for RFC 3325 in the first
place. The entity doing the the trust domain must be the first proxy
reached and the entity doing the authentication, and is also the
endpoint of any TLS session.

How is this set up, well there are SIP extensions that allow one to do
this, but I don't think we need to go into details of how trust domains
are configured and used in this document.

If these restructions are not always the case, and I have a hard time
evisaging something that is not, then I have no problem in stating that
as a condition for use in responses.

Regards

Keith 

> Sent: Friday, October 24, 2008 1:56 PM
> To: DRAGE, Keith (Keith); Dean Willis
> Cc: [email-masked]
> > If you have a proxy acting as both inbound proxy and outbound proxy 
> > and providing authentication of the user (all of which are 
> pretty much 
> > a given for RFC 3325 usage of P-Preferred/Asserted), and if on 
> > security binding for that user (e.g. a TLS session), then any 
> > responses received over that binding presumably relate to that 
> > authenticated user.
> [JRE] This was the example given in earlier drafts, and 
> removed because it is broken. There is nothing to bind 
> together the entity authenticated by digest and the entity 
> terminating TLS. A request certainly has to come via the 
> entity that terminates TLS, but this need not be the same 
> Proxy 2 accepts an inbound TLS connection and over that 
> receives a SIP request, which it challenges. The next SIP 
> request contain correct credentials for UA1. Proxy 2 then 
> receives a further SIP request. How does it know that it 
> comes from UA1 and not UA2, say? In other words, how does 
> proxy 2 know that there is a proxy 1 (or some other form of SIP
> > identities for that user, the user can indicate which one 
> is in use. 
> > So if this mechanism is used, the authentication and binding should 
> > exist for all valid identities for that user, and not just 
> for the one 
> > used in the request that created it.
> > 
> > > It seemed that to get the draft through IESG, it needed 
> to cite at 
> > > least one mechanism by which a response can be authenticated 
> > > (likewise ACK and CANCEL). The mechanism in earlier 
> drafts, whereby 
> > > the response is received over a TLS connection over which digest 
> > > authentication had previously taken place, was shown to 
> be flawed. 
> > > Nobody seemed able to offer a robust and standardised 
> alternative. 
> > > If somebody can put forward a robust and standardised alternative 
> > > that can convince those with concerns, I would be happy to 
> > > re-instate the response stuff.
> > > 
> > > John
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Oct 2008 14:25:02 +0100

Keith,

We are talking about requests received from outside a trust domain.

John 

> Sent: 24 October 2008 14:03

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:42:06 -0500

"See IMS". 3GPP references our standards, we can reference theirs.

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2008 16:46:14 -0500

> entity that originates the request. So we could have the following

This scenario drove the requirement for a "P-Asserted-By" header, so  
the transitivity could be tracked. We don't have that header  
defined . . .

However, there are architectures for which the UA can issue a valid  
digest in the response, since the "challenge" per se is handled at the  
SIM level.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 25 Oct 2008 15:56:03 +0100

Dean,

I am looking for somebody to provide some text that could replace or add
to the text in section 3.3, paragraph beginning "Section 5 of RFC 3325
requires". I spoke to Keith yesterday and I think he will try to do so.
Nobody objected to the consensus call to remove the response stuff, and
therefore as editor I removed it. As much as I personally would like to
include PAI in responses in this draft, I have to go along with the WG
consensus, which, until a couple of days ago was to remove it.

If somebody wants to have it re-instated, they should provide the text
AND convince those who objected to the existing text. I am not going to
take the lead.

John

> Sent: 24 October 2008 22:46
> To: Elwell, John
> Cc: DRAGE, Keith (Keith); [email-masked]
> receives a SIP
> > how does proxy 2 know that there is a proxy 1 (or some 
> other form of  
> > SIP

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Oct 2008 22:06:25 -0500

i think Keith is working the same issue I am. His text should resolve  
the immediate concern.

--
Dean