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

Re: PKI Signature format in ISAKMP -- proposal

> 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.

The fact that it is open to interpretation means it needs clarification.
But, regardless of people's interpretation, the intent of the draft
is to not do "PKCS#1 Signatures" for RSA-SIG authentication. The intent
was to do "PKCS#1 Encryption" of the result of the hmac.

> 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

This is fine for the bake-off but there is no requirement to pass certs
over the wire and signature verification should not be dependent upon it.

>   - 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>

Actually, it should be (from PKCS#1):

	00 | BT | PS | 00 | hmac

where BT in this case would be a 1 (because it's encrypting with the private 
key), PS is a string of 0xff which is modulus-length minus 3 minus hmac 
length in 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.

But is is PKCS#1, it's just "PKCS#1 encryption". To do an RSA signatures
you do a PKCS#1-defined RSA private key encryption of the output from the
hmac function instead of a PKCS#1-defined "RSA signature" (which includes
encoding a magic number that is outside the control of the IETF).

> 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.

The fact that it contains the length is extremely important. Given a
key modulus length payload how do you know the true length of the hash
is without the above-mentioned encoding? The fact that it contains an
algorithm identifier is problematic. 

The intent of the draft was to do authentication with RSA signatures by 
encrypting the hmac with a private key and verifying it with the 
corresponding public key. I've failed quite spectacularly in conveying this. 
I'm open to suggested text on how to properly convey the intent. 

  regards,

    Dan.

-------------------------------------------------------------------------------
Dan Harkins                                |   E-mail:  dharkins@cisco.com
Network Protocol Security, cisco Systems   |   phone:   +1 (408) 526-5905
170 W. Tasman Drive                        |   fax:     +1 (408) 526-4952
San Jose, CA 95134-1706, U.S.A.            |   ICBM:    37.45N, 122.03W
-------------------------------------------------------------------------------
For your safety and the safety of others: concealed carry, and strong crypto
-------------------------------------------------------------------------------
References: