On Apr 4, 2008, at 6:57 PM, Michael Thomas wrote:
> Dean Willis wrote:
>>
>> On Apr 4, 2008, at 1:20 PM, Michael Thomas wrote:
>>> Rather than work on a solution, I'd rather hear why a receiver cares
>>> about any of this. Ie, what does the consumer of this information do
>>> differently? The experience from the email world thus far is "not
>>> much"
>>> which makes me suspicious this is too abstract a problem for the
>>> outside
>>> world to care about.
>>>
>>
>> That's a fair question.
>>
>> The worry is that an RFC 4474 identity assertion forms what is
>> essentially a contract verification "I, identity service example.com,
>> have verified according to best current practices that the party
>> originating this message is authorized to use the identity
>> sip:[EMAIL PROTECTED]".
>
> Is 4474 really that emphatic? Can you point me to the section that
> defines
> that (sorry, I'm not being rhetorical). That's a pretty high barrier,
> and strikes
> me as a very hard thing for any bulk signing service to guarantee.
> DKIM
> is far weaker.
4474 provides a relatively strong assertion of identity. There isn't
one place in the text that says it, but again and again throughout the
text it covers potential weaknesses and why they aren't a problem. It
talks about identities being "verified". My professional opinion is
that, as written, RFC 4474, implies that the identity service has
strongly vouched for the identity indicated in the header.
Consider the text of Section 5:
> This document defines a new role for SIP entities called an
> authentication service. The authentication service role can be
> instantiated by a proxy server or a user agent. Any entity that
> instantiates the authentication service role MUST possess the
> private key of a domain certificate. Intermediaries that instantiate
> this role MUST be capable of authenticating one or more SIP users
> that can register in that domain.
This normatively states that the authentication service can
authenticate the users for which it voices, with the strong
implication (supported later in the text) that it actually does so.
Consider also the discussion of trusted entities:
> One solution to this problem is to use 'trusted' SIP intermediaries
> that assert an identity for users in the form of a privileged SIP
> header. A mechanism for doing so (with the P-Asserted-Identity
> header) is given in [12]. However, this solution allows only hop- by-
> hop trust between intermediaries, not end-to-end cryptographic
> authentication, and it assumes a managed network of nodes with
> strict mutual trust relationships, an assumption that is
> incompatible with widespread Internet deployment.
If you've represented yourself as a trusted provider of information,
and arrange for people to trust that information, then you've entered
into a contract to provide trustworthy services in a workmanlike
fashion. If you do a shoddy job, you're liable for the consequences to
your victims. This is true throughout legal systems derived from the
British common law, including the US. That's why every mutual fund
you might buy has a prospectus saying "Past history does not guarantee
future performance".
>
>>
>> We generally assume the "best current practices" something on the
>> order of "the party in question has presented credentials based on a
>> secret known to sip:[EMAIL PROTECTED] and presumably unknown to other
>> parties, and this presentation is consistent with prior interactions
>> had by this identity service and sip:[EMAIL PROTECTED]".
>
> That puts an awful lot of responsibility on the signer, especially
> if the
> signer isn't colocated with the credential verification. With DKIM,
> we
> do not make that kind of guarantee; it's up to the domain itself to
> determine what the best practices are which might be some
> cryptographic
> guarantee (say, SMTP auth), or might be layer 8 guarantee ("you'll
> lose your job if you do this"). By not making any explicit guarantee
> about the authorization to use a given local part, we skate around
> this thorny issue and frankly makes it a lot easier to roll out a
> signer.
Right. But 4474 makes strong assertions about the user part.
And that's why we either have to choose to "take with a grain of salt"
any Identity that contains something that might possibly be a phone
number, or we have to have some way of differentiating things that
came from the PSTN from those we really authenticated, or we have to
follow the letter of RFC 4474 and NOT provide an identity header when
there's any doubt. Several people have proposed this last choice, and
it's technically valid.
But since DTLS-SRTP does get some benefit from having an RFC 4474
header, this consequently weakens what we get from DTLS-SRTP whenever
there's a call that originates on the PSTN and transits an IP network.
This might be OK too, but if that's what we choose, then we have to
document the limitation.
And so far, we keep going around in circles explaining the problem.
And since we can't declare consensus on something people don't
understand, we'll keep going around in circles until either 1) people
get it, or 2) we give up.
>
>>
>> But when the identity assertion is coming from a PSTN caller ID, it's
>> significantly less authoritative statement: "I, the identity service
>> at example.com, think that this request came from +12142821376
>> because
>> this is the calling party identifier presented to my telephony
>> interface."
>
> Why is this limited to just the PSTN? Given your average megacorp or
> telephant,
> the possibility for spoofing of the local part seems pretty
> significant
> when you're
> talking about bulk signers. Weakening the guarantees to "you can
> complain
> to my SIP admins" is a lot easier to achieve in real life.
Might be. But we've currently established the expectation that an
Identity header serves to authenticate the calling party for access to
confidential records like voice mail, access to conference calls, and
so on. We can certainly go back and write in some guidance about the
meaningfulness of the assertion, if that's what we choose to do.
>
>>
>> There is a profound liability distinction between these two. Failure
>> to resolve it means that RFC 4474 identity headers would never be
>> more
>> credible than PSTN caller-ID, and we seem to think they need to be
>> more credible.
>
> I don't buy this: PSTN caller id is a cross domain transitive trust
> model.
> 4474 limits this to domain boundaries. That people want to put e.164
> like thingies in the localpart doesn't change who controls the
> namespace:
> it's the domain's, fullstop. Trying to go anything beyond saying
> that the
> localpart is anything beyond an opaque blob as far as the receiver is
> concerned is essentially saying that I want to tell you my rules for
> laying
> out my name space, part of which has thingies that look (but aren't)
> e.164 blobs.
>
Right -- the law is clear that as an identity server, you're
responsible for the accuracy of your work, no matter whether the user
part is numeric or textual or encodoes a phone number.
The question is, how do you avoid making misleading assertions?
> I really don't think you want to go here. The complexity here is
> enormous.
>
> But I'm not sure that my question was answered though: what do you
> expect a receiver to do differently? Are you thinking about human
> factors on the UAS? Something else?
Here's what 4474 already says:
> As a recipient of a request, a user agent that can verify signed
> identities should also support an appropriate user interface to
> render the validity of identity to a user. User agent
> implementations SHOULD differentiate signed From header field values
> from unsigned From header field values when rendering to an end-user
> the identity of the sender of a request.
So yes, we expect the UAS to treat these things differently based on
the presence of an Identity header. We could equally assume that it
will treat them differently based on strength of the identity
assertion. For example, one might choose to request a PIN from PSTN
callers attending a conference bridge, but not do so from VoIP callers
who have authorized identities.
--
Dean
--
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
