[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Weak authentication in Xauth and IKE, CMC token enroll
Sounds good to me, however the implementation described in CMC may not be
providing the protection implied. But its nothing that can't be fixed,
problem:
Section 5.2 Identification and IdentityProof Control Attributes states:
The CMC method starts with an out-of-band transfer of a token (the shared
secret). The distribution of this token is beyond the scope of this
document. The client then uses this token for an identity proof as
follows:
1. The reqSequence field of the PKIData object (encoded exactly as it
appears in the request message including the sequence type and length)
is the value to be validated.
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the value produced in Step 1,
as described in [HMAC], using the hash of the token from Step 2 as the
shared secret value.
4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value
of the identityProof attribute.
Note that with a regular shared secret (non hardware token) the shared
secret also acts to protect the message since reqSequence can not be altered
without the identityProof verification failing.
In section 5.2.1 Hardware Shared Secret Token Generation it states:
The shared secret between the end-entity and the identity verify is
sometimes transferred using a hardware device that generates a series of
tokens based on some shared secret value. The user can therefore prove
their identity by transferring this token in plain text along with a name
string. The above protocol can be used with a hardware shared-secret
token generation device by the following modifications:
1. The identitification attribute MUST be included and MUST contain the
hardware-generated token.
2. The shared secret value used above is the same hardware-generated
token.
3. All certification requests MUST have a subject name and the subject
name MUST contain the fields required to identify the holder of the
hardware token device.
Number 2 is confusing. "The shared secret value used above is the same
hardware-generated token." To me this means use the hardware generated token
as the shared secret in the algorithm described in 5.2 BUT then point 1
states "The identitification attribute MUST be included and MUST contain the
hardware-generated token." If the "identitification attribute" is
transmitted in the clear
("The user can therefore prove their identity by transferring this token in
plain text along with a name string")
than you are sending your shared secret in the clear. This allows anyone to
modify reqSequence undetected, since they can then recalculate identityProof
and sign the PKIData with their own key, placing their public key in
reqSequence. And the server/CA still thinks its you since the token will
validate. CMC does allow encryption of the signedData PKIData message,
which would prevent this, but it is not required.
But this can be fixed, and the same principle applied to CMP (rfc2510)
shared secrets or any other PKI boot strap protocol.
Possible solutions are to not transmit the 'token', or use CMC encryption.
Not transmitting the 'token' works for DES challenge/response cards but not
too well for SecurID but is doable with mods on their end, and would be
preferable. Instead of asking their server "Is this response correct",
their server would say "here are the acceptable responses for this minute in
time" you would then calculate the HMAC with each returned response until
you find a match. Alternatively they could modify their server to take as
input a HMAC output and data and be able to tell you if the user could have
generated that HMAC (using their response as the HMAC key).
Requiring encryption in CMC requires support for RSA, and may have export
issues...
Also not addressed is that DES based challenge/response cards typically need
to receive the "Challenge" so that it can be entered into the card to
produce the "token"/shared secret. Some cards have a "guess next challenge"
mode which would get around this but if the card/server become out of sync
then you need a way for the server to "challenge" the user.
Another draw back with the method described in CMC is that it does not allow
the client to verify the CA, since the shared secret is sent in the message,
and even if the shared secret was not sent in the message there is no
corresponding "CA identityProof" on the response messages. However I am not
sure if verifying the CA is a goal of CMC since its not even done with
regular nonhardware based secrets(it should be but I will leave that to PKIX
working group).
If the above issues are addressed than its a great way to make use of the
existing infrastructure, whether through CMC or CMP or ....
Bye.
-----Original Message-----
From: Dan Harkins [mailto:dharkins@network-alchemy.com]
Sent: Monday, August 23, 1999 3:36 PM
To: John Pliam
Cc: Tamir Zegman; ipsec@lists.tislabs.com
Subject: Re: Weak authentication in Xauth and IKE
On Mon, 23 Aug 1999 17:04:06 -0000 John Pilam wrote
>
> I must first make clear that, IMHO, XAUTH/Hybrid is the only proposal for
> legacy authentication within IPSEC that can reasonably be said to provide
> strong authentication. By that standard, it is therefore the only one
> which is ISAKMP compliant. All others fall to variants of the attacks I
> have posted.
Let me propose another technique then. One that doesn't require any
asymmetry in the IKE negotiation, doesn't imply a weakly authenticated
IKE SA, and allows for strong, mutual authentication.
I believe that CMC allows for token card authentication; the token
card credentials authenticate enrollment into a CA. This can be used to
deliver a very short lived (or one-time) certificate. The client then
uses this certificate in the standard way-- no modification to IKE is
necessary. Due to the short lifetime of the certificate the client would
be forced to use it immediately in a standard IKE exchange. The IKE
implementation on the non-client end need not have any special hooks to
understand an extended or asymmetric authentication. It's just a plain,
vanilla, IKE.
This solves the concern of a private key (whose public analog is contained
in the certificate) from living on a transient device like a lap top for an
extended period of time. The public/private key pair can be generated
immediately prior to authentication using the token card and once the
resulting certificate is used any exposure of the private key would not be
catastrophic since the certificate would no longer be valid.
It allows the issuing entity full flexibility in setting the lifetime
of the certificates. It would not be necessary to have the device speaking
IKE be the same device that is authenticating the remote client and issuing
the certificate-- it could be, but need not be.
It requires no hacks to IKE. Granted, it does require implementation of
CMC,
which is no small matter, but it seems to me that a profile of CMC-- some
subset of the full CMC functionality-- could be defined to meet these needs.
This subset need not be much greater than what is already required for XAUTH
but with the added benefit of not having to modify IKE.
It addresses the concern that people have that their token cards must be
used in some manner as a way of amortizing the cost (this is largely a
political arguement but one that is very compelling nonetheless). Since it
uses certificates it is a must smoother transition to get people off the
token card addiction than either XAUTH or XAUTH+Hybrid.
Finally, it separates the two steps-- token card authentication and the
IKE protocol-- and eliminates the need to change your IKE implementation.
There is no need for a "remote access IKE" and a separate "VPN IKE".
Is there any desire in the WG to pursue this?
Dan.