Subject: Re: [Sipping] I-D Action:draft-kaplan-sipping-pai-responses-00.txt

From: "Elwell, John" <[email-masked]>
Date: Mon, 01 Dec 2008 08:59:27 +0000

Hadriel,

Thanks for writing this. However, in my opinion it still suffers from
the same problem that we had with update-pai-06 (where we just said that
the proxy must have authenticated the source of the response by some
means) and update-pai-05 (where we cited one possible circumstance where
authentication could be assumed, i.e., when an earlier request over the
same TLS connection had been digest-authenticated). We received
objections to 06 because it did not cite at least one example of how to
achieve authentication and we received objections to 05 because the
mechanism is broken (there could be an intermediary that terminates the
TLS connection, so there is no guarantee that the UA that was previously
authenticated is the same as the UA that sends the response).

I think there are only two ways forward on this:
1. Somebody comes up with some text that describes a plausible way of
achieving authentication using present mechanisms. For example, if my
understanding is correct, I think the 3GPP mechanism relies on using the
same credentials for authenticating the UA and the underlying transport,
and hence the broken behaviour I described above does not apply. I
really wanted somebody else to provide some text, and I had hoped Keith
would do this.
2. We define a new mechanism. It has been stated that something based on
sip-outbound might be possible, but I don't really know what people have
in mind. As Cullen observes, this approach would most likely need to be
pursued in SIP rather than SIPPING.

John

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 29 November 2008 17:51
> To: sipping
> Cc: Elwell, John; Cullen Jennings
> Subject: I-D Action:draft-kaplan-sipping-pai-responses-00.txt
> 
> Howdy,
> At the most recent IETF meeting in Minneapolis, we were 
> informed that a WG decision regarding support for PAI in 
> responses in draft-ietf-sipping-update-pai had been reached 
> on the mailing list, and the decision was not to support 
> them.  I was instructed to submit a new draft if I wished to 
> propose any such support.  I have now done so.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-sipping-pai-r
> esponses-00.txt
> 
> Of course any comments are welcomed and appreciated.
> 
> -hadriel
> p.s. and thanks to John Elwell for (unknowingly) providing 
> most of the text for this draft, since it is based on 
> draft-ietf-sipping-update-pai.
> 
> 
_______________________________________________
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: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 10:43:36 -0500

Maybe I don't understand what your update draft is trying to accomplish, or maybe I don't understand RFC 3325.  They're written in English, but English is not my native language, so who knows.

My belief is that your draft is trying to clarify that PAI can be used in other methods than INVITE, that a trusted UAC can insert it, and that it can be more and different URI schemes.  It's not actually changing the fundamental definitions/scope of RFC 3325, right?

So let's start with what RFC 3325 is about.  For one, it's an Informational RFC for private use.  For another, it actually does not say what methods a PAI can be inserted in or not - it only uses the word "message", and in fact says both requests and responses.  It very clearly says that if a Proxy trusts a node, then it can believe the information as if it had authenticated the user itself.  Are you suggesting your draft is going to remove that, or re-define that?  For what purpose?  This whole thing is about a private network deciding what "Trust" means to itself!

But more importantly, RFC 3325 does not define a particular *instantiation* of a Spec(T).  It gives an *example* of one, but that's it.  If I decide for my network that all my PSTN Gateways and proxies trust each other, then that is my specific Spec(T).  If you decide for your network that only proxies have a trust relationship, then that's your Spec(T).  In my network, the PSTN gateways can certainly send back PAI in responses, because they're implicitly authenticated.  In your network they can't, because they're outside of the trust domain.  And the problem is...?

That's why Keith doesn't need to give you any 3GPP use-case.  It's not germane to the draft.  3GPP is simply one particular Spec(T).  It very well could be a bad one (and I think it has some holes), but that's the nature of a private-use, privately-defined Spec(T) model to begin with, which is all RFC 3325 covers!

-hadriel

> From: Elwell, John [mailto:[email-masked]]
> Sent: Monday, December 01, 2008 3:59 AM
> To: Hadriel Kaplan; sipping
> Cc: Cullen Jennings
> Subject: RE: I-D Action:draft-kaplan-sipping-pai-responses-00.txt
>
> Hadriel,
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 01 Dec 2008 16:45:32 +0000

Hadriel,

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 01 December 2008 15:44
> To: Elwell, John; sipping
> Cc: Cullen Jennings
> Subject: Re: [Sipping] I-D 
> Action:draft-kaplan-sipping-pai-responses-00.txt
> 
> 
> Maybe I don't understand what your update draft is trying to 
> accomplish, or maybe I don't understand RFC 3325.  They're 
> written in English, but English is not my native language, so 
> who knows.
[JRE] You surprise me.

> 
> My belief is that your draft is trying to clarify that PAI 
> can be used in other methods than INVITE, that a trusted UAC 
> can insert it, and that it can be more and different URI 
> schemes.  It's not actually changing the fundamental 
> definitions/scope of RFC 3325, right?
[JRE] Yes

> 
> So let's start with what RFC 3325 is about.  For one, it's an 
> Informational RFC for private use.  For another, it actually 
> does not say what methods a PAI can be inserted in or not - 
> it only uses the word "message", and in fact says both 
> requests and responses.  It very clearly says that if a Proxy 
> trusts a node, then it can believe the information as if it 
> had authenticated the user itself.  Are you suggesting your 
> draft is going to remove that, or re-define that?  For what 
> purpose?  This whole thing is about a private network 
> deciding what "Trust" means to itself!
> 
> But more importantly, RFC 3325 does not define a particular 
> *instantiation* of a Spec(T).  It gives an *example* of one, 
> but that's it.  If I decide for my network that all my PSTN 
> Gateways and proxies trust each other, then that is my 
> specific Spec(T).  If you decide for your network that only 
> proxies have a trust relationship, then that's your Spec(T).  
> In my network, the PSTN gateways can certainly send back PAI 
> in responses, because they're implicitly authenticated.  In 
> your network they can't, because they're outside of the trust 
> domain.  And the problem is...?
[JRE] Spec(T) applies between trusted nodes. This is not the issue. The
issue is when a proxy receives a response from an untrusted node, on
what basis can it assert an identity for the UAS. Or how can it
authenticate the UAS?

> 
> That's why Keith doesn't need to give you any 3GPP use-case.  
> It's not germane to the draft.  3GPP is simply one particular 
> Spec(T).  It very well could be a bad one (and I think it has 
> some holes), but that's the nature of a private-use, 
> privately-defined Spec(T) model to begin with, which is all 
> RFC 3325 covers!
[JRE] I am just the editor. It is Cullen you have to convince.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 12:36:42 -0500

> Sent: Monday, December 01, 2008 11:46 AM
>

That's only one of several scenarios.  The pai-responses draft covers the scenarios where the UA is *within* the Trust Domain, for example, and I don't think those are currently covered by your update-pai draft.

And my draft said if the UA is outside the Trust Domain, then the Proxy MUST remove any received PAI.

I assume the main concern would be the following paragraph:
  "If a Proxy receives an ACK or CANCEL request from a UAC, or any
   response for any method from a UAS, and the message does not contain
   a P-Asserted-Identity header field, the Proxy MAY insert the header
   field, if it has knowledge of the UA's identity per [RFC 3325].
   This would require the Proxy to have previously authenticated the
   UA's identity over the same secure transport as the response was
   received from.  If the message has a P-Preferred-Identity header
   value, the Proxy MAY use this information as a hint for P-Asserted-
   Identity generation, per the rules in [RFC 3325].  The Proxy MUST
   remove any P-Preferred-Identity from any message it forwards, per
   [RFC 3325]."

I admit that concept bothers me too.  Clearly without either a client-side certificate matching the identity, or some shared key model tied to a secure transport's authentication mechanism (like 3gpp), it can't really be done for responses/ACK/CANCEL.  That doesn't mean it can't be done.  It just means only some can do it.

-hadriel