[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple security mechanisms
Hi Iljitsch,
El 09/08/2006, a las 14:11, Iljitsch van Beijnum escribió:
[BTW: I'm reposting three messages from last week that I don't think
made it to the list.]
How about the following to move forward in the dicussion on HBA/CGA
patent issues and the need/want for other security mechanisms:
I still have to do a full review of the shim6 proto spec, but the way
I understand it, today, the security mechanism (HBA) is either an
integral part of the signalling, or it's encapsulated into the shim6
signalling protocol.
What if we make this the other way around? So we isolate the shim6
signalling from the security and then allow multiple security
mechanisms to encapsulate the signalling and send it over the wire
using appropriate mechanisms. For the current stuff this would look
like this:
[shim header][shim signalling][HBA/CGA]
or
[shim header][HBA/CGA][shim signalling]
The changes, if needed, should be minimal: just move the HBA/CGA stuff
and the shim6 signalling to opposite ends of the packet so they can be
easily separated.
i think it would be possible to achieve something similar to what you
are after with the current spec
The current spec defines the Locator List Option Format where the
alternative locators are carried.
Fro each of the locators contained in the list, there is a field
called Verification Method that states which is the verification
method for this locator. So, for each verification method, you would
need additional verification information that needs to be conveyed in
the message. In the case of HBA/CGA, there are two options defined,
namely, CGA Parameter Data Structure Option Format to carry the
parameter data structure and the CGA Signature Option Format for
carrying signature information (in the case of CGA)
If we want to support a different security method, what we need to do
is:-
Define a value of the Verification Method field, so that we can include
the new verification method in the message (that is easy)
Define new options to carry additional information required by the
security method if required.
For the case of IPSec for instance, this wouldn't be necesary, i guess.
If the packet passes the AH /ESP verification and the proper
certificate or manually configured pre shared is in placed, then the
locator is validated.
Similar approach could be used with TLS i guess.
From the protocol perspective, adding this mechanisms is trivial. I
guess that the compexity is likely to be in the interaction between the
processes in the host itself, but i would expect this to work
regards, marcelo
Then, if someone were to take it upon themselves to specify shim6 with
TLS security or shim6 with IPsec security, that would look like this:
[tcp][tls([shim signalling])]
[esp([udp][shim6 signalling])]
[ah][udp][shim6 signalling]
Additionally, the TLS/IKE people can define extensions to their
protocols to signal the capability to do shim6 and if both sides
support it and the necessary prerequisites are met (certificates at
both ends, for instance), they can trigger a shim signalling exchange
protected by TLS or IPsec so we wouldn't need to implement complex
capability negotiations in shim6, and if desired, the shim6 signalling
can be encrypted for additional security.