We've realized we have a specification mutual exclusion.
RFC 4474 as written precludes the insertion of an Identity header by
an authentication service into a SIP message produced by a PSTN
gateway. However, DTLS-SRTP as written needs such an Identity header
in order to be able to verify that the media key fingerprint has not
been altered by a MITM who is also attacking on the media path.
We've heard a bunch of suggestions, and so far I think the best has
been to adopt a convention (and possibly a new extension) for encoding
the From: header field in messages coming from gateways, along with a
convention for interpreting Identity headers on those messages as
"asserting the identity of the gateway", instead of "asserting the
telephone number".
Someone suggested the idea of using a "user=phone" parameter as this
indicator. I initially dismissed the idea. However, after reading
Paul's recent analysis of what user=phone means (from his view,
nothing), and in light of my counterexample (that the user=phone
modifier can influence routing) I've reconsidered my earlier dismissal
of the idea.
RFC 3261 Section 19.1.1 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like telephone numbers. If the user string contains a
telephone number formatted as a telephone-subscriber, the user
parameter value "phone" SHOULD be present. Even without this
parameter, recipients of SIP and SIPS URIs MAY interpret the
pre-@ part as a telephone number if local restrictions on the
name space for user name allow it
If we made it mandatory for a PSTN gateway to assert identities using
user=phone and documented that Identity headers over an identity with
a user=phone parameter do not assert the "user part" of that identity,
then I think we'd have a complete solution.
Corollary , we need to document that a "phone" UAS that is attached to
the Internet does NOT use "user=phone" even if its user ID is a phone
number and the ENUM entry for that phone number happens to point at
this user ID at this UAS (or supporting domain).
In other words, we'd be changing the above text to say that the
user=phone does NOT distinguish between phone numbers and user names,
but that it distinguishes between phone numbers on the PSTN and SIP
phone numbers or user IDs.
Let me restate: user=phone applies only to things that transit a PSTN
gateway.
So for example if Alice at +12142821376 were to call Bob at
+19725199190 (and where +19725199190 terminated on a gateway in domain
example.com), we might see that gateway generate an INVITE like:
INVITE tel:+19725199190 SIP/2.0
From: sip:[EMAIL PROTECTED];user=phone
To: tel:+19725199190
...
The authentication service at example.com could then reasonably insert
an Identity header field. Receivers of this INVITE would know that the
"user=phone" modifier implies that the Identity header asserts nothing
whatsoever about the user part (+12142821376) of the request, and that
the Identity header proves only that the request came from a gateway
authenticated by example.com.
Alternatively the INVITE and TO might be populate with sip:[EMAIL
PROTECTED];user=phone
, but I think it cleaner to document tel:
Also alternatively, the From: might be sip:[EMAIL PROTECTED];user=phone
Note that with this approach "tel:" does not mean "on the PSTN",
rather it means "in the namespace of E.164", which is an entirely
different thing. It is perfectly legitimate to use tel: URIs to refer
to devices that are entirely on the Internet. In fact, this might be
the model used if one enum device were to call another using an E.164
number.
--
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
