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

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

A comment I received on the previous draft
(draft-elwell-sipping-update-pai-02) was whether to allow
P-Asserted-Identity in any mid-dialog request (including PRACK, INFO,
BYE...) rather than just UPDATE? The present motivation in this document
is that an identity may change mid-dialog, and although the new identity
can at present be conveyed in a re-INVITE request, this needs extending
to UPDATE requests. I don't think any other method would need to be used
to convey a new identity mid-dialog. Therefore the only motivation for
extending to all mid-dialog requests is to provide an explicit assertion
that the source of each request has been authenticated.

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: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2008 10:33:59 -0500

*Not* including PAI in mid-dialog requests implies an assumption that 
these requests do not require authentication. That may make sense in 
certain cases, where all the requests in the dialog share a secure 
session. But it does not make sense in general. In the (unfortunately 
still common) case of sending requests using unsecured UDP transport 
there is no reason to assume that mid-dialog requests are from the same 
source. They typically should use something like digest authentication 
on every request. In the kinds of environments that use PAI, that digest 
authentication might be between the UA and an edge proxy, with PAI being 
used downstream. So it makes perfect sense to include PAI in every 
request that has been authenticated.

	Thanks,
	Paul

---

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

Paul,

But RFC 3325 mandates the use of TLS with a certain cipher suite between
nodes within a Trust Domain, so is this sufficient grounds for assuming
that if one request in a dialog has delivered PAI, then subsequent
requests within that dialog that don't include PAI are from the same
source and have been similarly authenticated?

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 14 February 2008 15:34
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 2
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2008 10:53:43 -0500

> source and have been similarly authenticated?

That only seems to apply to the proxy that inserts the PAI and the 
downstream nodes. It doesn't apply to the UAC, which could be talking to 
the proxy via UDP.

Now you could assert that the proxy is then responsible for keeping 
track of a session, but that requires a degree of statefullness that 
isn't otherwise required. So the proxy might have no memory of the 
dialog establishment.

Or do you assume that such a proxy should do its authentication and then 
just request apparently in-dialog requests out-of-hand if it hasn't been 
able to authenticate them? That seems overreaching on the part of the 
proxy to me.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Feb 2008 16:01:51 +0000

Paul,

OK, I think what you say makes sense. Let's see if there are other
opinions.

John 

> Sent: 14 February 2008 15:54
> To: Elwell, John
> Cc: [email-masked]

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 20 Feb 2008 15:20:01 +1100

Doesn't RFC3325 assume these is a security association between the UA and
the outbound proxy? We are talking about the 'P' header P-asserted-identity.
We are not trying to justify using this 'P' header outside its trusted
domain usage, are we?

Hisham

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 20 Feb 2008 06:06:32 -0800 (PST)

If you can not trust subsequent requests coming on the same dialog to come
from the same source, then how can you trust the value of
P-Asserted-Identity that comes on subsequent requests?

I think I agree with John here.

/Hans Erik 

-- 
View this message in context: http://www.nabble.com/draft-ietf-sipping-udate-pai-00---open-issue-2-tp15479159p15589730.html
Sent from the IETF - Sipping mailing list archive at Nabble.com.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 10:07:08 -0500

> P-Asserted-Identity that comes on subsequent requests?

You should trust the P-A-ID because you trust the agent that inserts it 
and that the path between you and it is secure.

It is up to that agent to be confident in the identity before it asserts 
that identity. How it does so is its business. It really doesn't matter 
if two requests in a dialog come from different sources so long as each 
has been adequately authenticated. (E.g. it could be that the two 
messages came from different instances of a redundant pair of servers 
that cooperatively manage their participation in a dialog.

> I think I agree with John here.

So, you are ok with a situation where a proxy accepts incoming requests 
over UDP, authenticates dialog establishing requests with digest and 
inserts PAID to attest to that, and then forwards in-dialog requests 
without authentication and without PAID? You will happily accept those?

	Paul

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Wed, 20 Feb 2008 17:49:05 +0100

No I will not accept that and I don't remember having said or implied
that the subsequent requests should not be authenticated as well before
they enter the trust domain. If they can't be authenticated to come from
the same source they should not even be allowed to enter the trust
domain. The fact that the source is authenticated does not imply that a
PAI header is inserted. 

Of course a PAI could be added to all requests/responses, the question
is what good is that for?
What does it mean when one receives an initial request with PAI: A and a
subsequent request on the same dialog with PAI: B?

/Hans Erik

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 20, 2008 4:07 PM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 2

Hans Erik van Elburg wrote:
> If you can not trust subsequent requests coming on the same dialog to 
> come from the same source, then how can you trust the value of 

	Paul

> /Hans Erik
> 
> 
> Paul Kyzivat wrote:
>>
>>
>> Elwell, John wrote:
>>> Paul,
>>>
>>> But RFC 3325 mandates the use of TLS with a certain cipher suite 
>>> between nodes within a Trust Domain, so is this sufficient grounds 
>>> for assuming that if one request in a dialog has delivered PAI, then

>>> subsequent requests within that dialog that don't include PAI are 
>>> from the same source and have been similarly authenticated?
>> downstream nodes. It doesn't apply to the UAC, which could be talking

>> to the proxy via UDP.
>> Or do you assume that such a proxy should do its authentication and 
>> then just request apparently in-dialog requests out-of-hand if it 
>> hasn't been able to authenticate them? That seems overreaching on the

>> part of the proxy to me.
>>>> Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue

>>>> 2
>>>>
>>>> *Not* including PAI in mid-dialog requests implies an assumption 
>>>> that these requests do not require authentication. That may make 
>>>> sense in certain cases, where all the requests in the dialog share 
>>>> a secure session. But it does not make sense in general. In the 
>>>> (unfortunately still common) case of sending requests using 
>>>> unsecured UDP transport there is no reason to assume that 
>>>> mid-dialog requests are from the same source. They typically should

>>>> use something like digest authentication on every request. In the 
>>>> kinds of environments that use PAI, that digest authentication 
>>>> might be between the UA and an edge proxy, with PAI being used 
>>>> downstream. So it makes perfect sense to include PAI in every 
>>>>> 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
>>>>>
>> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 13:43:19 -0500

Hans Erik van Elburg wrote:
> they enter the trust domain.

I didn't mean to imply that you said so. It is just a logical 
consequence of 3325.

> If they can't be authenticated to come from

3325 says that the server must authenticate the request if it desires to 
add a PAI header. The implication is clearly that it may forward 
requests without adding a PAI if it can't, or doesn't try to, 
authenticate the request. It certainly isn't forbidden from forwarding 
requests that haven't been authenticated.

> is what good is that for?

For a proxy to decide that a new request is trusted because it comes 
from the same source as a prior message that was authenticated, the 
proxy must be more than transaction stateful. (Dialog or more.)

For a proxy to know that a dialog initiating request was previously 
forwarded with a PAI and so a new in-dialog request may be sent without 
a PAI requires that the proxy be dialog stateful.

If a proxy doesn't maintain such state, and decides whether to 
authenticate based on the assumption that a request is in-dialog 
(because it has a to-tag), then it opens itself up to attack by a UAC 
that sends an "initial" request with a to-tag, perhaps to a confederate 
that will accept it.

On the receiving side, how does a downstream node distinguish a case 
where there is no PAI because this is an in-dialog request from the case 
where the edge proxy simply forwarded a message that it didn't try to 
authenticate?

> subsequent request on the same dialog with PAI: B?

Obviously it means exactly what it says. While it does seem odd, I don't 
see why it is *necessarily* wrong. The question is: what (if anything) 
should the UAS do if this occurs? I guess any element that is stateful 
enough to notice this as a problem could choose to reject the second 
message.

The point is that you must reach something stateful enough to do the 
check. AFAIK there is no requirement in 3325 that the element on the 
border, that is responsible for inserting PAI, be stateful in that way.

I realize that some systems, such as IMS, expect that element (the 
P-CSCF) to be sufficiently stateful. But that is part of the 
specification of IMS, not part of 3325.

	Thanks,
	Paul

---

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

Hisham,
 
Generally speaking, the UAC is outside the trust domain. The proxy
inserts PAI into the request sent onwards within the trust domain. So
when the proxy sends PAI in the INVITE request it asserts that it has
authenticated the UAC. Does the absence of PAI in mid-dialog requests
mean that the same UAC has been authenticated again or not?
 
John

________________________________

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

	Doesn't RFC3325 assume these is a security association between
the UA and the outbound proxy? We are talking about the 'P' header
P-asserted-identity. We are not trying to justify using this 'P' header
outside its trusted domain usage, are we?
	 
	Hisham

		Paul,
		
		OK, I think what you say makes sense. Let's see if there
are other
		opinions.
		
		John
		
		> > But RFC 3325 mandates the use of TLS with a certain
cipher
		> suite between
		> > nodes within a Trust Domain, so is this sufficient
grounds
		> for assuming
		> downstream nodes. It doesn't apply to the UAC, which
could be
		> talking to
		> just request apparently in-dialog requests out-of-hand
if it
		> hasn't been
		> >> Subject: Re: [Sipping]
draft-ietf-sipping-udate-pai-00 -
		> open issue 2
		> >>
		> >> *Not* including PAI in mid-dialog requests implies
an
		> assumption that
		> >> these requests do not require authentication. That
may
		> make sense in
		> >> session. But it does not make sense in general. In
the
		> (unfortunately
		> >> still common) case of sending requests using
unsecured UDP
		> transport
		> >> there is no reason to assume that mid-dialog
requests are
		> >> from the same
		> >> source. They typically should use something like
digest
		> >> authentication
		> >> on every request. In the kinds of environments that
use PAI,
		> >> that digest
		> >> authentication might be between the UA and an edge
proxy,
		> >> with PAI being
		> >>> P-Asserted-Identity in any mid-dialog request
(including
		> >> PRACK, INFO,
		> >>> BYE...) rather than just UPDATE? The present
motivation in
		> >> this document
		> >>> is that an identity may change mid-dialog, and
although the
		> >> new identity
		> >>> can at present be conveyed in a re-INVITE request,
this
		> >> needs extending
		> >>> to UPDATE requests. I don't think any other method
would
		> >> need to be used
		> >>> to convey a new identity mid-dialog. Therefore the
only
		> >> motivation for
		> >>> extending to all mid-dialog requests is to provide
an
		> >> explicit assertion
		> >>> Sipping mailing list
http://www.ietf.org/mailman/listinfo/sipping
		_______________________________________________
		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: Wed, 20 Feb 2008 19:09:40 +0000

Hans Erik,

See below.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 20 February 2008 16:49
> To: Paul Kyzivat
> Cc: [email-masked]
[JRE] It could mean that a B2BUA has performed some 3PCC operation such
as call transfer. Of it could mean that a PSTN gateway has detected that
call transfer has occurred in the PSTN.

You can also ask the opposite question - how do I interpret a mid-dialog
request without PAI? Does it mean:
1) the mid-dialog request has come from A again, and A has been
authenticated as the source of the request?
2) the mid-dialog request has come from A again, but A has not
necessarily been authenticated as the source of the request?
3) no deduction can be made about the source of the mid-dialog request?

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Thu, 21 Feb 2008 11:45:46 +0100

Hi Paul,
inline...
/Hans Erik

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 20, 2008 7:43 PM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 2

Hans Erik van Elburg wrote:
> that the subsequent requests should not be authenticated as well 
> before they enter the trust domain.

I didn't mean to imply that you said so. It is just a logical
consequence of 3325.
[HE] Not entirely, it does not say that a request shall not be
authenticated. And it does not say either that if the request is
authenticated that then a PAI MUST be inserted.
I think the problem here is that any such conclusion assumes a specific
spec(T) and I admit that I was biassed towards an IMS like deployment.

> If they can't be authenticated to come from the same source they 
> should not even be allowed to enter the trust domain. The fact that 
> the source is authenticated does not imply that a PAI header is 
> inserted.

[HE] Agreed

[HE] Agreed

For a proxy to know that a dialog initiating request was previously
forwarded with a PAI and so a new in-dialog request may be sent without
a PAI requires that the proxy be dialog stateful.
[HE] Agreed, I think it is here where knowledge of the particular
spec(T) is required for a proxy to understand what it means when it
receives subsequent requests without a PAI. So RFC3325 in itself is not
sufficient to draw any conclusions.

[HE] Yes under certain spec(T)

[HE] depends on spec(T)

> What does it mean when one receives an initial request with PAI: A and

> a subsequent request on the same dialog with PAI: B?

