Subject: [Ecrit] Comments to draft-barnes-ecrit-auth-00.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jul 2007 22:54:48 +0200

Hi Richard,

thanks for writing this document.

I have a few comments:

Section 2.1: Location and Service URN

This is a very good summary of our currently assumed model.
I am, however, not sure about the following statement:

"
An important restriction to the applicability of this solution is that 
it requires the asserter possess a location value that can serve as part 
of an authenticator. For instance, if the authenticator is to be carried 
an INVITE message, the UAC must have access to its own location (with 
some degree of precision). Since there are situations where UACs may not 
have access to their own location (in access networks prevent this), 
this solution must be embedded in SIP in such a way that it can be 
inserted by a UAC, a UAS, or a proxy. In addition, if the Geolocation 
header is used to convey the location used here, then the SIP embedding 
must take into account the usage restrictions in [location-conveyance].
"

The UAC does not need to have access to precise location information. 
The considerations for "location hiding" apply here.

I am not sure what you mean with the sentences in the later part of the 
paragraph

Section 2.2: Asserter Identity

This model assumes that the PSAP operators network asserts that it has 
received an emergency call. It furthermore assumes that the VSP is able 
to verify which identities are indeed PSAP operators. Hence, some white 
lists of PSAP operators need to made available.

You want to use the Connected Identity for this purpose.

Please let me know whether I correctly understood this solution.

Section 2.3 Direct assertion

 From the description I got the impression that this is the plain SIP 
Identity. I cannot quite see how this prevents the attack. How does a 
VSP verify whether this is indeed an emergency call?

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.

The problem is that this is again complex, i.e., by no means better than 
the current solution we use as a working assumption.

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2007 10:08:12 -0500

Hannes,

> The considerations for "location hiding" apply here.

It doesn't need to have precise location, but it needs to have some 
location that's good enough for LoST.  This may not be the case, e.g., 
if it just got the PSAP URIs through HELD.

> I am not sure what you mean with the sentences in the later part of the 

draft-ietf-sip-location-conveyance puts a few relevant restrictions on 
the use of the Geolocation header, including the specification of which 
request and response types can carry it.  It also says that the value in 
the Geolocation header is always the location of the UAC.  I was 
thinking that the UAS (the PSAP) might include ITS location in a 
Geolocation header, which would be a problem.

> lists of PSAP operators need to made available.

That's correct.  I was imagining that you would have a dedicated 
authentication infrastructure for emergency services entities, so that 
if an entity were authenticated under this infrastructure, then you 
would know it's an emergency services entity.

> You want to use the Connected Identity for this purpose.

Yes, that's how a PSAP (as a UAS) could assert its identity.  If you 
were thinking about authority-to-citizen, you use SIP Identity for the 
originating authority to authenticate its identity.

> VSP verify whether this is indeed an emergency call?

The idea behind 2.3 is something SAML-like: An asserter that has a 
credential that shows that it's authorized to assert emergency calls, 
like an emergency services gateway.  The asserter inserts a marking 
(think SAML assertion) that asserts that the call is an emergency call.

> the current solution we use as a working assumption.
Using signed LoST responses could be a good option, one I'd like to 
discuss more.  I'll split this off into a separate thread.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2007 10:17:44 -0500

> c) verify whether the location information is contained in the service 

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

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 23 Jul 2007 10:54:00 -0500

At 10:17 AM 7/23/2007, Richard Barnes wrote:
>>into the SIP message together with the location information it used 
>>for retrieving the mapping. The VSP would verify that
>>c) verify whether the location information is contained in the 
>>service boundary.
>
>1. Remove item (c) from the verification steps, since the location 
>isn't really relevant (just that the destination is a PSAP).
>
>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:

exactly where is this in the SIP request?

>- Call is an emergency call if the To: address is a PSAP (as 
>verified by a signed LoST mapping)
>
>Pros:
>- No location required

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2007 10:57:47 -0500

James,

In the spirit of separating authenticators from how they're carried in 
SIP, we haven't picked out a place in the SIP message for it.  Seems 
most natural to me to include it as a body part.

--Richard

James M. Polk wrote:
>> "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.
>>
>> support peering and synchronization), so this is a good way to re-use 
>> that to support authentication of emergency calls.
>>
>> To summarize, then:
>>
>> Assertion:
>> - Call is an emergency call if the To: address is a PSAP (as verified 
>> by a signed LoST mapping)
>>
>> Pros:
>> - No location required

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 23 Jul 2007 11:27:15 -0500

At 10:57 AM 7/23/2007, Richard Barnes wrote:
>James,
>
>In the spirit of separating authenticators from how they're carried 
>in SIP, we haven't picked out a place in the SIP message for 
>it.  Seems most natural to me to include it as a body part.

- this makes it only viable to the UAS (receiver), and not any 
servers - and I'm not sure you want that
- you probably need a specific error (new or existing (with a new 
Warning or Reason code)) if it isn't processed correctly or is invalid
- you might require a new option-tag to mandate support for this, 
because it can easily be ignored otherwise
- this option-tag also allows you to mandate the recipient process 
this, otherwise the message fails (though this is usually reserved 
for SIP headers -- but I'm not sure where you are envisioning using 
this exactly)
- will this be mandatory to process if present?
- will SIP servers ever (need to) process this element?

- I'm looking for why this new element is *not* a new PIDF 
element...? Especially if SIP doesn't use this.

James

>>>>into the SIP message together with the location information it 
>>>>used for retrieving the mapping. The VSP would verify that
>>>>b) compare the identity of the mapping server with a a whitelist 
>>>>of valid mapping servers
>>>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.
>>>
>>>infrastructure is going to require strong authentication anyway 
>>>(to support peering and synchronization), so this is a good way to

---

From: Shida Schubert <[email-masked]>
Date: Mon, 23 Jul 2007 09:35:52 -0700

Richard,

 Comments inline..

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

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 11:56:38 -0500

> location to query the LoST server to begin with.

Having a lost <mapping> doesn't necessarily mean that the UA has the
location -- it could be that someone else that has the location did
the LoST lookup and passed the mapping to the UA.  For instance, if
the LCS (or other SIP configuration server) provided the <mapping>.

>  It also uses UPDATE to send the C-ID and doesn't mandate when this

(I think you mean the "called party's device".)  Since in the
individual-to-authority case, all of these are PSAP/ESRP issues, I
don't think theyr'e that big a deal.  IP PSAPs will be new anyway, so
they can be built to support C-ID, and they can be configured to send
the UPDATE within a specified period.  ISTM that this should be laid
out in the phonebcp.

>       device doesn't send UPDATE with connected-identity.

Yes, the idea would be to have a cut-off time specified in the
phonebcp, after which the call would be considered unverified.

>       C-ID won't be sent from the callee.

I'm not intimately familiar with C-ID, so I'm not sure if this is a
major issue or not.  Couldn't a proxy that wants the authentication
indicate it's support for C-ID?

Thanks for your comments,
--Richard

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 11:57:15 -0500

Ok, to be more specific, the concept would be analogous to the
approach used by Geolocation -- you'd have a header pointing to a body
part, and all the protocol machinery (warning codes, option tags, etc)
would need to be defined.

But I'd prefer not to get down into these details quite so soon.
--Richard

---

From: Shida Schubert <[email-masked]>
Date: Mon, 23 Jul 2007 10:46:14 -0700

> the LCS (or other SIP configuration server) provided the <mapping>.
 Okay. Obviously I overlooked that <mapping> was to be provided by the LCS.
> the UPDATE within a specified period.  ISTM that this should be laid
 Agree. Phone-BCP needs to cover this if we take this approach.
> phonebcp, after which the call would be considered unverified.
 Agree. Same as above.
> indicate it's support for C-ID?
 I agree what you suggest is possible, although I don't know what the 
spec says currently.
It's also possible for PSAP to always add the C-ID, despite the lack of 
indication for the
support of C-ID although it may be in conflict with the spec.

 Regards
  Shida

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 11:03:04 -0500

I think some people missed this point during the discussion:

3gpp and other SDOs who adopted ieee .11 technology, started to work on
the unauthenticated access by their own a while back. Thus, if ieee
didn't address and provide a native solution for the unauthenticated
case, then 3gpp/3gpp2, etc., would define their own solutions which
would probably be different from each other, resulting in solutions tied
to carriers. Would that be better?

Requests like don't do it should be addressed to the carriers who may
consider deploying it ...

 - gabor

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 12:07:40 +0200

> phonebcp, after which the call would be considered unverified.

You seem to be assuming some kind of call stateful model. SIP entities 
other than the end points or a B2BUA cannot terminate calls.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 12:12:19 +0200

> authentication of emergency calls.

I don't think this follows. For LoST to work, you only need trust "up" 
the tree, i.e., a resolver needs to know that the forest guide it 
contacts is indeed the one it wants to talk to. It gets references to 
hosts, which it verifies in the same manner, without anything beyond 
verifying a binding between a domain name and a server certificate.

All of this requires nothing more than a standard TLS host certificate 
that Verisign and others sell you today for your Apache server. This is 
a very different certification from "host foo.com is a legitimate LoST 
server" or even "foo.com is an authoritative LoST server for Jerusalem", 
whatever that may mean precisely.

Henning

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 09:02:12 -0400

Henning,

> You seem to be assuming some kind of call stateful model. 

Any call status authentication model that uses any message other than 
the INVITE will likely require this sort of state.  Otherwise, the 
verifying proxy has no way to know if the call never authenticates until 
after the call has finished.

Note that this level of state (e.g., keeping track of all the messages 
in an INVITE transaction) is useful for things like accounting and 
billing as well, so VSPs may be doing it anyway.

> SIP entities 

I didn't mean "cut-off time" in the sense of "time when the call is cut 
off," but rather in the sense of "time when a flag goes up that this 
call is not an emergency call."  A VSP could use this signal to take 
whatever action it deems appropriate -- initiating billing, filing wire 
fraud charges, or (if it has a B2BUA in the path) terminating the call.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 09:17:17 -0400

Henning,

ISTM that the assertions that LoST servers(and relying parties) are 
interested in would be something like

"The holder of X public key is an authoritative LoST server for region Y"

This is a parallel, but much different assertion than what the typical 
Verisign certificate says, i.e., "The holder of X public key is the 
holder of Y domain name."  This statement has no relevance to LoST.

Encoding such assertions in public-key certificates would result in an 
authentication infrastructure very much like the IP address / AS number 
PKI being developed in the SIDR WG:
<http://tools.ietf.org/html/draft-ietf-sidr-arch-01>
The multi-tree design and the existence of field guides in the mapping 
architecture complicates things a little, but the structure would be 
mostly the same within the trees.  And the requirements for "resource 
holding" fields in the certificates are very similar.

Three uses immediately come to mind:
1. LoST resolution security: Servers in the LoST heirarchy are assured 
of the identities of servers "up" the tree so that it knows that they're 
the ones it wants to talk to.
2. LoST provisioning security: Servers in the LoST heirarchy (and FGs) 
are assured of the identities of servers "down" the tree so that they 
know who's providing them information, e.g., coverage maps.  Also 
applies to "lateral" peering among FGs.
3. Signed LoST mappings: When a third party gets a signed LoST mapping, 
he can verify that the signing party is the authoritative server for the 
given coverage area.

This is what I had in mind in my earlier email.  Hope this helps to clarify.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 17:59:50 +0200

> billing as well, so VSPs may be doing it anyway.

This is not the right forum for this discussions, but if a VSP relies on 
such capabilities, they are likely to be in (financial) trouble. One of 
the core assumptions for ECRIT is that we don't mess with SIP call flows 
or create emergency-specific call flows.

> 
>> SIP entities other than the end points or a B2BUA cannot terminate calls.
> 

See above.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 18:06:09 +0200

Richard,

That's what I assumed you meant. Unfortunately, this requires a world 
government or equivalent, which seems somewhat outside our scope to 
create or assume. Simply wishing that some global PKI comes into 
existence has a rather dismal track record of success. I don't know who 
is going to certify the authoritative LoST server for Taiwan or parts of 
the former Soviet Union, but I suspect that creating any kind of global 
PKI is going to be hard, particularly since the domain-level 
authenticity I described is likely to be sufficient for secure operation 
of the system. I'm curious as to whether there is any existing example, 
outside of emergency calling, of such a global role-based certification 
authority.

Henning

Richard Barnes wrote:
>> that Verisign and others sell you today for your Apache server. This 
>> is a very different certification from "host foo.com is a legitimate 
>> LoST server" or even "foo.com is an authoritative LoST server for 
>> Jerusalem", whatever that may mean precisely.
>>
>> Henning
>>
>>
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 12:53:42 -0400

Henning,

I encourage you to take a look at what the SIDR WG has been up to, 
namely defining a PKI that encodes assertions of the form

"The holder of X public key is the holder of address space Y"
"The holder of X public key is the holder of AS number Z"

Administration of this PKI is globally distributed, and there will 
likely not be a single root, but rather a set of cross-certifications 
among the RIRs.  This arrangement allows ISPs to validate certificates 
from the entire PKI based only on trust with their chosen RIR.  This PKI 
is currently being implemented by the RIRs.

To make the analogy with LoST, here's one way you could arrange things:
1. Each tree will have an autonomously administered, hierarchical PKI -- 
the LoST folks in Taiwan won't care about the LoST folks in the Ukraine, 
or Sierra Leone, or anywhere else.
2. FGs sign certificates for the roots of the trees with which they 
peer.  I.e., they create certs that verify that "The holder of X public 
key is the root for region Y", given trust in the FG.
3. Seekers/resolvers use FG keys as trust anchors.

If somebody gets something signed under this structure, he
1. Validates up to the root of the tree, then
2. Checks to see if any of his FGs vouch for that root.

This model only requires local interactions, e.g.:
1. Each tree manages its own PKI.
2. Each FG only deals with the trees it already deals with.
3. Each seeker/resolver only deals with the FGs it already deals with.

There's no global coordination needed here, only an augmentation of 
relationships already required by the mapping architecture.

--Richard

Henning Schulzrinne wrote:
>> authentication infrastructure very much like the IP address / AS 
>> number PKI being developed in the SIDR WG:
>> of the identities of servers "up" the tree so that it knows that 
>> they're the ones it wants to talk to.
>> 3. Signed LoST mappings: When a third party gets a signed LoST 
>> mapping, he can verify that the signing party is the authoritative 
>> server for the given coverage area.
>>
>>> I don't think this follows. For LoST to work, you only need trust 
>>> "up" the tree, i.e., a resolver needs to know that the forest guide 
>>> it contacts is indeed the one it wants to talk to. It gets references 
>>> to hosts, which it verifies in the same manner, without anything 
>>> beyond verifying a binding between a domain name and a server 
>>> certificate.
>>>
>>> All of this requires nothing more than a standard TLS host 
>>> certificate that Verisign and others sell you today for your Apache 
>>> server. This is a very different certification from "host foo.com is 
>>> a legitimate LoST server" or even "foo.com is an authoritative LoST 
>>> server for Jerusalem", whatever that may mean precisely.
>>>
>>> Henning
>>>
>>>
>>>
>>
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 19:17:40 +0200

The problem is that the VSP in Sierra Leone will need to deal with their 
  traveling customer visiting Taiwan (or the impostor pretending to 
visit Taiwan). These are in different trees, obviously.

Richard Barnes wrote:
>> existence has a rather dismal track record of success. I don't know 
>> who is going to certify the authoritative LoST server for Taiwan or 
>> parts of the former Soviet Union, but I suspect that creating any kind 
>> of global PKI is going to be hard, particularly since the domain-level 
>> authenticity I described is likely to be sufficient for secure 
>> operation of the system. I'm curious as to whether there is any 
>> existing example, outside of emergency calling, of such a global 
>> role-based certification authority.
>>
>> Henning
>>
>>
>> Richard Barnes wrote:
>>> Henning,
>>>
>>> This is a parallel, but much different assertion than what the 
>>> typical Verisign certificate says, i.e., "The holder of X public key 
>>> is the holder of Y domain name."  This statement has no relevance to 
>>> LoST.
>>>
>>> Encoding such assertions in public-key certificates would result in 
>>> an authentication infrastructure very much like the IP address / AS 
>>> The multi-tree design and the existence of field guides in the 
>>> mapping architecture complicates things a little, but the structure 
>>> would be mostly the same within the trees.  And the requirements for 
>>> "resource holding" fields in the certificates are very similar.
>>>
>>> 1. LoST resolution security: Servers in the LoST heirarchy are 
>>> assured of the identities of servers "up" the tree so that it knows 
>>> that they're the ones it wants to talk to.
>>> 2. LoST provisioning security: Servers in the LoST heirarchy (and 
>>> FGs) are assured of the identities of servers "down" the tree so that 
>>> they know who's providing them information, e.g., coverage maps.  
>>> Also applies to "lateral" peering among FGs.
>>>> it contacts is indeed the one it wants to talk to. It gets 
>>>> references to hosts, which it verifies in the same manner, without 
>>>> anything beyond verifying a binding between a domain name and a 
>>>> server certificate.
>>>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 13:27:52 -0400

Yes, whoever validates the signature an object signed by the Taiwanese 
LoST server will need to get certificates from Taiwanese tree.  This is 
not a hard problem: There are existing mechanisms to do this using LDAP, 
FTP, and HTTP (RFC 2559 and 2589).  The RIRs are just throwing 
everything in one big, distributed database that ISPs fetch using rsync.

Also, remember that this validation doesn't necessarily have to be done 
in real time with the call.  I think it was Barbara that said in an 
earlier discussion that it would be good enough to have a forensic 
capability.

--RB

Henning Schulzrinne wrote:
>  traveling customer visiting Taiwan (or the impostor pretending to visit 
> Taiwan). These are in different trees, obviously.
> 
> Richard Barnes wrote:
>> Henning,
>>
>> from the entire PKI based only on trust with their chosen RIR.  This 
>> PKI is currently being implemented by the RIRs.
>>
>> 1. Each tree will have an autonomously administered, hierarchical PKI 
>> -- the LoST folks in Taiwan won't care about the LoST folks in the 
>> Ukraine, or Sierra Leone, or anywhere else.
>> peer.  I.e., they create certs that verify that "The holder of X 
>> public key is the root for region Y", given trust in the FG.
>>> parts of the former Soviet Union, but I suspect that creating any 
>>> kind of global PKI is going to be hard, particularly since the 
>>> domain-level authenticity I described is likely to be sufficient for 
>>> secure operation of the system. I'm curious as to whether there is 
>>> any existing example, outside of emergency calling, of such a global 
>>>> FGs) are assured of the identities of servers "down" the tree so 
>>>> that they know who's providing them information, e.g., coverage 
>>>> maps.  Also applies to "lateral" peering among FGs.
>>>>> server. This is a very different certification from "host foo.com 
>>>>> is a legitimate LoST server" or even "foo.com is an authoritative 
>>>>> LoST server for Jerusalem", whatever that may mean precisely.
>>>>>
>>>>> Henning
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 13:38:44 -0400

> There are existing mechanisms to do this using LDAP, 
> FTP, and HTTP (RFC 2559 and 2589).  

Oops, that should be RFC 2585.
--Richard

>> The problem is that the VSP in Sierra Leone will need to deal with 
>> their  traveling customer visiting Taiwan (or the impostor pretending 
>> to visit Taiwan). These are in different trees, obviously.
>>
>> Richard Barnes wrote:
>>> Henning,
>>>
>>> among the RIRs.  This arrangement allows ISPs to validate 
>>> certificates from the entire PKI based only on trust with their 
>>> chosen RIR.  This PKI is currently being implemented by the RIRs.
>>>
>>>> That's what I assumed you meant. Unfortunately, this requires a 
>>>> world government or equivalent, which seems somewhat outside our 
>>>> scope to create or assume. Simply wishing that some global PKI comes 
>>>> into existence has a rather dismal track record of success. I don't 
>>>> know who is going to certify the authoritative LoST server for 
>>>> Taiwan or parts of the former Soviet Union, but I suspect that 
>>>> creating any kind of global PKI is going to be hard, particularly 
>>>> since the domain-level authenticity I described is likely to be 
>>>> sufficient for secure operation of the system. I'm curious as to 
>>>> whether there is any existing example, outside of emergency calling, 
>>>> of such a global role-based certification authority.
>>>>
>>>> Henning
>>>>
>>>>
>>>> Richard Barnes wrote:
>>>>> Henning,
>>>>>
>>>>> typical Verisign certificate says, i.e., "The holder of X public 
>>>>> key is the holder of Y domain name."  This statement has no 
>>>>> relevance to LoST.
>>>>>
>>>>> would be mostly the same within the trees.  And the requirements 
>>>>> for "resource holding" fields in the certificates are very similar.
>>>>>
>>>>>>> (to support peering and synchronization), so this is a good way 
>>>>>>> to re-use that to support authentication of emergency calls.
>>>>>>
>>>>>> "up" the tree, i.e., a resolver needs to know that the forest 
>>>>>> guide it contacts is indeed the one it wants to talk to. It gets 
>>>>>> certificate that Verisign and others sell you today for your 
>>>>>> Apache server. This is a very different certification from "host 
>>>>>> foo.com is a legitimate LoST server" or even "foo.com is an 
>>>>>> authoritative LoST server for Jerusalem", whatever that may mean 
>>>>>> precisely.
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 20:47:22 +0200

However, unless there is a global root, the VSP has no way to 
distinguish a valid Taiwanese cert from some randomly created one. Just 
being able to retrieve the cert makes no difference. The impostor can 
point to a cert by his best buddy and the VSP has no way to distinguish 
them. The only good way is to recognize, ssh-style, that the new 
certificate for Taiwan differs from the one the VSP saw last week, which 
  means that the new one is probably dubious. This may well be 
sufficient in practice.

I don't see how you avoid either cross-certification, which doesn't 
scale, or a global root certificate. ISPs have a far easier time with 
that, since AS "territories" are not in dispute, for example.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 30 Jul 2007 19:07:18 -0500

I'd like to give Henning a chance here... I think Richard is making
genuine practical proposals with respect to how trust is going to be
tested. Henning has spoken at a higher level about trust "going up the
tree" and ensuring that the forest guide is the one that you want and
that it provides the trustable host list.

Can you elaborate, Henning, on how you see a forest guide hosted in a
particular jurisdiction actually establishing the trusted host list
belonging to another jurisdiction?

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, 31 July 2007 3:28 AM
To: Henning Schulzrinne
Cc: ECRIT
Subject: Re: [Ecrit] Signed LoST mappings

--RB

> The problem is that the VSP in Sierra Leone will need to deal with
their 
>  traveling customer visiting Taiwan (or the impostor pretending to
visit 

>> among the RIRs.  This arrangement allows ISPs to validate
certificates 

>>> That's what I assumed you meant. Unfortunately, this requires a
world 

>>>> typical Verisign certificate says, i.e., "The holder of X public
key 

>>>> would be mostly the same within the trees.  And the requirements
for 

>>>> This is what I had in mind in my earlier email.  Hope this helps to

>>>> clarify.
to 
>>>>> "up" the tree, i.e., a resolver needs to know that the forest
guide 

>>>>> certificate that Verisign and others sell you today for your
Apache 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Jul 2007 21:08:20 -0400

FGs are already a locus of trust: By peering with tree roots, they 
effectively vouch for the validity of roots already.  For each FG to 
provide a list of certificates for the roots with which it peers is 
conceptually no different than providing a list of DNS names for these 
roots, and offers lots of security benefits.  (If there are bandwidth 
concerns, you could just as easily define a mechanism for querying for 
specific certs or domain names.)

I'm not sure what the basis is for your argument that this type of 
cross-certification doesn't scale.  Any given FG is only concerned with 
the roots from which it receives information, and for any given 
validation resolver/seeker is only concerned with certification of a 
root by its FGs.  So the number of certs at each FG scales as O(#roots) 
and the number of certs for each resolver/seeker validation scales as 
O(#peeredFGs) in the worst case.  Cert path length only grows as 
O(avgTreeDepth + 1), since a FG can create new certs for roots it learns 
about through its peers.

--Richard

Henning Schulzrinne wrote:
>  means that the new one is probably dubious. This may well be sufficient 
> in practice.
> 
>> LoST server will need to get certificates from Taiwanese tree.  This 
>> is not a hard problem: There are existing mechanisms to do this using 
>> LDAP, FTP, and HTTP (RFC 2559 and 2589).  The RIRs are just throwing 
>> Also, remember that this validation doesn't necessarily have to be 
>> done in real time with the call.  I think it was Barbara that said in 
>> an earlier discussion that it would be good enough to have a forensic 
>> capability.
>>
>> --RB
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 31 Jul 2007 09:08:12 +0200

To make easier to talk about, I'm assuming that each country has a tree 
and that we have standard TLS host certs.

The resolver is pre-configured with a host name of the FG. (I'm saying 
host name; in reality it's a NAPTR thing, but this doesn't seem to 
matter.) When the resolver connects to the FG, it uses the FG TLS cert 
to verify that it is indeed connected to the right FG. It needs to trust 
the FG to do the right thing. The FG in turn peers with other FGs, again 
based on pre-configured trust relationships and host certificates.

The FG is configured with the top of the country tree(s), again with a 
domain name. The coverage maps contain domain names of the child nodes.

For each step, the querier can verify that they are talking to the right 
  host. The trust is by nature transitive, but we can't avoid that.

There are two authenticity problems, which are largely orthogonal:

(1) Assuring the resolver and host that their resolution traverses a 
legitimate chain of LoST servers. See above.

(2) Proving to a third party that a LoST binding was indeed 
"authorized". This is harder.

Henning

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 31 Jul 2007 14:00:23 -0400

I'd like to step back (for a moment) from the discussion of whether 
there is a way for a third party to verify that a LoST mapping for a 
Taiwanese PSAP is authentic (or authoritative).

At a high level Richard proposed that the problem of fruad prevention 
(verifying that a call is actually headed to a PSAP) can be solved more 
easily if we utilize not just the SIP INVITE but a response to the SIP 
INVITE. In particular, if we use Connected Identity (if PSAPs have 
appropriate credentials) or Signed LoST Mappings (if LoST servers have 
appropriate credentials) or something else (if someone else has 
appropriate credentials).

Henning provided the following response:

> [Richard Barnes:] Note that this level of state (e.g., keeping track 
> of all the messages in an INVITE transaction) is useful for things 
> like accounting and billing as well, so VSPs may be doing it anyway.
>
> [Henning Schulzrinne:] This is not the right forum for this 
> discussions, but if a VSP relies on such capabilities, they are likely 
> to be in (financial) trouble. One of the core assumptions for ECRIT is 
> that we don't mess with SIP call flows or create emergency-specific 
> call flows.
>
Henning seems to be saying that any mechanism for fraud prevention which 
relies on a message other than the SIP INVITE is not useful.

Am I interpreting Henning's response correctly?

Do others feel that using messages other than the SIP INVITE is not a 
useful approach to fraud prevention?

- Matt Lepinski :->

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 31 Jul 2007 13:23:35 -0500

Matt

Looking at this example topology

Alice--INVITE-->Proxy1-->Proxy2-->ESRP/ESInet-->EmSvcsProxy-->PSAP

Alice<--Proxy1<--Proxy2<--ESRP/ESInet<--EmSvcsProxy<--200OK--PSAP

Q#1 - Where is this 200 OK important in your context (for verifying 
intended destination)?

Q#2 - Why is this important at this point in the topology?

Q#3 - What do you expect the SIP element to do with any indication 
you are creating here?

Little new can be between Alice and the ESRP, as we're attempting to 
create a solution with the LEAST amount of changes to SIP --> because 
the more changes there are, the more complicated the solution is, the 
less likely it will be implemented right --> which is the goal, right?

The ESRP should be a B2BUA or SBC, so changes behind it towards the 
PSAP call taker's UA need to highlighted as only being in that part 
of the topology.

We cannot expect COTS SIP products to do too much, yet I don't 
believe COTS SIP equipment will be used at the ESRP or between it and the PSAP.

At 01:00 PM 7/31/2007, Matt Lepinski wrote:
>At a high level Richard proposed that the problem of fruad 
>prevention (verifying that a call is actually headed to a PSAP) can 
>be solved more easily if we utilize not just the SIP INVITE but a 
>response to the SIP INVITE. In particular, if we use Connected 
>Identity (if PSAPs have appropriate credentials) or Signed LoST 
>Mappings (if LoST servers have appropriate credentials) or something 
>else (if someone else has appropriate credentials).
>
>>[Richard Barnes:] Note that this level of state (e.g., keeping 
>>track of all the messages in an INVITE transaction) is useful for 
>>things like accounting and billing as well, so VSPs may be doing it anyway.
>>
>>discussions, but if a VSP relies on such capabilities, they are 
>>likely to be in (financial) trouble. One of the core assumptions 
>>for ECRIT is that we don't mess with SIP call flows or create 
>>emergency-specific call flows.
>Henning seems to be saying that any mechanism for fraud prevention 
>which relies on a message other than the SIP INVITE is not useful.
>
>Do others feel that using messages other than the SIP INVITE is not 
>a useful approach to fraud prevention?
>
>- Matt Lepinski :->
>
>