[Openswan Users]
2.3.0 AES is not default + invalid encryption type 65535??
Scott Mcdermott
smcdermott at questra.com
Tue Mar 8 06:24:54 CET 2005
I am in the process of switching my kernel 2.6-based from
using the BSD KAME racoon system for IPSEC, to openswan
using NETKEY, with version 2.3.0.
For the start I am converting one end only (of a
both-end-racoon tunnel). The problem is that I cannot seem
to specify the correct encryption/hash parameters. Openswan
seems to recognize the parameters, but it seems to be
sending bogus values of 65535 for encryption and hash, which
are not recognized by Racoon.
Additionally, the documentation specifies that AES/SHA1 are
now the preferred alghorithms, but this is not the case with
my openswan version 2.3.0. If I do not specify
"ike=aes-something" and "esp=aes-something" in my "conn"
section, the proposal is for 3DES/MD5. Is this an error in
the documentation?
Here is the Racoon end I am trying to negotate with:
remote anonymous
{
exchange_mode main;
send_cert off;
proposal_check obey;
proposal {
encryption_algorithm aes256;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}
sainfo anonymous
{
lifetime time 24 hours;
encryption_algorithm aes256;
authentication_algorithm hmac_sha1;
pfs_group modp1024;
}
and here is the openswan end:
config setup
forwardcontrol = no
rp_filter = %unchanged
klipsdebug = all
plutodebug = all
hidetos = no
conn %default
auto = start
authby = secret
conn questra-rwc
left = <my openswan gateway>
right = <racoon gateway>
leftsubnet = <local net>
rightsubnet = <remote net>
ike = aes256-sha1-modp1024
esp = aes256-sha1-modp1024
# disable opportunistic encryption
conn packetdefault
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn block
auto=ignore
I cannot for the life of me get the "ike" and "esp"
parameters to work properly though. I have tried the
following variations:
ike = aes-256-sha2-256-modp1024
esp = aes-256-sha2-256-modp1024
ike = aes-256-sha1-256-modp1024
esp = aes-256-sha1-256-modp1024
ike = aes256-sha1-modp1024
esp = aes256-sha1-modp1024
ike = aes256-sha1-modp1024
esp = aes256-sha1
ike = aes256-sha-modp1024
esp = aes256-sha1-modp1024
ike = aes256-sha1
esp = aes256-sha1
ike = aes256-sha
esp = aes256-sha
ike = aes-sha
esp = aes-sha
ike = aes-sha
esp = aes-sha
the results range from parse errors (it doesn't seem to
allow me to specify -modp1024 suffix), to a peculiar result
where the Racoon end tells me this (when using
"aes256-sha1"):
racoon: ERROR: invalied encryption algorithm=65535.
in the openswan logs, there are strange messages from Pluto
(I used "aes256-sha1!" -- note the exclamation -- so it
would be the only responder proposal in the logs for this
paste below):
| ****emit ISAKMP Proposal Payload:
| next payload type: ISAKMP_NEXT_NONE
| proposal number: 0
| protocol ID: PROTO_ISAKMP
| SPI size: 0
| number of transforms: 3
| *****emit ISAKMP Transform Payload (ISAKMP):
| next payload type: ISAKMP_NEXT_T
| transform number: 0
| transform ID: KEY_IKE
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_TYPE
| length/value: 1
| [1 is OAKLEY_LIFE_SECONDS]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_DURATION
| length/value: 3600
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_ENCRYPTION_ALGORITHM
| length/value: 65535
| [65535 is 65535??]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_HASH_ALGORITHM
| length/value: 65535
| [65535 is 65535??]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_AUTHENTICATION_METHOD
| length/value: 65535
| [65535 is 65535??]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_GROUP_DESCRIPTION
| length/value: 65535
| [65535 is 65535??]
| emitting length of ISAKMP Transform Payload (ISAKMP): 32
| *****emit ISAKMP Transform Payload (ISAKMP):
| next payload type: ISAKMP_NEXT_T
| transform number: 1
| transform ID: KEY_IKE
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_TYPE
| length/value: 1
| [1 is OAKLEY_LIFE_SECONDS]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_DURATION
| length/value: 3600
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_ENCRYPTION_ALGORITHM
| length/value: 7
| [7 is OAKLEY_AES_CBC]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_HASH_ALGORITHM
| length/value: 2
| [2 is OAKLEY_SHA1]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_AUTHENTICATION_METHOD
| length/value: 1
| [1 is OAKLEY_PRESHARED_KEY]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_GROUP_DESCRIPTION
| length/value: 5
| [5 is OAKLEY_GROUP_MODP1536]
| emitting length of ISAKMP Transform Payload (ISAKMP): 32
| *****emit ISAKMP Transform Payload (ISAKMP):
| next payload type: ISAKMP_NEXT_NONE
| transform number: 2
| transform ID: KEY_IKE
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_TYPE
| length/value: 1
| [1 is OAKLEY_LIFE_SECONDS]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_LIFE_DURATION
| length/value: 3600
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_ENCRYPTION_ALGORITHM
| length/value: 7
| [7 is OAKLEY_AES_CBC]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_HASH_ALGORITHM
| length/value: 2
| [2 is OAKLEY_SHA1]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_AUTHENTICATION_METHOD
| length/value: 1
| [1 is OAKLEY_PRESHARED_KEY]
| ******emit ISAKMP Oakley attribute:
| af+type: OAKLEY_GROUP_DESCRIPTION
| length/value: 2
| [2 is OAKLEY_GROUP_MODP1024]
| emitting length of ISAKMP Transform Payload (ISAKMP): 32
| emitting length of ISAKMP Proposal Payload: 104
Note how it sends the values twice, even though I have
included the `!' character. Even more confusing, the first
group it sends is all with values "65535", decoded to
"65535??" This seems to indicate it doesn't understand the
values or they are nonsensical.
So why is it sending them, and where is it getting them
from?
btw one other data point: my kernel has everything compiled
statically and modules disabled. I don't know if this would
make any difference (I've quite certain everything needed is
compiled into the kernel, and it works fine with Racoon),
but offer this in case it's even remotely related...
So my questions:
1. why are the default algorithms in 2.3.0 documented as
AES/SHA1, but actually end up as 3DES/MD5?
2. what is the origin of the bogus 65535 values, and how do
I get rid of them so they aren't part of the proposal?
3. how does one specify a DH group in the esp= and ike= line
without getting parsing errors? Documentation only has
3des and md5 documented
4. what is the exact format I should use for esp= and ike=
to get modp1024 (DH group 2 I think), AES256, SHA1 for
both IKE and IPSEC SAs?
Any information is greatly appreciated. Thanks.
More information about the Users
mailing list