> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 14 March 2008 16:40 > To: Hadriel Kaplan > Cc: Elwell, John; Dwight, Timothy M (Tim); IETF SIP List > Subject: Re: [Sip] Straw-man for rfc4474 and e164 > > > > Hadriel Kaplan wrote: > > John, can you elaborate more on the straw-man proposal? > I'm not sure I fully grok it. > > > > When I commented at the mic that the problem with such a > concept, assuming I understand the proposal, is that there is > nothing stopping any middle-man or frankly anything on the > planet from simply signing a [EMAIL PROTECTED], for their > domain name. Jonathan's response I think was "well that > makes it the same strength as PSTN". But this makes it > effectively useless to sign or verify. Why bother signing? > Just use PAID. (which may well be the final result of all > this discussion) > > I too am struggling with this. > > I think this only makes sense if you then make a policy decision: a > white list of signing domains from which you will accept > signatures for > phone numbers. But I don't understand how you populate that > white list > in a useful way. Seems like either it is "your own enterprise (if you > have one) and your own SP", [JRE] Yes, probably just these too. This is a limitation of phone number based URIs.
> or else it is based on your trust in the > root CA for the signer. > > The latter only works if there are one or more root CAs that enforce > some sort of meaningful policy over who they will provide > certs to. That > in turn starts to sound a lot like policies for ENUM. > > Paul > > > -hadriel > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of > >> Elwell, John > >> Sent: Thursday, March 13, 2008 6:17 PM > >> To: Dwight, Timothy M (Tim); IETF SIP List > >> Subject: Re: [Sip] The thing we're missing in the RFC 4474 > and DTLS- > >> SRTPdiscussion > >> > >> Quite right. PSTN gateways present their own problems, but > just the use > >> of number-based SIP URIs for communications within the SIP > environment > >> also has some issues, i.e., the fact that the number has > meaning without > >> the domain part, and thus the temptation to modify the > domain part. As > >> part of the straw man proposal presented today in the > meeting, it was > >> suggested that a domain can sign a number-based SIP URI if > it believes > >> that calls to that number can reach the user via that > domain. So that is > >> all you can assume about the domain part of such a URI. > >> > >> Of course, this leads to the question of when is a SIP URI > number-based > >> and when is it not. In theory, the user=phone parameter > could be the > >> criterion, so that if user=phone is absent a relying party > could assume > >> that the domain indicated in the URI is the "home" domain > for that user. > >> In practice, it appears there are implementations that > modify the domain > >> part of any URI that looks like it contains a phone number > in the user > >> part. That would appear to be broken, in that return > routability would > >> be lost. However, in practice, often a numeric user part IS a phone > >> number, and assuming global uniqueness, return routability > perhaps is > >> achievable. > >> > >> So there seems to be rather a grey line between trusting > or not trusting > >> the domain part of a SIP URI as being the "home" domain of > the user. We > >> have to try to figure out how to address this and give > reasonable advice > >> to relying parties. > >> > >> John > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>> Behalf Of Dwight, Timothy M (Tim) > >>> Sent: 13 March 2008 19:28 > >>> To: IETF SIP List > >>> Subject: Re: [Sip] The thing we're missing in the RFC 4474 > >>> and DTLS-SRTPdiscussion > >>> > >>> I don't understand the focus on PSTN gateways. Is it > >>> believed that only > >>> PSTN gateways ever create URIs with numeric user parts? > Or that PSTN > >>> gateways are particularly untrustworthy? Neither seems > reasonable to > >>> me. > >>> > >>> tim > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>>> Behalf Of Dean Willis > >>>> Sent: Thursday, March 13, 2008 12:00 PM > >>>> To: IETF SIP List > >>>> Subject: [Sip] The thing we're missing in the RFC 4474 and > >>>> DTLS-SRTP discussion > >>>> > >>>> > >>>> We seem to agree that RFC 4474 assertions involving things > >>> that look > >>>> like phone numbers can not really be trusted, and probably > >>> therefore > >>>> should not be sent. > >>>> > >>>> However, DTLS-SRTP doesn't function without RFC 4474. > >>>> > >>>> So, if you need to use DTLS-SRTP to protect a phone call that > >>>> involves > >>>> a numeric identity (and that includes E.164, private phone > >>> numbers, > >>>> and numeric user parts of any kind), you end up having to > >>>> send an RFC > >>>> 4474 Identity header that is going to mislead people. > >>>> > >>>> So as things are currently written, one can never use > >>>> DTLS-SRTP with a > >>>> numeric userpart in the identity. > >>>> > >>>> That's the part that we absolutely have to sort out. > >>>> > >>>> We could fix this by having gateways encode their > identity using a > >>>> reserved userpart. This has to have the property of saying > >>> "Do not > >>>> display this as caller-ID". Using "sip:domain" or > >>>> "sip:ipaddress" does > >>>> not work, as those might actually be valid URIs that be be > >>> displayed > >>>> as IDs. > >>>> > >>>> It might work to have the gateway use a reserved value, like > >>>> "sip:[EMAIL PROTECTED] > >>>> ". > >>>> > >>>> Or it might work to extend RFC 4474 to have a "strength of > >>>> assertion" > >>>> indicator. > >>>> > >>>> It's certainly easier to add guidance in DTLS-SRTP about what > >>>> gateways > >>>> should do and about how UASes should interpret various > >>> header fields > >>>> than it is to change RFC 4474. > >>>> > >>>> However, we need to note that a standards-track document > >>> cannot say > >>>> "Use P-Asserted-Identity". That would be an unacceptable > >>> downref. It > >>>> could however say "If the identity encoded in the RFC 4474 > >>> Identity > >>>> header has the reserved userpart "pstngateway", then the UAS > >>>> MUST NOT > >>>> display this to the user as the calling party identifier. > >>>> Rather, the > >>>> UAS should use other indicators of calling party identity > >>>> that may be > >>>> available to it. > >>>> > >>>> -- > >>>> Dean > >>>> _______________________________________________ > >>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use [EMAIL PROTECTED] for questions on current sip > >>>> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > >>> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > >> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
