Subject: [Sipping] draft-elwell-sipping-update-pai-02 posted

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Nov 2007 10:14:09 +0000

http://www.ietf.org/internet-drafts/draft-elwell-sipping-update-pai-02.t
xt
Abstract:
"  SIP has a mechanism for conveying the asserted identity of the
   originator of a request by means of the P-Asserted-Identity header
   field.  This header field is specified for use in requests using a
   number of SIP methods, in particular the INVITE method.  However, RFC
   3325 does not specify the insertion of this header field by a trusted
   UAC, does not specify the use of this header field with the SIP
   UPDATE, MESSAGE or PUBLISH methods, and is unclear on the use of this
   header field in responses.  This document extends RFC 3325 to cover
   these situations."

The only significant change from 01 is the inclusion of support for
P-Asserted-Identity in MESSAGE and PUBLISH.

I would really like some feedback as to whether this should be
progressed as an update to RFC 3325.

John

_______________________________________________
Sipping mailing list  https://www1.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: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Nov 2007 12:17:16 -0500

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, November 16, 2007 5:14 AM
> To: [email-masked]
> Subject: [Sipping] draft-elwell-sipping-update-pai-02 posted
>

I think that's a good idea.  It puts to paper what many people have been doing in the field (at least for trusted UAC's generating it and Message containing it).  Also I think P-Preferred-Identity should be likewise updated as well, for the allowed requests.

With regards to the response, shouldn't it let the UAS send a P-Preferred as well?

And while you're at this, can you include PAI/PPI being allowed in INFO?  ;)

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Nov 2007 17:58:17 +0000

Hadriel,

Thanks for your feedback. Your points about PPI are, I think, valid. I
will consider for the next draft. INFO though? Depends on other
discussions in Vancouver.

John 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 16 November 2007 17:17
> To: Elwell, John; [email-masked]
> Subject: RE: [Sipping] draft-elwell-sipping-update-pai-02 posted
> 
> 
> 
> I think that's a good idea.  It puts to paper what many 
> people have been doing in the field (at least for trusted 
> UAC's generating it and Message containing it).  Also I think 
> P-Preferred-Identity should be likewise updated as well, for 
> the allowed requests.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2007 16:25:11 -0500

I agree that updating PPI is also appropriate. It would be good to have 
some discussion of when to use PPI vs PAI.

Just as you have relaxed rules to allow PAI be trusted UAs perhaps it 
would make sense to allow PPI to be added by untrusted intermediaries. 
(I.e. an intermediary acting on behalf of the UA but still outside the 
trusted core. For instance this might be the case with an enterprise 
proxy between a user and a service provider.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 17 Nov 2007 17:07:44 +0000

Paul,

There has been mention in ETSI TISPAN of using PPI from an enterprise
network to an NGN. I am not quite sure, however, why an NGN would trust
PPI but not PAI.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 16 November 2007 21:25
> To: Elwell, John
> Cc: Hadriel Kaplan; [email-masked]
> Subject: Re: [Sipping] draft-elwell-sipping-update-pai-02 posted
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Nov 2007 13:10:12 -0500

Indeed, we've seen providers accepting PAI from the Enterprise, for cases where the Enterprise has a PBX or a registrar that authenticates the Enterprise phones (and is the only one that could do so).  But the NGN doesn't blindly accept it - sometimes they still want to check it against numbers/domain the Enterprise is allowed to originate from.  So sometimes the border device only accepts PPI, or changes the PAI to PPI, to let the core check it, if the border device doesn't have the necessary info to check it itself.  In that sense the NGN doesn't "trust" the PPI, but simply uses it as a differentiator that the identity still needs to be checked, vs. a PAI indicating it already has been checked.
It's less common though for the NGN to send PAI or PPI to the Enterprise. (i.e., if the call was anoynmized they consider the Enterprise outside of the trust domain)

-hadriel

> Sent: Saturday, November 17, 2007 12:08 PM
> To: Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Nov 2007 22:49:32 -0500

> network to an NGN. I am not quite sure, however, why an NGN would trust

Well, I suppose it would be the same rationale as between a UE and 
P-CSCF: you don't *trust* the supplier of the PPI - it is only a choice 
among the values that the trusted element decides the untrusted one is 
entitled to use. So, if the enterprise is entitled to use 100 
identities, the enterprise can use PPI to select among them.

But that is all just speculation on my part.

	Paul