[Swan-commit] Changes to ref refs/heads/master

[Paul Wouters]

New commits:
commit 68c25611eed93edd459e38deadf01916ab983115
Author: Paul Wouters <pwouters at redhat.com>
Date:   Fri May 30 01:58:15 2014 -0400

    pluto: Ensure we send/require KEY_LENGTH attributes for some ciphers
    
    This continues the work in commit b12823df59768b
    
    - Remove unused 3rd argument of kernel_alg_esp_enc_ok()
    - Remove obsoleted kernel_alg_policy_algorithms()
      (obsoleted by crypto_req_keysize() and some other checks)
    - Removed some #ifdef'ed out ESP attributes we don't support
      (and one listed as unsupported but handled earlier)
    - Use kernel_alg_esp_enc_ok() to check if we support the received ESP transform
      (this should be extended with the functionality of crypto_req_keysize()
       regarding valid key sizes)
    
    The function kernel_alg_policy_algorithms() used to add ESP KEY_LENGTH
    attributes for algo ESP_AES and newer if the user did not specify these
    (eg user specified "aes" and not "aes128"). It used the maximum key length
    instead of the default only mandatory to implement key length (usually
    128). The new crypto_req_keysize() uses the mandatory to implement
    key length. This means a difference in interpretation of esp=aes-sha1
    (formarly we would send AES256, now we send AES128). Ideally this is
    changed to send all valid AES key sizes instead (128, 192 and 256)
    although in Aggressive Mode we can only send one proposal. If the
    receive has esp=aes-sha1, it will accept any of the three key sizes,
    so the only configuration that would break is initiator with esp=aes-sha1
    and responder with esp=aes128-sha1.
    
    There was no similar function for IKE, so we could send OKALEY_ENCRYPTION
    proposals with missing OAKLEY_KEY_LENGTH attributes (violating RFC 3602).
    Commit b12823df59768b already introduced the code to add the default only
    mandatory to implement key sizes to insert this attribute when missing.
    Interop with older functions should be verified using a new impair function.