server authentication? [Re: [v6tc] I-D ACTION:draft-palet-v6ops-tun-auto-disc-03.txt (fwd)]

On Mon, 28 Feb 2005, Jeroen Massar wrote:
> On Mon, 2005-02-28 at 16:21 +0100, Kurt Erik Lindqvist wrote:
>> My concern is that you still have no idea if you are talking to the TSP
>> server you think you are talking to.
>
> There is quite a funny problem here ;)
>
> The TEP server gets automatically discovered, thus everybody who deploys
> one would need to have the same cert, otherwise the client can't verify
> it being the 'correct' TEP. But with everybody having the cert,
> everybody can setup a bogus one...
>
> Maybe we should have shim6 finished before this ? Then one could use the
> identifier as the verification mechanism...

This issue is somewhat offtopic from _discovery_, but was mentioned 
briefly earlier under "mutual authentication", without much 
discussion.

One can indeed raise a question how strongly the server should 
authenticate the client, and how strongly the client should 
authenticate the server.

If the discovery mechanism has potential for giving ambiguous 
responses, it can be argued that the need for the client to 
authenticate the server is greater (but probably only slightly).

There can be a number of authentication methods in the _configuration 
protocol_ (and not necessarily the endpoint discovery), but a major 
question is how many roundtrips the clients want to waste in the 
authentication.  At least in some scenarios, doing this may not be all 
that interesting.

As an example of configuration protocol client<->server 
authentication, draft-parent-v6tc-protocol-exploration-01.txt gives an 
overview how to use SEND or DHCPv6 + authentication.  Both can 
guarantee that you are talking to the server you think you're talking 
to.

So, this does not necessarily need to be addressed in the end-point 
discovery part of the solution, though the properties of the discovery 
may affect the requirements level of the authentication.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc