Richard,
Comments inline..
Richard Barnes wrote:
Another solution would be to sign a LoST mapping response (with a
service boundary). The SIP UA would then add the signed LoST mapping
into the SIP message together with the location information it used
for retrieving the mapping. The VSP would verify that
a) the signature of the mapping is correct.
b) compare the identity of the mapping server with a a whitelist of
valid mapping servers
c) verify whether the location information is contained in the
service boundary.
I would make a couple of modifications:
1. Remove item (c) from the verification steps, since the location
isn't really relevant (just that the destination is a PSAP).
2. Generalize item (b). It's not practical to maintain a global
whitelist of mapping servers; what you'd want instead is some sort of
"LoST PKI" that you would use to verify identities. You could have
PKI hierarchies that correspond to tree hierarchies, with root tree
nodes used as trust anchors, or you could use some FGs as trust anchors.
I like this approach, because it only gives you one thing to
credential, namely LoST servers. Chances are that the LoST
infrastructure is going to require strong authentication anyway (to
support peering and synchronization), so this is a good way to re-use
that to support authentication of emergency calls.
To summarize, then:
Assertion:
a) Include a signed LoST <mapping> element in the SIP message
The fact that you get LoST <mapping> element indicates that UA has a
location to
query the LoST server to begin with. In which case, UA would naturally
holds the location
it used for mapping thus includes the location in the SIP request which
can be utilized by
VSP to verify the rigidness of emergency call by simply querying the
LosT server itself.
I thought you were trying to address a problem when location is not
available neither for
VSP nor UA while VSP wishes to verify that call indicated as an
emergency call is really
an emergency call.
Use of connected-identity (C-ID) has some issues as well. AFAIK the C-ID
requires calling party's device and called party's domain to support C-ID.
It also uses UPDATE to send the C-ID and doesn't mandate when this
UPDATE is sent.
So the following issues may arise
1. I can call Hannes with indication that it's an emergency call, VSP
forwards the
call and I establish a call with Hannes and start talking to him
as long as Hannes's
device doesn't send UPDATE with connected-identity.
2. As far as I know C-ID although can be used by VSP to verify
callee's identity, it is
the UAC that actually set the option tag indicating the support
for C-ID which is necessary
information for UAS or callee's domain to trigger the C-ID
process. So if UAC doesn't
indicate that it supports C-ID (Although VSP supports it) using
the defined option-tag,
C-ID won't be sent from the callee.
Verification:
a) Verify the signature on the <mapping> element
b) Verify that the signer is trusted
c) Verify that the To: address for the dialog is contained in a <uri>
Trust model:
- Trust in LoST infrastructure and LoST credentialing authorities
- Call is an emergency call if the To: address is a PSAP (as verified
by a signed LoST mapping)
Pros:
- No location required
- Very similar to the location+URN use case
Cons:
- Requires credentialing of LoST servers
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|