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

RE: Phase 1 Re-keying Implementation Identification

Tero,

> 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...

We've had this discussion before (offline). I think there are really only 3
realistic solutions:

1) Don't add unsigned payloads to phase 1. Send them later (e.g. using
Isakmp-Config).
2) Add them to phase 1 unauthenticated. Later, send a hash of the extra
payloads (e.g. using acknowledged notify).
3) Modify the phase 1 modes to retroactively sign earlier packets (like
crack does).

and, of course:

4) Don't do anything. This stuff's just for show, right? :-P


> 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.

Granted, vendor ids weren't necessarily intended to be used as feature ids,
but they seem to act in an appropriate manner. As Paul described it to me
(offline), we need to provide "feature advertisement capability", instead of
"negotiation capability".

Sort of like:

Initiator: "I do feature X".
Responder: "So do I. Let's do it".


> 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>

You're right that that's a secure way to do it. I wouldn't say that it's
less kludgy than any other method, though. You kind of break the proposal
model (flat list vs. pick & choose), which is important if we want to avoid
gigantic packets but still kind of confusing. Also, the feature sets can be
grouped, which isn't possible (easily) using vendor ids, although it isn't
necessarily desirable either.

I would rather see something like:

 	Protocol: PROTO_ISAKMP
 		Transform 1 ISAKMP_CONFIG

and then use config mode later to negotiate the features using a
REQUEST/REPLY exchange.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.