[perpass] Why a Key Exchange should be a separate module

[Phillip Hallam-Baker <[e-mail]>]

It occurs to me that in answering Kent's attack on me, I may have
inadvertently left the wrong impression of the reason why I have come to
the conclusion that key exchange should be a separate concern from the
binding to the communication layer.

Then as I began to wonder why the proposal might have set him off and
working from a hypothesis advanced in another place, I have come up with a
better scheme than previously.


The only connection to Omnibroker is that I realized the need to make this
separation as a result of writing Omnibroker. After writing the first
implementation, I took a look at my code and realized that over 70% of it
dealt with the problem of establishing and managing a long term trust
relationship between a group of related clients (i.e. sharing the same
account) and a service. And that this is a mechanism that can be used in
many, many other protocols.

Consequently, I factored the connection protocol out.

http://tools.ietf.org/search/draft-hallambaker-wsconnect-05


Now people can argue that the approach I take in wsconnect, namely relying
on the encapsulating TLS transport to protect exchange of the long term
secrets is a naive approach. Which of course it is. I want to replace that
approach with something better, preferably something that has been
thoroughly tested. But that currently requires me to reverse engineer some
other key exchange which is hardly an optimal approach. So the current
scheme is really a placeholder rather than a final proposal.

Kerberos has shown the way forward here. A symmetric security context may
be reduced to:

* The identity and permissions of the subject
* A set of cryptographic parameters (algorithms, etc)
* A set of symmetric keys
* An identifier that allows the counterparty to obtain the above

Since the only necessary feature of the identifier is that it uniquely
identify the security context to the counterparty, the identifier should be
opaque to the communication medium.

If the counterparty generates the identifier and the permitted identifier
length is sufficiently long, the identifier can contain the security
context provided that suitable encryption and authentication measures are
used.


Presenting the Key Exchange as a separate Web Service with defined inputs
and outputs means that instead of having to choose between OAKLEY, IKE,
PHOTURIS etc. as effectively exclusive schemes because there is only one
MTI, a mix and match approach becomes easier.

This presentation also makes it rather easier to conceal the identities of
the parties when combined with the WSConnect approach because this
integrates key exchange into the service discovery process. A WSConnect
service association is to a collection of hosts with information to enable
protocol and protocol version agility. Each host has a separate security
association.


So in WSConnect right now, if I have service A and B, the security
association would have a different key identifier and symmetric key for
each (with dummy data):

Service = [
  { "host" : "a", "secret" : "xxxxxx", "id" : "iixxxxx"},
  { "host" : "b", "secret" : "yyyyyy", "id" : "iiyyyyy"}]

This approach means that a passive observer can perform traffic analysis by
looking for repeated appearances of iixxxxx and iiyyyyy. This would allow
an attacker to match traffic from different IP addresses. It is not
possible for the attacker to correlate iixxxxx and iiyyyyy directly but
this may be inferred from other data.

Now imagine that we add a parameter for a DH public key for each host. We
can now blind the identifier values by encrypting them under an ephemeral
DH key from the client.


The separate key exchange service approach is very powerful because we can
use it iteratively. One key exchange service can be used to protect
interactions with another. This allows identity leakage to be concealed to
a far greater degree than is currently possible in IPSEC or TLS. Control
over identity leakage is given to the party deploying a service rather than
the designer of the protocol.

I think that is a good thing. Others might disagree.

-- 
Website: http://hallambaker.com/