headers
Elwell, John | 1 Dec 2008 09:59
Picon

Re: I-D Action:draft-kaplan-sipping-pai-responses-00.txt

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-----
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hadriel Kaplan | 1 Dec 2008 16:43
Favicon

Re: 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.

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

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell <at> siemens.com]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Elwell, John | 1 Dec 2008 17:45
Picon

Re: I-D Action:draft-kaplan-sipping-pai-responses-00.txt

Hadriel,

> -----Original Message-----
> From: sipping-bounces <at> ietf.org 
> [mailto:sipping-bounces <at> ietf.org] 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 -
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hadriel Kaplan | 1 Dec 2008 18:36
Favicon

Re: I-D Action:draft-kaplan-sipping-pai-responses-00.txt


> -----Original Message-----
> From: Elwell, John [mailto:john.elwell <at> siemens.com]
> Sent: Monday, December 01, 2008 11:46 AM
>
> [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 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Worley | 1 Dec 2008 22:12
Favicon

Experimental "References" header

A new version of I-D, draft-worley-references-01.txt has been successfuly submitted by Dale Worley and
posted to the IETF repository.

Filename:        draft-worley-references
Revision:        01
Title:           The References Header for SIP
Creation_date:   2008-12-01
WG ID:           Independent Submission
Number_of_pages: 23

Abstract:
This document defines a SIP extension header, References, to be used
within SIP messages to signify that the message (and the dialog
containing it) is related to one or more other dialogs.  It is
expected to be used largely for diagnostic purposes.

Dale

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Alan Johnston | 1 Dec 2008 22:51

Re: draft-johnston-sipping-cc-uui-05

Cullen,

That is the standard way S/MIME is used with SIP.  Of course, extensions 
to the way SIP and S/MIME are used together could be developed, but this 
draft would not be the place to do this.

The better way to do this for this particular application would probably 
be to encrypt the UUI before passing it to the SIP stack, but this also 
would be out of scope for this draft.

Thanks,
Alan

Cullen Jennings wrote:
>
> So you want the new header to be tunneled in a body part of the SIP 
> message?
>
> On Nov 27, 2008, at 12:00 PM, Alan Johnston wrote:
>
>> Cullen Jennings wrote:
>> > <snip>
>> > Uh, I can understand how S/MIME protects a body but seems like a bit
>> > more might be needed to explain how it protects a header.
>> >>
>>
>> Is the text in RFC 3261 not clear?
>>
>>     23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mary Barnes | 2 Dec 2008 01:49
Favicon

Initial WG review: draft-johnston-sipping-cc-uui-06

Hi folks,

This email is intended to announce an initial WG review for the following  document:
http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-uui-06.txt

There was strong consensus to complete the problem statement and requirements in the SIPPING WG session (i.e., WGLC) and then propose that the solution be worked in SIP WG - with the obvious understanding that SIP WG must go through the process of taking on a new work item.   And, of course, the chairs will work with the AD to get the appropriate milestones added to SIPPING WG charter.

In order to progress this document in the SIPPING WG, we would like at least 3 (ideally 4) dedicated reviewers. So, please let us know ASAP if you would be willing to serve as a reviewer.  If we don't get volunteers, I will pick on people, but it would be great to get some new reviewers into the pool. 

In terms of feedback, as well as technical comments, we would like to hear views on whether this doc is ready for WGLC (note that this document has been in the WG as an individual draft for over two years).

Please send any and all comments on or before Dec. 22nd, 2008 (3 weeks time).

Regards,
Mary.
SIPPING WG co-chair 

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 8 comments |
headers
Geir Arne Sandbakken | 2 Dec 2008 16:32

SIP Configuration Framework uses underscore in SIP URI

The Local-Network profile in the framework requires "_sipuaconfig"
concatenated with the local network domain to be used as the host part
of the Request URI.  

Our SIP stack does not view this as valid SIP URI, and rejects the
message. AFAICC RFC 3261 seems to agree with our parser.

IMHO, using underscores in DNS host for finding services related names
in DNS queries is one thing. Changing the grammar of a SIP URI
potentially breaking parsers is quite another matter.

Geir Arne
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 7 comments |
headers
Elwell, John | 3 Dec 2008 08:51
Picon

Re: Initial WG review: draft-johnston-sipping-cc-uui-06

Alan and Joanne,

Looking at the redirection example, I could imagine a similar case but
using proxying (retargeting or rerouting) rather than redirection. In
this case the proxy would insert the UUI in the forwarded request. Is
see no requirement for this in section 3.

However, PSTN/ISDN does not support capabilities equivalent to insertion
by a proxying or redirecting entity. Yet in section 1 it states:
"This document looks only at the
   requirements and mechanisms for replicating the existing, widely used
   and deployed ISDN UUI service."

Therefore we should either:
- remove the redirection case, on the grounds that it doesn't replicate
existing ISDN UUI operation; or
- clarify the statement in section 1 so as not to preclude the
redirection case.

Furthermore, if we adopt the second of these approaches we might wish to
consider adding a requirement for insertion by a proxy. Fortunately the
chosen mechanism would seem to permit this.

I have no strong feelings which approach we should take. I just wish to
see consistency.

John

> -----Original Message-----
> From: sipping-bounces <at> ietf.org 
> [mailto:sipping-bounces <at> ietf.org] On Behalf Of Mary Barnes
> Sent: 02 December 2008 00:49
> To: sipping <at> ietf.org
> Cc: Gonzalo Camarillo
> Subject: [Sipping] Initial WG review: draft-johnston-sipping-cc-uui-06
> 
> Hi folks, 
> 
> This email is intended to announce an initial WG review for 
> the following  document: 
> http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-
> uui-06.txt 
> <http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc
> -uui-06.txt>  
> 
> There was strong consensus to complete the problem statement 
> and requirements in the SIPPING WG session (i.e., WGLC) and 
> then propose that the solution be worked in SIP WG - with the 
> obvious understanding that SIP WG must go through the process 
> of taking on a new work item.   And, of course, the chairs 
> will work with the AD to get the appropriate milestones added 
> to SIPPING WG charter.
> 
> In order to progress this document in the SIPPING WG, we 
> would like at least 3 (ideally 4) dedicated reviewers. So, 
> please let us know ASAP if you would be willing to serve as a 
> reviewer.  If we don't get volunteers, I will pick on people, 
> but it would be great to get some new reviewers into the pool.  
> 
> In terms of feedback, as well as technical comments, we would 
> like to hear views on whether this doc is ready for WGLC 
> (note that this document has been in the WG as an individual 
> draft for over two years). 
> 
> Please send any and all comments on or before Dec. 22nd, 2008 
> (3 weeks time). 
> 
> Regards, 
> Mary. 
> SIPPING WG co-chair 
> 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 3 comments |
headers
Dale Worley | 3 Dec 2008 04:22
Favicon

Re: SIP Configuration Framework uses underscore in SIP URI

On Tue, 2008-12-02 at 16:32 +0100, Geir Arne Sandbakken wrote:
> The Local-Network profile in the framework requires "_sipuaconfig"
> concatenated with the local network domain to be used as the host part
> of the Request URI.  
> 
> Our SIP stack does not view this as valid SIP URI, and rejects the
> message. AFAICC RFC 3261 seems to agree with our parser.
> 
> IMHO, using underscores in DNS host for finding services related names
> in DNS queries is one thing. Changing the grammar of a SIP URI
> potentially breaking parsers is quite another matter.

Yes, that seems to be a problem.

There was a discussion starting at
http://www.ietf.org/mail-archive/web/sip/current/msg00966.html regarding
adding "_" and other characters to the allowed set of characters in
host-parts of SIP URIs, but it was inconclusive.

It seems that the use of "_sipuaconfig" prefixing a domain name was
introduced in regard to looking up DNS A records.  (This is a valid
extension of current practice.)  But at some point, this was
transitioned into being the request-URI of a SUBSCRIBE.  And as you say,
that's not syntactically valid.

Interestingly, "_" has no reserved uses in RFC 3261 section 25.1, so we
could extend the grammar to allow it in host names with no ill effects.

Dale

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 2 comments |

Gmane