Subject: Re: [Ietf-krb-wg] PKINIT with smart-cards

From: Nico Williams <[email-masked]>
Date: Mon, 9 May 2011 15:13:42 -0500

On Mon, May 9, 2011 at 11:14 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
>  I've been thinking of an attack relating to Public key Kerberos
> with smart-cards and I'd appreciate if anyone could verify
> that what is described is not due to my misunderstanding
> of the protocol.
>
> The legitimate owner is equipped with a smart-card containing
> an RSA private key and a certificate that restricts it to
> signing (meaning Diffie-Hellman PKINIT will be used).

This wouldn't work with the RSA key transport option, no, because the
AS encrypts the reply key in the client principal's public key --
getting to it requires access to the client principal's private key.

Clever attack.  The attacker is constrained to using the manufactured
requests only while the requests remain fresh (there's a timestamp in
the request), so there's that mitigation.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 9 May 2011 18:14:00 +0200

Hello,

(two scenarios illustrating the same impersonation attack)

1. The attacker steals the smart card and the PIN required to operate it.
Performs several precalculations for PK_AS_REQ with future timestamps
that span for next few years. Places the smart-card back to the owner.
The owner has no way of detecting that the card has been used and
the key although no compromised, it can be used to impersonate
him by the thief.

2. A malicious smart-card reader is installed in a way that legitimate
users will use it to connect using Kerberos. The reader operates
as expected, but during idle time that the card is inserted the reader
precalculates PK_AS_REQ messages with future timestamps. The
owner has no way of knowing that.

The attacker having the PK_AS_REQ signed message can initiate
connections impersonating the legitimate owner at any time
of his choice.

best regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Mon, 9 May 2011 15:26:49 -0500

Pardon the brainfart, the ctime doesn't help.

Sounds like there should be a challenge-response in the non,anonymous,
non-key transport case.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 9 May 2011 13:01:44 -0700

Can't point at the exact verbiage in 4556 without more time, but pretty sure there's no way to decrypt and use the AS_REP unless you have the private key.  In other words you can't complete the exchange and get a TGT without actually having the card.

There are still two things that come to mind if you want to pursue this:  1) There may be scenarios where being able to substitute such a precomputed request for a legitimate one might cause exploitable behavior on the part of the legitimate client.  2) You might study the various reply options in 4556 to see if there is an allowed combination which bypasses the need for the card to process the AS_REP.  If such a misconfiguration is possible, then it might exist in the wild.

> connections impersonating the legitimate owner at any time

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 May 2011 13:35:25 +0200

> getting to it requires access to the client principal's private key.

Indeed, it is only applicable to the Diffie-Hellman variant. It is interesting
though that intuition is not correct here. Although Diffie-Hellman
provides perfect forward secrecy, a stronger security guarrantee
than of the plain RSA key transport, it does not protect against this attack.

regards,
Nikos

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 May 2011 10:58:50 -0400

>>>>> "Nikos" == Nikos Mavrogiannopoulos <[email-masked]> writes:

    Nikos> On Mon, May 9, 2011 at 10:13 PM, Nico Williams <[email-masked]> wrote:
    >>> Â I've been thinking of an attack relating to Public key
    >>> Kerberos with smart-cards and I'd appreciate if anyone could
    >>> verify that what is described is not due to my misunderstanding
    >>> of the protocol.  The legitimate owner is equipped with a
    >>> smart-card containing an RSA private key and a certificate that
    >>> restricts it to signing (meaning Diffie-Hellman PKINIT will be
    >>> used).
    >> This wouldn't work with the RSA key transport option, no, because
    >> the AS encrypts the reply key in the client principal's public
    >> key -- getting to it requires access to the client principal's
    >> private key.

    Nikos> Indeed, it is only applicable to the Diffie-Hellman
    Nikos> variant. It is interesting though that intuition is not
    Nikos> correct here. Although Diffie-Hellman provides perfect
    Nikos> forward secrecy, a stronger security guarrantee than of the
    Nikos> plain RSA key transport, it does not protect against this
    Nikos> attack.

My initial analysis suggests this is a valid attack.

Speaking only as an individual.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Tue, 10 May 2011 16:22:26 -0400

>     Nikos> plain RSA key transport, it does not protect against this

Forward secrecy is powerful, but only if properly authenticated.  The
semantics of the authentication of the DH parameters are crucial here.
The authentication evidence that the KDC has when it receives the
AS-REQ is that at some point in the past, someone with control over
the client's RSA private key used it to sign the DH parameters (and
other AuthPack stuff) the KDC received.  The KDC has no evidence that
the signature is "fresh".

> My initial analysis suggests this is a valid attack.

I agree that this looks like a valid attack.  One could argue that the
attack should be out of scope, as it effectively requires that a smart
card and reader be subverted, which is comparable the consequences of
someone's password being captured in symmetric-key Kerberos.

However, it does contradict a security assumption (perhaps an implicit
one?) that an attacker would have to have active physical control over
the smart card in order to access any resources that require
authentication from the smart card.  The ability of the attacker to
use temporary control of the smart card to precompute some signatures
and use them in the future without the presence of the smart card is
not an expected property of a smart card based authentication system.

I also note that if the smart card were to keep a tamper-resistant
audit log of all public key operations performed by it, this attack
might be detectable.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 May 2011 22:49:29 +0200

On 05/10/2011 10:22 PM, Tom Yu wrote:

> Forward secrecy is powerful, but only if properly authenticated.
> The semantics of the authentication of the DH parameters are crucial
> here. The authentication evidence that the KDC has when it receives
> the AS-REQ is that at some point in the past, someone with control
> over the client's RSA private key used it to sign the DH parameters
> (and other AuthPack stuff) the KDC received.  The KDC has no evidence
> that the signature is "fresh".

So in that context timestamps fail to provide freshness.

> I agree that this looks like a valid attack.  One could argue that
> the attack should be out of scope, as it effectively requires that a
> smart card and reader be subverted, which is comparable the
> consequences of someone's password being captured in symmetric-key
> Kerberos.

It is out of scope if you take the existing models of adversaries.

> However, it does contradict a security assumption (perhaps an 
> implicit one?) that an attacker would have to have active physical 
> control over the smart card in order to access any resources that 
> require authentication from the smart card.  The ability of the 
> attacker to use temporary control of the smart card to precompute 
> some signatures and use them in the future without the presence of 
> the smart card is not an expected property of a smart card based 
> authentication system.

You are right it is an implicit assumption as I've never really seen
any discussion over it, but rather it is assumed in all smart-card
solutions. That is because smart-cards transform cryptographic objects
(keys) to physical objects and expectations of the physical object (such
as possession) should also be available to the keys and protocols involved.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 16:10:22 -0500

> someone's password being captured in symmetric-key Kerberos.

It's not just any attacker that can mount this attack.  The user can
pre-mint AS-REQs so that they never have to bother plugging in their
smartcard (or even carrying it), much less entering their PIN.

Nico

---

From: Tom Yu <[email-masked]>
Date: Tue, 10 May 2011 17:07:44 -0400

> as possession) should also be available to the keys and protocols involved.

A key difference is that temporary access to (and reportedly, casual
visual inspection by a sufficiently skilled adversary!) a physical key
for a mechanical lock can be sufficient to easily and surreptitiously
duplicate it, while a design goal of tamper-resistant cryptographic
key stores such as smart cards is that temporary physical access
should still present substantial barriers to surreptitious
duplication.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 May 2011 01:38:24 +0200 (MEST)

> So in that context timestamps fail to provide freshness.

But there _are_ no timestamps involved.

This protocol is about unique nonces generated by the client for
the purpose of creating a replay protection for the protocol.
In an attempt to help the server not having to keep an eternal,
unlimited size replay cache for all nonces ever created, time-based
nonces plus a window of validity are used.
The time-based validity window splits the nonces into two groups,
those that can be checked for replay, and those which can not be checked
for replay.  Assumptions about "freshness" apply at most to passive
observers, but not creators of the nonces.

Conceiving the time-based nonces created by the client as timestamps
can easily result in flawed assumptions about the properties of the
protocols, such as that it would provide a "freshness" proof.

If a RP wants freshness, then it must either newly generate a unique
challenge, or use some real time stamp, i.e. a time value that is
digitally signed (or at least securely MACed) by some trusted time source
or by the RP itself.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 May 2011 08:04:47 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> If a RP wants freshness, then it must either newly generate
    Martin> a unique challenge, or use some real time stamp, i.e. a time
    Martin> value that is digitally signed (or at least securely MACed)
    Martin> by some trusted time source or by the RP itself.

I think we're all in agreement with that statement.

The question seems to boil down to whether the KDC wants freshness in
authentication requests.  Put that way, the intuitive answer is that
yes, the KDC does care about freshness of authentication requests.
That's not quite an answer to whether we need to fix this attack:
intuition does not always match reality.

--Sam

---

From: Tom Yu <[email-masked]>
Date: Wed, 11 May 2011 09:50:57 -0400

> intuition does not always match reality.

Consider the case of a smart card used as secure storage for a
symmetric key that is used for Kerberos.  An attacker with temporary
access to the smart card can precompute a (non-FAST) encrypted
timestamp preauth in the AS-REQ, but the KDC doesn't care whether it's
fresh, because the attacker would need to have active access to the
key to decrypt the AS-REP.  PKINIT in DH mode doesn't have this
property for the reply key, so PKINIT with a smart card is "weaker"
than symmetric key Kerberos with the symmetric key stored in a smart
card.

We should get more input from the smart card user community about how
serious they think this problem is.  Doug Engert, are you listening?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 May 2011 10:11:32 -0500

I do think the KDCs (or, rather, the realm admins) want freshness, for
policy reasons.  Namely: the smartcard is the "something the user has"
and the PIN is the "something the user knows".  If the user can
circumvent this by pre-minting all the AS-REQs they'll need, that's
bad.

The fact that an attacker who can gain temporary access to a logged-in
token can take advantage of it to mint future AS-REQs is a problem
too.  Specifically it's an auditing problem.  This could be mitigated
by auditing on the smartcard, but that's hardly ideal.

So, yes, I think we should fix this.  I don't think it's urgent, but
certainly it should be desirable.

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 11 May 2011 10:21:17 -0500

On 5/11/2011 8:50 AM, Tom Yu wrote:
> Sam Hartman<[email-masked]>  writes:
>
>>>>>>> "Martin" == Martin Rex<[email-masked]>  writes:
>>

Yes I am listing.

Can current implementations of KDCs be configured to not accept DH?
And client configured to not use DH even if the key usage only has
"Digital Signature"?

Most smart cards if not all, do not associate the key usage bits in the
certificate with the private key. So any RSA operation can be done
using the key on the card. Its the PKINIT software on the client and
server side that would be enforcing this.

But based on recent discussions about LOA, I think this attack
would be taken seriously.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 May 2011 10:33:45 -0500

> And client configured to not use DH even if the key usage only has

The way PKINIT works is that if you want users to have signing-only
certificates then you must use DH.  This makes DH fairly popular,
IIUC.

> server side that would be enforcing this.

Yes, but the KDC will want the user to have a certificate for
encryption when the user wants to use RSA key transport.  Switching
from signing to encrypting with the same key is not a workaround.

Nico

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 May 2011 17:36:35 +0200 (MEST)

> certainly it should be desirable.

Technically, the "pre-minting" is possible for vanilla RSA as well.
But the processing of the AS_REP requires presence of the private key,
which for a hardware token (with non-exportable private key) means
token presence.

So what you have with RSA is not a "freshness proof" of any kind, but
a "RSA private key present" pre-requisite for the processing of the
AS_REP by the client.  It depends on your protocol whether that
property is sufficient to address your concerns.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 11 May 2011 08:40:37 -0700

> intuition does not always match reality.

+1  (also to Yom Yu's first post)

Assuming this problem is as real as people are now saying, my immediate reaction is that this is bad, but not so bad we would *have* to do anything about it.  We would need reevaluate the use of PKINIT for e.g. high level-of-assurance applications.  Probably use the card directly with TLS some times we'd rather not.

As a possible workaround, is it feasible to disable DH mode?  I have not tracked which platforms use which mode.  (In particular, which does Microsoft use?)

Larry Zhu, are you listening?  ;-)

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 May 2011 11:22:03 -0500

> which for a hardware token (with non-exportable private key) means

Good point.

> property is sufficient to address your concerns.

And even that only happens if the client ever gets around to using the
issued Ticket.  Similar to how the Ticket is unauthenticated plaintext
in KDC replies yet that's not a problem because when the client
eventually tries to use the Ticket, if the Ticket works then that's
proof enough that the KDC reply was not tampered with.  So for the RSA
key transport case we have the same sort of mitigation as we have in
Kerberos in general for Ticket being unauthenticated plaintext in the
KDC-REPs.  I'm not saying that's great, just that it's good enough.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 May 2011 11:25:36 -0500

> As a possible workaround, is it feasible to disable DH mode?  I have not tracked which platforms use which mode.  (In particular, which does Microsoft use?)

Sure, but if you've deployed smartcards with signing certs only then
you lose the ability to use PKINIT with smartcards altogether.

In other words: if you want PKINIT with smartcards, and you want proof
[enough] of freshness, and you'd already deployed signing-only user
PKINIT certs, well, you have to re-credential your users -- likely an
expensive proposition.

IMO this attack is bad, but not so bad that folks should consider any
mitigation beyond on-smartcard auditing prior to a fix being
delivered.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 May 2011 12:28:35 -0400

<hat role="individual">

It's certainly possibly for the client to force the use of RSA mode.
I know MIT and Microsoft implement both.
I believe everyone prefers DH to RSA.

I'm not sure whether a KDC can force the use of RSA.
It looks like that might be possible in RFC 4556.
It would be interesting to see if someone could try this out; I suspect
it would involve code changes.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 May 2011 16:34:08 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Wed, May 11, 2011 at 10:40 AM, Henry B. Hotz <[email-masked]> wrote:
    >> As a possible workaround, is it feasible to disable DH mode?
    >> I have not tracked which platforms use which mode. Â (In
    >> particular, which does Microsoft use?)

    Nico> Sure, but if you've deployed smartcards with signing certs
    Nico> only then you lose the ability to use PKINIT with smartcards
    Nico> altogether.

There seem to be a number of smart cards that will use a signing only
cert for encription.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 11 May 2011 13:44:16 -0700

> There seem to be a number of smart cards that will use a signing only

Like the ECDSA certs that keeps popping up.

Love

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 12 May 2011 16:58:15 -0500

On 5/11/2011 3:44 PM, Love Hörnquist Åstrand wrote:
>>>>>>> "Nico" == Nico Williams<[email-masked]>  writes:
>>
>>     Nico>  On Wed, May 11, 2011 at 10:40 AM, Henry B. Hotz<[email-masked]>  wrote:

There does not appear to be any negotiation in the protocol,
other then the KDC could return KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED
and return a list of TD-DH-PARAMETERS.
"TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
  that the KDC supports in decreasing preference order, from which the
  client SHOULD pick one to retry the request."

It does not say what to do if the list is empty.

>>>> particular, which does Microsoft use?)

Looks like the Microsoft DC will use what ever the client requests.

Although the KDC needs to enforce no DH for selected accounts to
address this security issue some tests can still be done.

For testing purposes,the MIT 1.9.1 kinit -X flag_RSA_PROTOCOL=1 can
be used to force the client to use RSA. I tried this against Windows
2008 DC, with a PIV smart card with OpenSC driver and a certificate
with  X509v3 Key Usage: critical, Digital Signature.

The DC will return the PA-PK-AS-REP and has the encKeyPack, and the
private key on the card is used to decrypt it. But there is another issue,
in that the DC returns an encrypted SignedData, but does not include the
SEQUENCE as defined in RFC 3582. The MIT code has comments about this
and will handle the missing SEQUENCE, if the the krb5.conf
has pkinit_longhorn = 1. With all of this the ticket is obtained,
and the private key on the card has to be used. Thus this
would address the attack.

>> There seem to be a number of smart cards that will use a signing only

The cards themselves don't look at certificate key usage bits,
and if the card supports RSA RAW mode, the same card commands
are used for signing and decryption. The PKCS#11 middle ware
or the PKINIT code could, and refuse to continue.

But it is really up to the KDC with PKINIT case to enforce the
keyUsage bits. The certificate also has the Microsoft SmartcardLogin
X509v3 Extended Key Usage, so this could override the
basic KeyUsage (Some pkix RFCs needs to be consulted.)

> Like the ECDSA certs that keeps popping up.

The EC key in the cert can be used for ECDSA, as well as
ECDH to unwrap a key but I would have to read NIST 800-56A
again to see if one of the modes for ECC would address the
attack. i.e. force the EC private key to be used after
the AS-REP is returned. (NIST 800-73-3 defines ECC for
the PIV cards.)

--