[HE] yes it could

The point is that you must reach something stateful enough to do the
check. AFAIK there is no requirement in 3325 that the element on the
border, that is responsible for inserting PAI, be stateful in that way.
[HE] agreed but it coulc be part of spec(T)

	Thanks,
	Paul

> You should trust the P-A-ID because you trust the agent that inserts 
> it and that the path between you and it is secure.
> 
> It is up to that agent to be confident in the identity before it 
> asserts that identity. How it does so is its business. It really 
> doesn't matter if two requests in a dialog come from different sources

> so long as each has been adequately authenticated. (E.g. it could be 
> that the two messages came from different instances of a redundant 
> pair of servers that cooperatively manage their participation in a
dialog.
> So, you are ok with a situation where a proxy accepts incoming 
> requests over UDP, authenticates dialog establishing requests with 
> digest and inserts PAID to attest to that, and then forwards in-dialog

> requests without authentication and without PAID? You will happily
accept those?

>>>>> issue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2008 09:50:22 -0500

> spec(T) and I admit that I was biassed towards an IMS like deployment.

Yes. The trick here is to ensure that the mechanisms of 3325 itself need 
to be independent of Spec(T).

> sufficient to draw any conclusions.

Yes, since Spec(T) must specify "The default privacy handling when no 
Privacy header field is present".

> that the source of each request has been authenticated.

It requires a particular kind of Spec(T), with special requirements on 
the border elements, for mid-dialog requests without a PAI to be 
understood by elements within the trust domain to have been authenticated.

There are reasonable kinds of Spec(T) where any request without a PAI 
may have to be treated as unauthenticated/untrusted. To accommodate 
those, IMO PAI should be allowed within *all* requests.

	Thanks,
	Paul

---

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

Paul,

> those, IMO PAI should be allowed within *all* requests.
[JRE] In fact, as I pointed out on another thread, the draft adds
UPDATE, MESSAGE and PUBLISH because they were missing from both RFC 3325
and from the RFCs that specify those methods. I am not aware of any
other methods not explicitly covered by some RFC.
However, RFC 3325 explicitly does not allow PAI in ACK, CAN, REG, INFO
and PRACK.
- REGISTER is the subject of a separate thread - it looks like it should
be allowed.
- ACK, INFO and PRACK seem to be candidates for allowing PAI. Presumably
they were disallowed in RFC 3325 because it was assumed that an asserted
identity at dialog establishment time would suffice for the whole
dialog. As observed in this thread, this implies a certain statefulness
on behalf of both the inserter and receiver of PAI.
- CANCEL is not a mid-dialog request - it is something rather odd and I
don't really see the applicability of PAI.

John

---

From: "Bino George" <[email-masked]>
Date: Fri, 22 Feb 2008 09:12:58 +0530

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Thursday, February 21, 2008 9:45 PM
To: Paul Kyzivat; Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [Sipping] draft-ietf-sipping-udate-pai-00 - open issue 2

Paul,

John