Re: [Sip] Signing P-Asserted-Identity

[Paul Kyzivat <pkyzivat at cisco.com>]

Or, we could put the "original-From" in From, the "original-To" in To, etc.

	Paul

Adam Roach wrote:
> On 7/11/08 2:56 AM, Elwell, John wrote:
> > I understand that some service providers expect PAI to identify the
> > charged user, so accepting any PAI value outside the legitimate range of
> > the authenticated entity from which the request is received (e.g.,
> > authenticated at the IPSEC or TLS level) causes them grief. Hence,
> > considering an enterprise network to be part of their trust domain is
> > problematic for these service providers. In my opinion, the From URI is
> > more likely to pass through unchanged than the PAI. But perhaps the best
> > chance of success is to place the e2e-authenticated identity in some
> > other header field.
> >   
>
> P-Original-From?
>
> Actually, that would work pretty well -- if we add "P-Original-Call-Id," 
> "P-Original-CSeq," "P-Original-Contact," and "P-Original-Identity," we 
> could use RFC 4474 with just minor modification.
>
> Or, even better, we could do away with P-Original-* headers altogether, 
> and put the relevant header fields (including Identity) in an 
> application/sipfrag body part. Then, you could use a normal RFC4474 
> identity service, and add a security mangler to make the signature 
> SBC-safe.
>
> /a
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip


ing <dwing at cisco.com>
Subject: Re: [Sip] Signing P-Asserted-Identity
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org

Or, we could put the "original-From" in From, the "original-To" in To, etc.

	Paul

Adam Roach wrote:
> On 7/11/08 2:56 AM, Elwell, John wrote:
> > I understand that some service providers expect PAI to identify the
> > charged user, so accepting any PAI value outside the legitimate range of
> > the authenticated entity from which the request is received (e.g.,
> > authenticated at the IPSEC or TLS level) causes them grief. Hence,
> > considering an enterprise network to be part of their trust domain is
> > problematic for these service providers. In my opinion, the From URI is
> > more likely to pass through unchanged than the PAI. But perhaps the best
> > chance of success is to place the e2e-authenticated identity in some
> > other header field.
> >   
>
> P-Original-From?
>
> Actually, that would work pretty well -- if we add "P-Original-Call-Id," 
> "P-Original-CSeq," "P-Original-Contact," and "P-Original-Identity," we 
> could use RFC 4474 with just minor modification.
>
> Or, even better, we could do away with P-Original-* headers altogether, 
> and put the relevant header fields (including Identity) in an 
> application/sipfrag body part. Then, you could use a normal RFC4474 
> identity service, and add a security mangler to make the signature 
> SBC-safe.
>
> /a
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip