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

From: [email-masked]
Date: Thu, 27 Oct 2005 12:36:25 +0100

hi andy,

thanks for the draft review. please find some comments inline:

-- Ursprüngl. Mitteil. --
Betreff:	[Ecrit] thoughts on draft-taylor-ecrit-security-threats-00
Von:	Andrew Newton <[email-masked]>
Datum:		26.10.2005 21:15

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. 

# that's true. the most difficult part is related to the key management. do we demand authentication of the mapping server to the mapping client? 

 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.

the aspect of object signing is certainly difficult and we haven't reached conclusion with regard this issue. in past discussions we said that the mapping client will not verify the source of the provided mapping information as part of the digital signature. sometimes we argued that the psap might be interested in this information to determine the authenticity of the provided information.

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?

# would this info need to go into a threats / requirements document?we can certainly discuss it but i guess the main answer is: "if you fail to perform the security checks, for example because a certificate status check fails" you still continue."

i will respond to your other comments later. 

ciao

hannes

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

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