Re: [alto] Security

[Richard Alimi <[e-mail]>]

Hi Hannes,

Thank you for the feedback. Replies inline...

On Wed, Mar 6, 2013 at 8:49 AM, Hannes Tschofenig <[e-mail]
> wrote:

> Hi all,
>
> I just read through the security consideration section of
> http://tools.ietf.org/html/draft-ietf-alto-protocol-14 and it raised some
> questions for me.
>
> As someone who has not followed the work closely I unfortunately have to
> say that I do not understand why you came up with the current security
> solution.
>
> It is not clear to me what the threats are.
>
> Just as an example: Why would someone want to sent a client fake ALTO
> information or impersonate a server? What would be their benefit? If they
> do that wouldn't it be easier to then attack the discovery mechanism?


Section 13.2 currently states:

   Applications using the information must be cognizant of the
   possibility that the information is malformed or incorrect.  Even if
   an ALTO Server has been properly authenticated by the ALTO Client,
   the information provided may be malicious because the ALTO Server and
   its credentials have been compromised (e.g., through malware).  Other
   considerations (e.g., relating to application performance) can be
   found in Section 6 of [RFC5693]
<http://tools.ietf.org/html/rfc5693#section-6>.


This references the ALTO Problem Statement draft which describes some
reasons an attacker may want to do this.  We can make it clear that
this forward reference contains some example attacks.


The draft also has this text in the Manageability Considerations section:



   Operators providing an ALTO Server should ensure that appropriate
   information is being exposed.  Privacy implications for ISPs are
   discussed in Section 13.1
<http://tools.ietf.org/html/draft-ietf-alto-protocol-14#section-13.1>.
 Both operators and ALTO Servers and those
   using ALTO Clients should be aware of the impact of incorrect or
   faked guidance (see Section 10.3 of [I-D.ietf-alto-deployments
<http://tools.ietf.org/html/draft-ietf-alto-protocol-14#ref-I-D.ietf-alto-deployments>]
and
   future versions of that document).


As far as attacking the discovery mechanism, yes an attacker may wish to do
that.  I believe that something that should be addressed in the
server-discovery document (and its security considerations) but not in the
protocol document.

Does this answer your questions?

Looking at those two pointers again, we should probably clean this up such
that Section 13.2 also points to draft-ietf-alto-deployments, and the
Manageability Considerations section points to the 13.2.

What is the relationship between the client and the server? Is it always
> dynamically discovered or are there cases where the client has an ALTO
> server address pre-configured?
>

These are a few relationships that have been discussed in the past:
(1) ALTO Client a part of an application used by a subscriber of an ISP,
and the ISP may host an ALTO server
(2) Business relationship between peering ISPs (one has the ALTO server and
another has the ALTO client)
(3) CDN provider using an ALTO client to subscribe to information about an
ISPs network (the ISP managing the ALTO server)

I can see cases where an ALTO client may manually configure the address of
an ALTO server, particularly for (2) or (3).


> Do you need confidentiality protection of the exchange between the client
> and the server? Would you consider the information that the server provides
> as public information?
>

I think it depends on the deployment scenario.  I could imagine that the
exchange between two peering ISPs would be confidential, while a
public-service ALTO server that pieces together information from public
datasources like BGP looking glasses may not need to be (though a client
may desire it to be, depending on what it's using it for).  There is
already a thread about exactly how to word this requirement, so let's leave
discussion of this to that thread.


>
> There is text about denial of service attacks but that is not really core
> to the topic since the usage of TLS will likely make the DoS vulnerable
> worse. The reference to SIP puzzles is misleading (since you are not using
> SIP nor cryptographic puzzles in TLS).
>

Can you clarify here?  Are you suggesting to drop the text about Denial of
Service, or to extend it to note that use of TLS may make it worse?

I think we can remove the reference to draft-jennings-sip-hashcash.


>
> I don't understand from the reading whether client authentication
> functionality has to be provided or not. It is too fuzzy; you cannot
> develop an interoperable based on the current description. There are many
> ways to do client authentication and there is always the question about key
> management.
>

In your view, how much of this belongs in the ALTO protocol draft versus
the ALTO Deployment Considerations draft (draft-ietf-alto-deployments)?

When revising the statement about TLS support we can also revise exactly
which features are required to support the base protocol.  My personal view
is that server-authentication, message integrity, and confidentiality would
be required but that client-authentication can be optional.

Question (to anyone): looking at the RFCs cited by Michael (
http://www.ietf.org/mail-archive/web/alto/current/msg01759.html), I don't
see any of them expanding on the particular TLS mechanisms used (e.g., key
management, how client certs are provided, etc).  Are there any examples we
can work off of to understand how other WG's have tackled this?

Thanks,
Rich


>
> Ciao
> Hannes
>
> PS: Please stop using the term SSL since it shows that you have no idea
> about security. SSL was the precursor to TLS; the work on TLS (of the
> different versions) had fixed security vulnerabilities of SSL. Have a look
> at the Wikipedia to get a brief summary of the history:
> http://en.wikipedia.org/wiki/Transport_Layer_Security


Thanks. We'll update the text.


>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>