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

Re: certificate key usage in IKE

Dan,

Point of reference.
One large company (Microsoft) in its CryptoAPI distinguishes the SignatureKey
from the KeyExchangeKey. The SignatureKey can be used for signatures only, but
the KeyExchangeKey can be used for both - signatures and key exchanges
(encryption). This makes KeyExchangeKey less restrictive and therefore very
popular in the Microsoft's certificate model.

Daniel Harkins wrote:

>   Another issue has come up with RSA encryption mode (both of them) and
> regrettably the IKE document does not address it.
>
>   It's concerned with the key usage restrictions that can be added to
> a certificate. For split-key systems where there is a "signature" key and
> a "key encipherment" key can the signature key be used for the encrypted
> nonce-type authentication methods?
>
>   On the one hand, the argument goes that since it is basically for
> authentication then it's OK to use a signature-only public key to encrypt
> a nonce and send to the peer. On the other hand, the argument goes that while
> the nonce is not used directly for a key (as in some email systems where the
> key encipherment usage is more straightforward) it is used to generate the
> key. In fact, the two decrypted nonces are used as the key to the prf that
> generates the shared secret data from which the encryption and authentication
> keys are generated. For the extended public key encryption method this might
> even be more strong since the decrypted nonce is used to generate not only
> the shared secret data but a symmetric key to decrypt the remaining payloads
> in the message. So I'm sitting here like Reptavia from Fiddler on the Roof:
> "but on the other hand...but on the other hand...but on the other hand...."
>
>   This has to be addressed somewhere, most likely in the IKE document but it
> would be nice if this went into the certificate profile that Rodney Thayer is
> developing. (Hint, hint :-).
>
>   What is the feeling of the WG? I have my own opinion but it is clouded by
> reluctance to rearchitect my code (as is that of the other vendor with whom
> interoperability testing today illustrated this issue) so I'd rather not
> state it here.
>
>   Dan.



--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive  Suite 513
Danvers, MA  01923
voice: 978-739-2384
http://www.ire.com
References: