Subject: [Ecrit] thoughts on draft-taylor-ecrit-security-threats-00

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Oct 2005 16:15:06 -0400

Here are my comments on the security threats and requirements document.

Overall, I like the format and structure of the document.  The  
authors have done a good job.

However, I am concerned about the security requirements from two main  
perspectives:

a) First, I question whether or not they are overly burdensome with  
regard to performance.  Invoking channel security is more than just a  
few roundtrips and is CPU intensive.  Additionally, the requirement  
for object signing may be even more burdensome, as it requires the  
triple of location info, URI, and timestamp (that's a lot of data to  
sign -- especially in the geo x,y,z case, and just how often does it  
need resigning).  And I certainly don't think both of these measures  
are required.

b) There is no discussion regarding what a user would do if  
authentication fails.  What does it mean?  Do they just put down the  
phone and let their house burn down?  Or do they continue on with the  
call in hopes that the authentication failure is false indicator?

Anyway, here are my comments:

 From Section 1:
> As a corollary, the present document
> does not distinguish between the case where location is provided by
> reference and the case where it is provided by value within session
> signalling.

If both location by reference and location by value are to be part of  
the solution, then I think the security differences between the two  
should be enumerated.  Is this planned for a future rev, or is this  
analysis pending a decision on the use of location by reference?

 From Section 4.3.1.1
> To avoid
> launching DoS, the mapping server should be capable of limiting the
> queries from a single IP, especially when an anonymous mapping is
> requested, at a particular time.

I keyed in on the word "anonymous".  Perhaps this is one of those  
cases where there is no agreement on the requirement, but I thought  
ALL mapping requests would be anonymous.  As in, no user information  
is sent to the mapping server.

 From Section 4.3.2
> An adversary might run a faked mapping server aiming to pretend that
> it is a legitimate server.  This would lead an emergency caller to
> get bogus URI(s) that hinder a caller not to avail the emergency
> service.  It is necessary for the client to authenticate and possibly
> to authorize the mapping server as part of the emergency call
> procedure.

Taking the last part first, I'm not sure how a client is to authorize  
the use of a mapping server.  This needs to be explained.

With regard to authentication of the mapping server, I do not agree  
that this is necessary for three reasons:

a) With authentication of the mapping server, I'm assume that this  
refers to some sort of crypto, most likely TLS.  There are two  
implications here: there is a performance penalty for every mapping  
request and there is the overhead of getting client vendors and  
server operators to agree upon trust anchors.

b) What does the usage scenario say about an improper  
authentication?  If the mapping server does not authenticate, is the  
call dropped?

c) There is another alternative, which is to sign the data the server  
gives back.

 From Section 4.3.2.1
> Channel Security: It is possible to establish a secure channel e.g.,
>    TLS to ensure the authenticity of the given mapped information.
>    Additionally, there are several advantages in establishing a
>    secure channel such as confidentiality protection, replay
>    protection and in case if the mapping server realizes that it is
>    under flooding attack (query) it might also request the
>    certificate, if available, to verify the identity of the
>    requesting client.  Consequently, this step might decrease the
>    performance of the mapping service since the certificate
>    processing and key exchange mechanism pose serious performance
>    degradation for the mapping server.

I think authentication of the client with user-based certs (assigned  
to individuals) is unlikely to see deployment in our life times.   
Using vender assigned certs is a much more reasonable idea, but it  
suffers from the flea market problem.

> Object Security: It is possible to use object security e.g., S/MIME
>    to sign the individual information in the query/response message
>    of the mapping service.  This mechanism with various settings also
>    provides authentication, a degree of confidentiality protection of
>    the sender and prevents from the replay attacks.

Things like S/MIME are vulnerable to replay, and therefore object  
security is of little benefit.  Perhaps the proper term needed is  
transaction signing.  A request is made, and the response contains a  
signed answer plus transaction ID (something from the request).

 From Section 5.4
> o  The maping client MUST be able to authenticate the mapping server.

Covered above.

> o  The mapping server MUST be provide data origin authentication
>    thereby ensuring that the provided data items are indeed from the
>    claimed source.

How is a client to know that civic data or geo data is not from a  
certain source?

> o  The mapping server SHOULD provide information to ensure that it is
>    authoritive for the provided information.

Same as above.  I don't understand how a machine, especially one that  
is trying to make a fast emergency call, will know that the server at  
IP address 10.0.0.1 is NOT authoritative for mapping 123 Main St. to  
a URI.

If the basis is not on the data but on accreditation, then this needs  
to be called out.  And this brings into question which trust anchors  
the client will use.

I think Section 5.5 is out of scope for ECRIT.

 From Section 5.6
>       When the query is issued on behalf of the mapping client then  
> the
>       mapping server must take necessary steps to determine  
> conclusively
>       that the data came from a genuine mapping server or an
>       authoritative mapping server (remote).
>
>       If the query procedure is done by the client then the client  
> must
>       authenticate both the home mapping server and remote mapping
>       servers before accepting the response information.

So the client has to contact two mapping servers?  And both have to  
have the same information?

 From Section 5.7
>    However, even if the AIP or ISP provides a signed location, it is
>    difficult to ensure that such a signed location object is only used
>    for calls from that location, as it will have to be copied from a
>    location delivery protocol to the call signaling protocol.  For
>    example, a third party could obtain such a signed location  
> object and
>    use it elsewhere.  Naturally, timestamps will restrict such  
> useage to
>    the order of minutes or hours, depending on how often location
>    information is updated.

Wouldn't including the IP address in the signed data stop the  
location object from having validity outside the AIP/ISP network?

-andy

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Oct 2005 16:24:13 +0200

hi andy,

here is the second part of my response:

~snip~

> analysis pending a decision on the use of location by reference?

it is currently not clear whether we will both approaches. the use of 
reference is not uncontroversal. in any case, we should reflect this.
as such, i think that a future version of the document could talk a bit 
more about this subject, if it turns out to be relevant for us.

> I keyed in on the word "anonymous".  Perhaps this is one of those  cases 
> where there is no agreement on the requirement, but I thought  ALL 
> mapping requests would be anonymous.  As in, no user information  is 
> sent to the mapping server.

if the end host queries the mapping server then i fully agree with you.
it might, however, be the case that a proxy server that invokes a query 
to the mapping server.

it might, however, be good to phrase this in a different way.

> the use of a mapping server.  This needs to be explained.

the problem is the following: do we want to prevent the case where a 
client is provided false uri's? if yes, then we need to make sure that 
the emergency caller talks to an entity that is actually allowed to 
operate as a psap. how do you verify this? one way (and this is a 
solution specific discussion) is to place certain information into the 
certificate. authentication is clearly not sufficient.

> request and there is the overhead of getting client vendors and  server 
> operators to agree upon trust anchors.

i am not sure about the performance impact of running tls. that does not 
seem to be the most difficult part, at least not for today's equipment.

i agree with regard to the trust anchors. that's indeed a difficult part.

> 
> b) What does the usage scenario say about an improper  authentication?  
> If the mapping server does not authenticate, is the  call dropped?

correction: the mapping client authenticates the mapping server. if the 
mapping client cannot authenticate the server then it can decide what 
todo. at least it has the chance to verify something.

> c) There is another alternative, which is to sign the data the server  

do you refer to the original source of the information or the mapping 
server that directly talks to the mapping client? if you talk about the 
former one then i need to remember you to appendix a of 
<draft-hardie-ecrit-iris-03.txt>.

an overall comment:
do you think that there should not be any security between the mapping 
client and the mapping server. if you think so then we certainly have no 
way to prevent a number of attacks. this does not seem to be attractive 
either. providing at least the possibity to prevent these attacks is 
worth thinking about it.

> I think authentication of the client with user-based certs (assigned  to 
> individuals) is unlikely to see deployment in our life times.   Using 
> vender assigned certs is a much more reasonable idea, but it  suffers 
> from the flea market problem.

this referred primarily to a non-end user that requests the mapping.
furthermore, i would like to mention our discussion at the ietf#63 
geopriv meeting when we spoke about the ability to prevent denial of 
service attack and the usage of end-to-end security using special client 
side certificates was seen as a potential way to address some of the 
problems (note that credentials that are different to the credentials 
used for service access or network access).

> signed answer plus transaction ID (something from the request).

you are right. s/mime itself does not provide protection against replay 
attacks. the term "transaction security" seems to be appropriate.

the aspect of object signaling needs to receive more attention 
particularly with regard to replay protection prevention.

> How is a client to know that civic data or geo data is not from a  

this was intentionally phrased provocative.
that's indeed difficult... good question.

> IP address 10.0.0.1 is NOT authoritative for mapping 123 Main St. to  a 
> URI.
> 

this is actually quite difficult. essentially, if you want to ensure 
that the information provided by a specific mapping server X is correct 
then the parent of this server needs to assertion that mapping server X 
is responsible for a certain geographical area.

i don't know whether we want to have this feature or not? maybe this 
functionality is more important for the server-to-server communication 
part (that is currently outside the scope of our work).

> I think Section 5.5 is out of scope for ECRIT.
true.

>  From Section 5.6
> 
>>       When the query is issued on behalf of the mapping client then  the
>>       mapping server must take necessary steps to determine  conclusively
>>       If the query procedure is done by the client then the client  must

i think that this section is very misleading. i either suggest to delete 
it or to entirely rephrase it.

>>    example, a third party could obtain such a signed location  object and
>>    use it elsewhere.  Naturally, timestamps will restrict such  useage to
> Wouldn't including the IP address in the signed data stop the  location 
> object from having validity outside the AIP/ISP network?
including the ip address in the signed information blob might work in 
some areas but it does not work if you are in a network that uses a 
private address space.

thanks for the review. we certainly need to update the text.

ciao
hannes

---

From: Andrew Newton <[email-masked]>
Date: Thu, 27 Oct 2005 15:02:15 -0400

It just occured to me that this document does not address two areas:  
security and threats in location delivery (dhcp, etc..) and security  
and threats of PSAP boundaries.  These are things that need to be  
discussed.

Anyway, my reply is in-line:

On Oct 27, 2005, at 10:24 AM, Hannes Tschofenig wrote:
>> cases where there is no agreement on the requirement, but I  
>> thought  ALL mapping requests would be anonymous.  As in, no user  
>> information  is sent to the mapping server.
>>
>
> it might, however, be the case that a proxy server that invokes a  
> query to the mapping server.

I still do not understand.  Why would user information be present if  
a proxy queries the LCMS?  Again, I thought ALL mapping requests  
would be anonymous.

>> Taking the last part first, I'm not sure how a client is to  
>> authorize  the use of a mapping server.  This needs to be explained.
>>
>
> the problem is the following: do we want to prevent the case where  
> a client is provided false uri's? if yes, then we need to make sure  
> that the emergency caller talks to an entity that is actually  
> allowed to operate as a psap. how do you verify this? one way (and  
> this is a solution specific discussion) is to place certain  
> information into the certificate. authentication is clearly not  
> sufficient.

There is a difference between authentication and authorization.  It  
seems that once a client has authenticated the identity of the  
server, full authorization is automatic.  If, however, there is a  
different authorization step or perhaps the client authorizes the  
server for use in only geo mapping or whatever, I am at a loss to  
know what that is or how it would work.

>> With regard to authentication of the mapping server, I do not  
>> agree  that this is necessary for three reasons:
>> a) With authentication of the mapping server, I'm assume that  
>> this  refers to some sort of crypto, most likely TLS.  There are  
>> two  implications here: there is a performance penalty for every  
>> mapping  request and there is the overhead of getting client  
>> vendors and  server operators to agree upon trust anchors.
>>
>
> i am not sure about the performance impact of running tls. that  
> does not seem to be the most difficult part, at least not for  
> today's equipment.

First, I'd rather see the requirement specified in what function we  
want (i.e. we want integrity of the mapping answers) instead of a  
requirement specifying implementation (i.e. it must be channel  
security).  There may be other ways to do this.

I would also not take the implications of TLS so lightly.  Not only  
does it mean crypto hardware, but it also means you have to get TCP  
load balancers.  Also, estimates of load cannot be based on current  
911 call load.  It is likely to be much higher.  If we are talking  
about end devices that make a query every time they connect to a  
network, that is a load that is orders of magnitude higher than  
current 911 call load.

> i agree with regard to the trust anchors. that's indeed a difficult  

Actually, after thinking about this, there is a simple answer: let  
the Internet Attachment Provider specify the trust anchor... after  
all, its specifying all sorts of other information that is essential  
for this to work.

>> c) There is another alternative, which is to sign the data the  
>> server  gives back.
>>
>
> do you refer to the original source of the information or the  
> mapping server that directly talks to the mapping client? if you  
> talk about the former one then i need to remember you to appendix a  
> of <draft-hardie-ecrit-iris-03.txt>.

My point was that channel security is not the only option here.  I'm  
still doubtful with the overall need.  See below.

> an overall comment:
> do you think that there should not be any security between the  
> mapping client and the mapping server. if you think so then we  
> certainly have no way to prevent a number of attacks. this does not  
> seem to be attractive either. providing at least the possibity to  
> prevent these attacks is worth thinking about it.

So which attacks does adding channel security or object/transaction  
signing prevent?  It doesn't stop an attacker's ability to DoS the  
LCMS.  In fact, it makes it easier.  It doesn't stop an attacker from  
jamming the communication between a particular client and a server.   
What it does do is stop a spoofed answer.  If everyday life were an  
episode of "24" and Jack Bauer needed to be sure he was not giving  
his position away to assassins, then this is a problem we need to  
worry about.  Is such a thing really a high priority problem?

>> I think authentication of the client with user-based certs  
>> (assigned  to individuals) is unlikely to see deployment in our  
>> life times.   Using vender assigned certs is a much more  
>> reasonable idea, but it  suffers from the flea market problem.
>>
>
> geopriv meeting when we spoke about the ability to prevent denial  
> of service attack and the usage of end-to-end security using  
> special client side certificates was seen as a potential way to  
> address some of the problems (note that credentials that are  
> different to the credentials used for service access or network  
> access).

Certs assigned to end users is wishful thinking. Certs assigned to  
vendors can be deployed, but it is as useful as knowing the vendor of  
an ethernet card (i.e. not very useful).  Certs assigned to ISPs/IAPs  
is probably more doable depending on the will of the jurisdiction.

> including the ip address in the signed information blob might work  
> in some areas but it does not work if you are in a network that  
> uses a private address space.

I would assume the IP address or IP subnet would be the one the ISP  
uses to communicate over the Internet.  If they don't have one, then  
their problem is out of scope.

-andy