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

Re: Phase 1 Re-keying Implementation Identification

tytso@mit.edu writes:
> What a number of folks have complained about is that the IKE framework
> doesn't have a particularly good way of turning on optional features,
> since as we add new orthoganol features, it causes a combinatoric
> explosion in number of IKE proposals that need to offered.  Some people
> have pointed out that the Vendor ID can be (ab)used to allow for a more
> streamlined way of negotiating optional parts of the specification,
> especially as we move forward and want to add new (optional) extensions
> to IKE.

Note, that the vendor ID payloads are not authenticated, so even if
somebody adds keepalive vendor IDs to their packets that doesn't mean
that those vendor IDs reach the other end...

> Granted it it violates the original intention of the Vendor ID payload.
> Granted it is an ugly kludge.  But the folks who are advocating it are
> saying that it might be cleaner and more pragmatic than some of the
> alternatives.  I think it's fair to consider this point, and not reject
> it out of hand --- although I do have a lot of sympathy for the purist
> point of view that this is an ugly hack.

I think we should start thinking better way to do the same thing.
There isn't any currently defined vendor-id payloads used now, so
everybody who wants to support something new, must modify their code
anyways.

So we might define new way to agree on used features, which doesn't
break old implementations, but which is authenticated, and which
doesn't violate the ISAKMP RFC.

One such way could be to define another Protocol ID to be used in the
feature negotiation. So the IKE SA proposal could be something like
this:

Proposal 1:
	Protocol: PROTO_ISAKMP
		Transform 1 KEY_IKE
			Encryption: Blowfish
			HASH: SHA
			Authentication method: RSA signatures
			Group: 5
Proposal 2:
	Protocol: PROTO_ISAKMP
		Transform 1 KEY_IKE
			Encryption: Blowfish
			HASH: SHA
			Authentication method: RSA signatures
			Group: 5
	Protocol: PROTO_ISAKMP_FEATURE_NEGOTIATION
		Transform 1 FEATURE_NEGOTIATION
			Keepalives: enabled
			Nethack over IKE: disabled
		Transform 2 FEATURE_NEGOTIATION
			Keepalives: disabled
			Nethack over IKE: enabled
		Transform 3 FEATURE_NEGOTIATION
			<empty>

Which would allow old implementations to select the proposal 1 having
only one protocol (for this to work they must be able to process
ike SAs having multiple proposals, which is currently forbidden in the
IKE rfc)

New implemenations could select IKE parameters from the PROTO_ISAKMP
transform list, and then they can select one feature list transform
from the PROTO_ISAKMP_FEATURE_NEGOTIATION list.

The good thing about the SA payloads are that they are authenticated,
so attacker cannot remove the features, as they can when you are using
the vendor id payloads.

This is just one example how this can be done, am not (yet) really
proposing this. This just for you to start thinking about this issue
also... 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: