Re: SOI QUESTIONS: 2.1 Identity protection questions?

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
    >> Initiator and Responder refers to who sends the first keying message.
    >> 
    >> Client and Server refers to who is active and who is passive in their
    >> intent to communicate. The initiator is not always the client.
    >> 
    >> We are VERY frequently dealing with cases where the client, having no
    >> preconceived policy, may well start communication with the server in the
    >> clear, and the server, having a policy will, initiate to the client in
    >> order 
    >> to send its reply.

    Theodore> This is assuming your "opportunistic encryption" scenario, right?

  No, not necessarily.
  It certainly happens a lot more often for us. In fact, has a number of very
nice operational advantages for easing deployment.

  I can trivially think of hot-failover or load-balancing RW VPN scenarios
where this could happen.

  Take, for instance, a situation where the backup machine, having been made
aware of the policy that on the primary machine, gets a packet that needs
encryption (the other box just died and vrrp kicked in) and decides it has to
initiate. 
  The simpler situation is byte or packet based rekeying. 

  If you assume your model of RW=client, HQ=server, then I'll bet the data
flow is very assymmetric, and so the HQ/server end will want to rekey first.

  Any protocol that does not maintain a phase 1 will have to reveal
identities in the other direction to rekey.

    Theodore> This is why it would be useful to do a formal write up of the
    Theodore> security 
    Theodore> assumptions and requirements of your scenario.  

  Well, I'm at section 6 of the Madison draft, and I do intend to post
when I finish reading, but your questions are a very good proceedure for
us to do.
  
    Theodore> See the questions which I asked ari on this thread with respect
    Theodore> to assunmptions about whether or not the "client" has a fixed
    Theodore> IP address or even a DNS server name, and what sort of naming
    Theodore> assumptions which you are making.

    Theodore> These sorts of questions are relatively well understood for the
    Theodore> VPN and road-warrier to corporate gateway scearios.  But I
    Theodore> believe that they are not quite so well understood (or at least
    Theodore> with everyone having the same assumptions) for some of the
    Theodore> other usage scenarios. 

  I am trying to say that, even without OE, there really can be no assumption 
made about relationships like "client=initiator" and "server=responder". 
  This is particularly clear to me in the absense of a phase 1.

===

  Paul's comments about protecting the responder against even active attacks
are particularly well taken to me. 

  Again, I'll re-interate that I'd prefer to have an optional phase 1
exchange where secondary identities can be exchanged. 

  If the identities that are revealed (particularly by responders) on the
first pass are always IPV4 identities that can be checked by a lookup in the
reverse map, there is really no additional information gleamed to even
an active attacker. 
  This goes a long way towards making it easier for people to less more
ephermeral IDs on the outside.

  Vs, doing a phase 1 exchange and receiving a cert that says, e.g:
      "Foo Corp Financial Transaction processing Server Gateway"
  with a Verisign Financial Server signer. I know I just found a bank-like
entity based upon who signed it.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [






-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPRIL+IqHRg3pndX9AQEhBAP+Lik6DhzzwocIptFbhGVXadhtxrww6JFO
UrT+Ka7xlkDW6zrugkpJEZSkFFPab8zQql16hAq7sVj5n68NsU4XXFc7M5Xit1cA
kDGePwJeeoyZziwRXHN3KVZaS9MQVenEPpTNOxf81H4UcGoYOMBJYVlI/6kMyQOx
PIRQXZ7bfv4=
=2rR9
-----END PGP SIGNATURE-----