[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 1 Re-keying Implementation Identification
On 23 Nov 99, at 2:24, Tero Kivinen wrote:
Hi Tero,
[...]
> 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.
But attacker can always change responder's selection, because SAr is
not explicitly authenticated in IKE.
> 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/
>
Best regards,
Valera.
Follow-Ups:
References: