Bug 435243 - Cannot create an SA with AH
Cannot create an SA with AH
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
ia32e All
high Severity medium
: rc
: ---
Assigned To: Thomas Graf
Martin Jenner
Depends On:
Blocks: 253764
  Show dependency treegraph
Reported: 2008-02-28 01:24 EST by IBM Bug Proxy
Modified: 2014-06-18 04:29 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:10:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Convert AH to new crypto interface (11.16 KB, patch)
2008-03-06 03:55 EST, Herbert Xu
no flags Details | Diff
patch to enable probe in AH/use ctr(aes)/ESP encryption only. (1.74 KB, text/plain)
2008-03-07 17:25 EST, IBM Bug Proxy
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 42749 None None None Never

  None (edit)
Description IBM Bug Proxy 2008-02-28 01:24:25 EST
=Comment: #0=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-02-27 20:30 EDT
---Problem Description---
When specifying a SA with only encryption or only authentication, the kernel
refuses the SA's creation.  SA's with encryption and authentication are allowed.
Contact Information = Primary: "Tyler Hicks" <tyhicks@linux.vnet.ibm.com>
Secondary: "Joy Latten" <latten@us.ibm.com>
---uname output---
Linux eal1.ltc.austin.ibm.com 2.6.18-83.el5 #1 SMP Thu Feb 21 12:14:23 EST 2008
i686 i686 i386 GNU/Linux
Machine Type = Xseries Model 335
---Steps to Reproduce---
Three setkey config files are used:

------------- setkey.auth -------------
add ah 0x1000
        -m transport
        -A hmac-md5 "TAHITEST89ABCDEF";

------------- setkey.enc -------------
add esp 0x1000
        -m transport
        -E des-cbc "TAHITEST";

-------- setkey.enc_with_auth ---------
add esp 0x1000
        -m transport
        -E des-cbc "TAHITEST"
        -A hmac-md5 "TAHITEST89ABCDEF";

[root@eal1 ~]# setkey -f setkey.enc_with_auth 
        esp mode=transport spi=4096(0x00001000) reqid=0(0x00000000)
        E: des-cbc  54414849 54455354
        A: hmac-md5  54414849 54455354 38394142 43444546
        seq=0x00000000 replay=0 flags=0x00000000 state=mature 
        created: Feb 27 19:25:23 2008   current: Feb 27 19:25:23 2008
        diff: 0(s)      hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=3582 refcnt=0
[root@eal1 ~]# setkey -f setkey.enc
The result of line 4: (null).
The result of line 5: No SAD entries.
[root@eal1 ~]# setkey -f setkey.auth
The result of line 4: Invalid argument.
The result of line 5: No SAD entries.
Comment 2 IBM Bug Proxy 2008-02-28 14:32:31 EST
------- Comment From tchicks@us.ibm.com 2008-02-28 14:28 EDT-------
The upstream kernel doesn't seem to have this bug.  I just did a git clone on
Linus' tree and compiled using the 2.6.18-83.el5 config file.  Using the same
machine with the same setkey config files, didn't produce the bug.  There may
already be a patch floating around somewhere for this bug.
Comment 3 Thomas Graf 2008-03-04 08:50:41 EST
Based on Herbert's statement, auth only is not allowed on purpose, are you sure
this works upstream? It would be easy to allow this though.
Comment 4 IBM Bug Proxy 2008-03-04 12:32:38 EST
------- Comment From tchicks@us.ibm.com 2008-03-04 12:30 EDT-------
I just tested again with the upstream git version of 2.6.25-rc3 and
2.6.18-53.1.6.el5 in RHEL 5.1.  AH and ESP with no authentication work fine with
these two kernels and the two machines can communicate with each other.

Thomas, can you please elaborate on why AH is purposely not being accepted in
the RHEL 5.2 kernel?  The support is there, so why disable it?  Also, do you
feel it is a bug that ESP with no authentication doesn't work?

Comment 5 IBM Bug Proxy 2008-03-04 14:24:35 EST
------- Comment From latten@us.ibm.com 2008-03-04 14:16 EDT-------
This may also be viewed as a regression by customers.
Comment 6 Herbert Xu 2008-03-04 19:27:08 EST
I think we're talking past each other.  Thomas is saying that auth-only (i.e.,
with no encryption) doesn't work.  While you guys are saying that enc-only (no
auth) works just fine.

So we both agree :)

At this point we all agree that auth-only doesn't work either in RHEL5.2 or
upstream, but that's easy to fix.

What I'm confused about is enc-only, are you saying that it used to work in
RHEL5.1 but has stopped working in RHEL5.2?

Comment 7 IBM Bug Proxy 2008-03-05 10:40:29 EST
------- Comment From latten@us.ibm.com 2008-03-05 10:33 EDT-------
Hi Herbert and Thomas,
Yes, we noticed that
1. when only AH protocol is used, we get test failures.
2. when we use ESP protocol with encryption only, we get test failures.

These things do not fail in RHEL 5.1 and in upstream kernel, just
our latest RHEL5.2 kernel.

Thomas, sorry, we thought you were saying it was new behaviour and was
supposed to fail. :-) Sigh. I think I need more coffee. :-)
Comment 8 Thomas Graf 2008-03-05 11:15:50 EST
The bugzilla subject was misleading me I talked to Herbert initially. 
Comment 9 IBM Bug Proxy 2008-03-05 23:08:34 EST
------- Comment From latten@us.ibm.com 2008-03-05 23:06 EDT-------
I did a little debugging and it seems when specifying AH protocol
the failure is occurring in crypto_alloc_tfm().... in this case
the name was "hmac(sha1)".
Comment 10 IBM Bug Proxy 2008-03-05 23:48:27 EST
------- Comment From latten@us.ibm.com 2008-03-05 23:45 EDT-------
It seems crypto_alloc_tfm() doesn't like "hmac(sha1)", it seems to want the old
syntax when it was just "sha1". Not sure how to fix this... should
crypto_alloc_tfm() be calling ncrypto_alg_mod_lookup()?
Comment 11 Herbert Xu 2008-03-05 23:59:02 EST
My fault, I forgot to update AH to use the new crypto interface.  I'll take care
of this.
Comment 12 Herbert Xu 2008-03-06 03:55:48 EST
Created attachment 297011 [details]
Convert AH to new crypto interface

Could you please let me know if this patch makes AH work again?
Comment 13 IBM Bug Proxy 2008-03-07 17:25:11 EST
Created attachment 297259 [details]
patch to enable probe in AH/use ctr(aes)/ESP encryption only.

Sorry, for the delay, I tested with the patch and found just a few things were
needed on top of this patch. Let me know if this looks ok.

Please see attachment.

1. AH protocol when calling xfrm_naalg_get_byname() appeared to need to enable
probe. Otherwise, the .avaliable field didn't get filled in.

2. In ESP protocol, specifying "hmac(digest_null)" instead of "digest_null"
allowed specifying ESP with encryption only to work.

I noticed in upstream code, where things worked, xfrm_probe_algs() queries
cryptoapi resulting in crypto_alg_mod_lookup on all the IPsec algorithms
specified in xfrm_algo.c 

I am still learning cryptoapi, but this appears to mean a larval or
instance is created for each of the IPSec algorithms.

Thus, in upstream, when esp calls authenc(digest_null, cbc(aes)) it works.

But in 5.2 and prior kernels, it seems we don't do this kind of probe into the
cryptoapi in xfrm_probe_alg. So when esp calls authenc(digest_null,cbc(aes)),
cryptomgr_schedule_probe()'s parsing results in a NOTIFY_OK message.
Is parsing set to fail/return NOTIFY_OK on something like "digest_null"
because it is a basic algorithm, no mode or hmac or anything which require
instances? Anyway, this leads to crypto_attr_alg() in crypto_authenc_alloc() to
fail. Putting "hmac(digest_null)" allows us to create a larval/instance and
crypto_attr_alg() is successful.

3. We needed ctr(aes) in xfrm_nalgo.c to successfully use it.
Comment 14 Herbert Xu 2008-03-07 19:45:24 EST
(In reply to comment #13)
> 1. AH protocol when calling xfrm_naalg_get_byname() appeared to need to enable
> probe. Otherwise, the .avaliable field didn't get filled in.

Good catch.  I missed that spot.
> 2. In ESP protocol, specifying "hmac(digest_null)" instead of "digest_null"
> allowed specifying ESP with encryption only to work.

Sorry you guys didn't see this but I had cloned this bug for the ESP issue and
there is a patch there for this.  The new bug is #436267.  The patch can also be
retrieved from the upstream kernel:

commit ce5bd4aca3c467936370846119b7f3daf9ccea78
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Dec 14 00:28:40 2007 +0800

    [CRYPTO] null: Allow setkey on digest_null

    We need to allow setkey on digest_null if it is to be used directly by
    authenc instead of through hmac.

    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Comment 16 Don Zickus 2008-03-19 12:24:35 EDT
in kernel-2.6.18-86.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 18 IBM Bug Proxy 2008-03-26 18:40:56 EDT
------- Comment From latten@us.ibm.com 2008-03-26 18:36 EDT-------
Red Hat this bug for AH is verified. Closing on the IBM side.
Comment 20 errata-xmlrpc 2008-05-21 11:10:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.