Subject: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 4

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Feb 2008 12:02:42 +0000

A comment I received on the previous draft
(draft-elwell-sipping-update-pai-02) suggested that we must be precise
(at least in the normative section) as to the conditions under which a
proxy may assert an identity in the response. One approach would be to
say that the only acceptable condition is that given as an example
(i.e., 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)). Are there any
other acceptable conditions?

Any opinions?

John

_______________________________________________
Sipping mailing list  http://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: "Hisham Khartabil" <[email-masked]>
Date: Wed, 20 Feb 2008 15:27:48 +1100

I wouldn't limit it to TLS. I would say any security association is
acceptable.

Hisham

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Feb 2008 19:09:40 +0000

Hisham,
 
On the one hand, within a trust domain TLS is the only mechanism
allowed, so this would be in line with that. However, here we are
talking about a response from a UAS outside the trust domain. In the UAC
case we accept digest authentication, but that can't be used with a UAS.
So perhaps this justifies more flexibility in the case of the UAS.
Jonathan wanted to limit it to TLS, so I guess I would like other
opinions.
 
John

________________________________

	From: Hisham Khartabil [mailto:[email-masked]] 
	Sent: 20 February 2008 04:28
	To: Elwell, John
	Cc: [email-masked]
	Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open
issue 4

	I wouldn't limit it to TLS. I would say any security association
is acceptable.
	 
	Hisham

		A comment I received on the previous draft
		(draft-elwell-sipping-update-pai-02) suggested that we
must be precise
		(at least in the normative section) as to the conditions
under which a
		proxy may assert an identity in the response. One
approach would be to
		say that the only acceptable condition is that given as
an example
		(i.e., 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)).
Are there any
		other acceptable conditions?
		
		Any opinions?
		
		John
		
		_______________________________________________
		Sipping mailing list
http://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: "Hisham Khartabil" <[email-masked]>
Date: Thu, 21 Feb 2008 09:25:12 +1100

Hi John,

Remeber IMS, who make very very extensive use of P-Asserted-Identity, uses
IPSec and security associations. Surely that's good enough.

Thanks,
Hisham

On 21/02/2008, Elwell, John <[email-masked]> wrote:
>
>  Hisham,
>
> On the one hand, within a trust domain TLS is the only mechanism allowed,
> so this would be in line with that. However, here we are talking about a
> response from a UAS outside the trust domain. In the UAC case we accept
> digest authentication, but that can't be used with a UAS. So perhaps this
> justifies more flexibility in the case of the UAS. Jonathan wanted to limit
> it to TLS, so I guess I would like other opinions.
>
> John
>
>  ------------------------------
> *From:* Hisham Khartabil [mailto:[email-masked]]
> *Sent:* 20 February 2008 04:28
> *To:* Elwell, John
> *Cc:* [email-masked]
> *Subject:* Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 4
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 07:27:27 +0000

Hisham,
 
That is true, but RFC 3325 mandates TLS (with a particular crypto suite)
for use within a trust domain. In using IPSec IMS does not comply with
RFC 3325.
 
Now, you can ask whether RFC 3325 should be updated to allow IPSec in
the way IMS uses it, but I haven't heard any requests to do that yet. I
am surprised such a request has not come from 3GPP, who were the people
who requested PAI in the first place.
 
John

	From: Hisham Khartabil [mailto:[email-masked]] 
	Sent: 20 February 2008 22:25
	To: Elwell, John
	Cc: [email-masked]
	Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open
issue 4

	Hi John,
	 
	Remeber IMS, who make very very extensive use of
P-Asserted-Identity, uses IPSec and security associations. Surely that's
good enough.
	 
	Thanks,
	Hisham

		Hisham,
		 
		On the one hand, within a trust domain TLS is the only
mechanism allowed, so this would be in line with that. However, here we
are talking about a response from a UAS outside the trust domain. In the
UAC case we accept digest authentication, but that can't be used with a
UAS. So perhaps this justifies more flexibility in the case of the UAS.
Jonathan wanted to limit it to TLS, so I guess I would like other
opinions.
		 
		John

			From: Hisham Khartabil
[mailto:[email-masked]] 
			Sent: 20 February 2008 04:28
			To: Elwell, John
			Cc: [email-masked]
			Subject: Re: [Sipping]
draft-ietf-sipping-udate-pai-00 - open issue 4

			I wouldn't limit it to TLS. I would say any
security association is acceptable.
			 
			Hisham

			On 14/02/2008, Elwell, John
<[email-masked]> wrote: 

				A comment I received on the previous
draft
				(draft-elwell-sipping-update-pai-02)
suggested that we must be precise
				(at least in the normative section) as
to the conditions under which a
				proxy may assert an identity in the
response. One approach would be to
				say that the only acceptable condition
is that given as an example
				(i.e., 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)). Are there any
				other acceptable conditions?
				
				Any opinions?
				
				John

_______________________________________________
				Sipping mailing list
http://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: "Horvath, Ernst" <[email-masked]>
Date: Thu, 21 Feb 2008 10:02:17 +0100

John,
 
actually RFC 3325 requires a scurity agreement that is called 'Spec(T)'
in the RFC. An example 'Spec(T)' using TLS is described for information
only. I think IPSec would also fullfil the requirement.
 
Ernst

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Elwell, John
	Sent: Thursday, February 21, 2008 8:27 AM
	To: Hisham Khartabil
	Cc: [email-masked]
	Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open
issue 4

	Hisham,
	 
	That is true, but RFC 3325 mandates TLS (with a particular
crypto suite) for use within a trust domain. In using IPSec IMS does not
comply with RFC 3325.
	 
	Now, you can ask whether RFC 3325 should be updated to allow
IPSec in the way IMS uses it, but I haven't heard any requests to do
that yet. I am surprised such a request has not come from 3GPP, who were
the people who requested PAI in the first place.
	 
	John

		From: Hisham Khartabil
[mailto:[email-masked]] 
		Sent: 20 February 2008 22:25
		To: Elwell, John
		Cc: [email-masked]
		Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 -
open issue 4

		Hi John,

		Thanks,
		Hisham

		On 21/02/2008, Elwell, John <[email-masked]>
wrote: 

			Hisham,
			 
			On the one hand, within a trust domain TLS is
the only mechanism allowed, so this would be in line with that. However,
here we are talking about a response from a UAS outside the trust
domain. In the UAC case we accept digest authentication, but that can't
be used with a UAS. So perhaps this justifies more flexibility in the
case of the UAS. Jonathan wanted to limit it to TLS, so I guess I would
like other opinions.
			 
			John

				From: Hisham Khartabil

				I wouldn't limit it to TLS. I would say
any security association is acceptable.
				 
				Hisham

				
				Any opinions?
				
				John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 09:07:58 +0000

Ernst,

RFC 3325 section 3 states:
"Connections between nodes within the Trust Domain and between
         UAs and nodes in the Trust Domain MUST use TLS using a cipher
         suite of RSA_WITH_AES_128_CBC_SHA1.  Mutual authentication
         between nodes in the trust domain MUST be performed and
         confidentiality MUST be negotiated."
Maybe the RFC is inconsistent.

John

	From: Horvath, Ernst 
	Sent: 21 February 2008 09:02
	To: Elwell, John; Hisham Khartabil
	Cc: [email-masked]
	Subject: RE: [Sipping] draft-ietf-sipping-udate-pai-00 - open
issue 4

	John,
	 
	actually RFC 3325 requires a scurity agreement that is called
'Spec(T)' in the RFC. An example 'Spec(T)' using TLS is described for
information only. I think IPSec would also fullfil the requirement.
	 
	Ernst

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Elwell, John
		Sent: Thursday, February 21, 2008 8:27 AM
		To: Hisham Khartabil
		Cc: [email-masked]
		Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 -
open issue 4

		Hisham,
		 
		That is true, but RFC 3325 mandates TLS (with a
particular crypto suite) for use within a trust domain. In using IPSec
IMS does not comply with RFC 3325.
		 
		Now, you can ask whether RFC 3325 should be updated to
allow IPSec in the way IMS uses it, but I haven't heard any requests to
do that yet. I am surprised such a request has not come from 3GPP, who
were the people who requested PAI in the first place.
		 
		John

			From: Hisham Khartabil

			Hi John,

			Thanks,
			Hisham

			On 21/02/2008, Elwell, John
<[email-masked]> wrote: 

				Hisham,
				 
				On the one hand, within a trust domain
TLS is the only mechanism allowed, so this would be in line with that.
However, here we are talking about a response from a UAS outside the
trust domain. In the UAC case we accept digest authentication, but that
can't be used with a UAS. So perhaps this justifies more flexibility in
the case of the UAS. Jonathan wanted to limit it to TLS, so I guess I
would like other opinions.
				 
				John

					From: Hisham Khartabil

					 
					Hisham

					A comment I received on the
previous draft
	
(draft-elwell-sipping-update-pai-02) suggested that we must be precise
					(at least in the normative
section) as to the conditions under which a
					proxy may assert an identity in
the response. One approach would be to
					say that the only acceptable
condition is that given as an example
					(i.e., 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)). Are there any
					other acceptable conditions?
					
					Any opinions?
					
					John

_______________________________________________
					Sipping mailing list
http://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: "Horvath, Ernst" <[email-masked]>
Date: Thu, 21 Feb 2008 10:15:41 +0100

John,

the text you cite is item 3. from section 11, Example of Spec(T), which
is marked as non-normative. Section 12, Security Considerations, even
mentions IPSec explicitly as a means of providing transport security.

Ernst

> -----Original Message-----
> From: Elwell, John 
> Sent: Thursday, February 21, 2008 10:08 AM
> To: Horvath, Ernst; 'Hisham Khartabil'
> Cc: [email-masked]'
> Subject: RE: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 4
> 
> Ernst,
> 
> 	Subject: RE: [Sipping] draft-ietf-sipping-udate-pai-00 
> - open issue 4
> 	
> 	
> 	John,
> 	 
> 	actually RFC 3325 requires a scurity agreement that is 
> called 'Spec(T)' in the RFC. An example 'Spec(T)' using TLS 
> is described for information only. I think IPSec would also 
> fullfil the requirement.
> 	 
> 	Ernst
> 
> 
> particular crypto suite) for use within a trust domain. In 
> using IPSec IMS does not comply with RFC 3325.
> 		 
> 		Now, you can ask whether RFC 3325 should be 
> updated to allow IPSec in the way IMS uses it, but I haven't 
> heard any requests to do that yet. I am surprised such a 
> request has not come from 3GPP, who were the people who 
> requested PAI in the first place.
> 		 
> 		John
> 
> 
> 			Remeber IMS, who make very very 
> extensive use of P-Asserted-Identity, uses IPSec and security 
> associations. Surely that's good enough.
> 			 
> 			Thanks,
> 			Hisham
> 			
> 			 
> 				On the one hand, within a trust 
> domain TLS is the only mechanism allowed, so this would be in 
> line with that. However, here we are talking about a response 
> from a UAS outside the trust domain. In the UAC case we 
> accept digest authentication, but that can't be used with a 
> UAS. So perhaps this justifies more flexibility in the case 
> of the UAS. Jonathan wanted to limit it to TLS, so I guess I 
> 					(at least in the 
> normative section) as to the conditions under which a
> 					proxy may assert an 
> identity in the response. One approach would be to
> 					say that the only 
> acceptable condition is that given as an example
> 					(i.e., 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)). Are there any

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 09:24:28 +0000

Ernst,

OK, my mistake. I saw the header "3. Security requirements" and didn't
pick up the fact that it was a sub-heading of 11, since that was
scrolled off the top of my screen.

In that case I agree that a Spec-T can specify IPSec. But that is only
within a trust domain. The issue that Hisham raised is between a UAS and
a proxy where the UAS is not in the trust domain. Jonathan wants to tie
it down, Hisham doesn't. We need other opinions.

John

> [mailto:[email-masked]] On Behalf Of Horvath, Ernst
> Sent: 21 February 2008 09:16
> Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 4
> 
> John,
>

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 21 Feb 2008 10:33:48 +0100

John,

on the real issue, I don't see why we should be more restrictive on the
"last hop" than within the trust domain. IOW, if IPSec is acceptable
between proxies, why should it not be acceptable towards the UAS?

Ernst

> Sent: Thursday, February 21, 2008 10:24 AM
> To: Horvath, Ernst; Hisham Khartabil
> Cc: [email-masked]
> OK, my mistake. I saw the header "3. Security requirements" 
> and didn't pick up the fact that it was a sub-heading of 11, 
> since that was scrolled off the top of my screen.
> 
> In that case I agree that a Spec-T can specify IPSec. But 
> that is only within a trust domain. The issue that Hisham 
> raised is between a UAS and a proxy where the UAS is not in 
> the trust domain. Jonathan wants to tie it down, Hisham 
> doesn't. We need other opinions.
> 
> John
>

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Thu, 21 Feb 2008 13:18:15 +0100

Fully agree with Ernst on that.

The real requirement is that you have authenticated the connected
identity by some means and maybe secured the connection. Mandating TLS
to be used for that, seems a step to far. 
  
/Hans Erik 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Horvath, Ernst
Sent: Thursday, February 21, 2008 10:34 AM
To: Elwell, John; Hisham Khartabil
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 4

John,

Ernst

> and didn't pick up the fact that it was a sub-heading of 11, since 
> that was scrolled off the top of my screen.
> 

> within a trust domain. The issue that Hisham raised is between a UAS 
> and a proxy where the UAS is not in the trust domain. Jonathan wants 
> to tie it down, Hisham doesn't. We need other opinions.
> 
> John
> 
_______________________________________________
Sipping mailing list  http://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  http://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, 21 Feb 2008 13:23:22 +0000

So Hans Erik, Ernst and Hisham: I assume you are satisfied with the
existing text in 3.5 and 4.2.2 concerning this. I do not detect an
overwhelming body of opinion in favour of change.

John

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 21 February 2008 12:18
> To: Horvath, Ernst; Elwell, John; Hisham Khartabil
> Cc: [email-masked]
> that is only

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 21 Feb 2008 15:26:27 +0100

No problem with those sections.

Since 3325 seems pretty generic and does not exclude specific requests
or responses. How should I view this draft, is it going to become a BCP
for a more developed spec(T) or something like that?

/Hans Erik

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 14:55:06 +0000

Hans Erik,
 
This is to be viewed as just an update of RFC 3325. Possibly by
accident, some methods were omitted from both RFC 3325 and from the RFC
that defines the method, e.g., UPDATE, MESSAGE, PUBLISH. So yes, these
specific requests were omitted, and the present draft attempts to
correct that. Also RFC 3325 is ambiguous as to whether PAI applies to
responses - the present draft also attempts to correct that.
 
John

	From: Hans Erik van Elburg
[mailto:[email-masked]] 
	Sent: 21 February 2008 14:26
	To: Elwell, John
	Cc: [email-masked]
	Subject: RE: [Sipping] draft-ietf-sipping-udate-pai-00 - open
issue 4

	Since 3325 seems pretty generic and does not exclude specific
requests or responses. How should I view this draft, is it going to
become a BCP for a more developed spec(T) or something like that?
	
	/Hans Erik

		So Hans Erik, Ernst and Hisham: I assume you are
satisfied with the
		existing text in 3.5 and 4.2.2 concerning this. I do not
detect an
		overwhelming body of opinion in favour of change.
		
		John
		
		> From: Hans Erik van Elburg
[mailto:[email-masked]] 
- open issue 4
		> From: [email-masked]
[mailto:[email-masked]] On
		> > Subject: RE: [Sipping]
draft-ietf-sipping-udate-pai-00 - 
		> > within a trust domain. The issue that Hisham raised
is 
		> between a UAS 
		> > and a proxy where the UAS is not in the trust
domain. 
		> Jonathan wants 
		> This list is for NEW development of the application of
SIP Use