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

PKI Signature format in ISAKMP -- proposal

-----BEGIN PGP SIGNED MESSAGE-----

In preparing for the ANX bakeoff there has been some discussion
of exactly what a "signature" should look like for ISAKMP.  Some
people have interpreted this to mean the signature output was in
PKCS#1 format.  Others have not.

In this message I have described what I interpreted this to
mean.  Note this DOES NOT use PKCS#1.  At the end I have listed my
reasons for not using PKCS#1 and what I think would have to
change to use it.

The Oakley resolution draft, in section 5.1, describes the use
of "signatures" for authentication.  The signature consists of
data formed by applying the signature algorithm to a hash and
transmitting the signature.  In the case of RSA signatures, this
means you create a hash and encrypt the hash with the RSA
private key.  At the receiving end, the process is reversed --
the encrypted data is decrypted using the RSA public key, then
the result is compared to the locally calculated hash.  [someone
else can augment this with proper prose for DSA...]

In ISAKMP, this hash which is used in the signature process has
specific meaning related to ISAKMP.  The draft specifies it to
be the HMAC form, and the hash algorithms that may be used are
specified explicitly.

The procedure used to produce the signature is described here for the
RSA signature algorithm case.  Note the terms are from
draft-ietf-ipsec-isakmp-oakley-03.txt.

  - ISAKMP produces HASH_I/HASH_R however it wishes

  - the hash is used as input data for encryption with the RSA private
key, with
  padding as required by the RSA algorithm (see PKCS#1 or the BSAFE
  documentation)

  - the (key bits) of encryption output is passed over the wire as the
signature

  - the other side calculates the hash value HASH_I/HASH_R independantly

  - the other side decrypts the signature data using the public key
retrieved
  from the cert we are sending over the wire

  - the other side compares the decrypted signature against it's locally
  calculated hash and if they match you're all set.

Note that the 'signature' data passed over the wire is the
<key bits> of data as generated by the RSA algorithm.  The
normal ISAKMP payload processing allows the receiving side to
determine how much data is present.  The 'signature', that is,
the encoded hash, must be padded as required by the RSA
algorithm, so when the data is encrypted it consists of:

  one byte of zero
  hash bytes
  padding of zero bytes up to <key length>

DIFFERENCE FROM PKCS#1.

In PKCS#1 an ASN.1 structure encoded in BER would be transmitted
over the wire.  I don't think this can be used because:

a. PKCS#1 can't be referenced in IETF documents
b. PKCS#1 does not define hmac-md5 or hmac-sha1 or Tiger

Note also this would add an implementation burden in that the
ISAKMP code would be responsible for generating BER encoded
information.

In my opinion, we should use the 'raw' signature for now. 

If we could obtain an IETF-compliant defininition of an enhanced
PKCS#1 format I would be willing to convert.  The fact the
PKCS#1 format contains the length and the algorithm is
appealing.

-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
Comment: PGP by ViaCrypt

iQCVAgUBMyhSfsKmlvJNktGxAQHJagP/WgKnRWF4IVX92kPlJU9juPacB0fwYNEO
slRCKLQcUatueyuSTvar+I23X6tOO/aNGndGsZfwrAss0cPI271TkCwVd4cOkRnY
EKRxZEVWS9ieAj9Oh7IwqDAeM2Lun9sDzuUUOJxGXZjuj+rVUaXqa9Gt9GljI2cW
SPxfHdkakKI=
=22vj
-----END PGP SIGNATURE-----


               Rodney Thayer <rodney@sabletech.com>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           "Developers of communications software"
Follow-Ups: