[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isakmp/doi questions: fine-grained keying..


In message <199706192310.AA015331828@relay.hp.com>, Bill Sommerfeld writes:
>It does not specify whether the port number is the port on the
>initiator's host or the responder's host; this could be specified more

If you check Quick Mode, you'll see that there are two IDs sent, 
IDii and IDir; these are (presumably) the identities of the
user-initiator and the user-responder, as known by the Initiator.
I would expect the Responder to verify those, then reverse the order
and send them back to the Initiator in the next message (i don't have
the draft around tho, so take this last with a grain of salt).

>I think you need to include both source and destination ports
>*somewhere* in the protocol, but I'm not entirely sure this works best
>in the phase I exchange, either.  I'll see if I can come up with a
>more concrete alternative proposal in the next few days.

I don't think you need to do this in the Phase I exchange; i would
expect that the IDs exchanged there are just IPv4 addresses, no ports.
Remember, Phase I identifies just the ISAKMP daemons, no users.

However, your question raises an interesting problem: what if i want
to encrypt the traffic of a particular TCP session but want to use my
certificate as user foo; as it stands right now, the protocol allows
for either but not both. I suspect that the way to authenticate TCP
sessions (but not all traffic from user A@host1 to user B@host2)
involves using secrets that depend on the IP address included in the
ID, i.e. no finer grain auth. is possible.
- -Angelos

Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface