[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
oakley-03: last call comments
In the last months I have been collaborating with Dan Harkins
on several design issues for the isakmp/oakley protocol.
Dan has been very open and receptive of the changes and design
guidelines that I suggested. There are two issues, however, that were
not resolved in oakley-03. They are significant for security and
functionality reasons so I insist they need to be done.
I am also adding a third simple change that I failed to communicate
to the editors in time before the appearance of oakley-03.
The changes are simple from editorial point of view (full text change
is suggested below). They do impact implementations but do not require
any extensive work to adjust to them. Therefore, now is the right
time to do them before fielded implementations are available.
Notice that I am careful not to suggest any change that could
lead to delays in the standard definition and deployment.
Change No. 1: Quick Mode
************************
The draft says:
> Quick Mode is defined as follows:
>
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), SA, Ni
> [, KE ] [, IDui, IDur ] -->
> <-- HDR*, HASH(2), SA, Nr
> [, KE ] [, IDui, IDur ]
> HDR*, HASH(3) -->
>
> Where:
> HASH(1) and HASH(2) are the prf over the message id (M-ID) from
> the ISAKMP header concatenated with the entire message that follows
> the hash including payload headers, but excluding any padding added
> for encryption. HASH(3)-- for liveliness-- is the prf over the value
> zero represented as a single octet, followed by a concatenation of
> the message id and the two nonces-- the initiator's followed by the
> responder's. In other words, the hashes for the above exchange are:
>
> HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ])
> HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ])
> HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr)
>
Problem: A basic practice in authentication protocols is to use nonces to
guarantee the freshness of the authentication messages.
In this case there is a nonce Ni sent for I to R in the first message.
That nonce Ni needs to be incorporated into the hash computation of HASH(2)
for such a freshness purpose (to prevent re-play attacks).
This is also consistent with design of HASH_I and HASH_R in all the
other modes of the protocol.
Recommendation: Change
> HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ])
to
HASH(2) = prf(SKEYID_a, M-ID | SA | Nr | Ni [ | KE ] [ | IDui | IDur ])
^^
Discussion: Currently, freshness in HASH(2) IS provided
via the field M-ID which ISAKMP specifies to be "randomly chosen by the
Initiator". The problem is that M-ID (message identifier) has
no cryptographic motivation by itself in ISAKMP. It is used by a system
to differentiate parallel (phase 2) exchanges belonging to the same tunnel.
In particular, in many cases implementations could dispense of the randomness
(e.g. when no parallel sessions are run).
Actually, we cannot even guarantee that this definition
of M-ID as a random number will not be changed in the future in arevised ISAKMP
version. Who will then remember that there is a cryptographic use of this
number in Oakley?
Since Ni is there anyway in Oakley let's use it as freshness guarantee, thus
making Oakley more self-contained, more secure, and easier for analysts
and implementers to understand its cryptographic rationale and design.
Change No. 2: Authentication through public key encryption
***********************************************************
Problem: The draft currently provides identity protection in this mode
(page 11) by encrypting the identities under a public key encryption.
As specified now this public key encryption is separated from that
of the nonces Ni and Nr. This means that the protocol requires TWO
encryption and decryption operation for each party. This is unnecessarily
expensive (depending on your processor the extra exponentiation may have
negligible up to significant effect in performance). Indeed it is enough
to encrypt the nonce under the public key
and to derive from it a key for a symmetric encryption (e.g. under DES)
of the identity. This solution adds no significant complexity to the
implementation and saves a costly long (RSA or other) exponentiation.
(It also allows to easily encrypt long certificates if sent from Inititiator
to Responder; currently such an encryption is not specified/possible.)
Recommendation: Change the following text (page 11)
>
> In addition to the nonce, the identities of the parties (IDii and
> IDir) are also encrypted with the other parties public key. If the
> authentication method is public key encryption, the nonce and
> identity payloads MUST be encrypted with the public key of the other
> party. Only the body of the payloads are encrypted, the payload
> headers are left in the clear.
>
> When using encrytion for authentication with Oakley, Main Mode is
> defined as follows.
>
> Initiator Responder
> ----------- -----------
> HDR, SA -->
> <-- HDR, SA
> HDR, KE, [ HASH(1), ]
> <IDii>PubKey_r,
> <Ni>PubKey_r -->
> HDR, KE, <IDir>PubKey_i,
> <-- <Nr>PubKey_i
> HDR*, HASH_I -->
> <-- HDR*, HASH_R
>
> Oakley Aggressive Mode authenticated with encryption is described as
> follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, [ HASH(1),] KE,
> <IDii>Pubkey_r,
> <Ni>Pubkey_r -->
> HDR, SA, KE, <IDir>PubKey_i,
> <-- <Nr>PubKey_r, HASH_R
> HDR, HASH_I -->
>
>
>
> Harkins, Carrel [Page 11]
TO:
The nonce is encrypted with the other parties public key.
The identities of the parties (IDii and IDir) are encrypted with
a symmetric cipher (as negotiated by the ISAKMP Security Association,
e.g. DES) using a key derived from the nonce (if a certificate is passed
from Initiator to Responder it is encrypted under the same key as the
identities).
If the authentication method is public key encryption, the nonce payload
MUST be encrypted with the public key of the other party. Only the body
of the payloads are encrypted, the payload headers are left in the clear.
When using encryption for authentication with Oakley, Main Mode is
defined as follows.
Initiator Responder
----------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, [ HASH(1), ]
<Ni>PubKey_r -->
<IDii>Ne_i
[<Cert-I>Ne_i]
<-- HDR, KE, <Nr>PubKey_i
<IDir>Ne_r
HDR*, HASH_I -->
<-- HDR*, HASH_R
The keys Ne_i and Ne_r are defined as:
Ne_i = prf(Ni, CKY-I)
Ne_r = prf(Nr, CKY-R)
The notation <...>PubKey refers to public key encryption
(e.g. using the RSA algorithm) while the notation <...>Ne
refers to encryption under a symmetric cipher (e.g DES)
as negotiated for payload encryption by the ISAKMP SA.
The key used for symmetric encryption to protect the third
(resp. fourth) message payloads is derived (and possibly expanded)
from Ne_i (resp. Ne_r) in an algorithm-specific manner (see appendix B).
If CBC mode is used for the encryption then the initialization vector (IV)
is set to 0 (notice that the value Ne_i is ephemeral).
Encrypted payloads are padded up to the nearest block size using bytes
containing 0x00.
Oakley Aggressive Mode authenticated with encryption is described as
follows:
Initiator Responder
----------- -----------
HDR, SA, [ HASH(1),] KE,
<Ni>Pubkey_r,
<IDii>Ne_i -->
[<Cert-I>Ne_i]
HDR, SA, KE, <Nr>PubKey_i,
<-- <IDir>Ne_r, HASH_R
HDR, HASH_I -->
(end of proposed change)
Discussion: A further security measure that can be taken here is to use
Ne_i and Ne_r to encrypt the KE payload. This adds more security to the DH
exchange (against broken modulus p, against short exponents, etc.).
I leave the decision to the editors whether to add this encryption as part
of the specification or not.
Also, notice that I left the HDR* notation in non-aggressive mode although
this encryption (under SKEYID_e) it is not really necessary since
the identities are not there. Whether to remove that encryption
is up to the editors. Leaving it adds to the processing time but may simplify
implementation as it is consistent with other non-aggressive modes.
Change No. 3: Derivation of SKEYID
**********************************
SKEYID derivation is defined as:
>
> For signatures: SKEYID = prf(Ni | Nr, g^xy)
> For public key encryption: SKEYID = hash(Ni | Nr)
> For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr)
In the case of public key encryption I suggest to change the definition to
For public key encryption: SKEYID = prf(Ni | Nr, CKY-I | CKY-R)
This is better compatible with the definition of prf (rather than just hash)
and uniform with all other key derivations in this protocol.
Note: The suggestion SKEYID = hash(Ni | Nr) is my own fault. Pau-Chen Cheng
suggested the above improved prf derivation.
Hugo