[kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-07.txt

[Internet-Drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF.

        Title           : PKINIT Algorithm Agility
        Authors         : Love Hornquist Astrand
                          Larry Zhu
                          Margaret Wasserman
                          Greg Hudson
        Filename        : draft-ietf-kitten-pkinit-alg-agility-07.txt
        Pages           : 20
        Date            : 2019-04-18

Abstract:
   This document updates the Public Key Cryptography for Initial
   Authentication in Kerberos standard (PKINIT) [RFC4556], to remove
   protocol structures tied to specific cryptographic algorithms.  The
   PKINIT key derivation function is made negotiable, and the digest
   algorithms for signing the pre-authentication data and the client's
   X.509 certificates are made discoverable.

   These changes provide preemptive protection against vulnerabilities
   discovered in the future against any specific cryptographic
   algorithm, and allow incremental deployment of newer algorithms.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-07
https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Benjamin Kaduk-2]

Thanks for the updates, Greg -- they really help the document out!
(Thanks to Eric for spotting the needed changes.)

Before I push this off for publication, I just wanted to check whether KDC
policy had a role in providing downgrade protection in the discovery
methods from Sections 4 and 5 -- would there be a case where the KDC knows
to require the stronger CMS type/signing algorithm for a specific
principal, so that even if the client is tricked into downgrade by an
attacker, the exchange would still fail?

Thanks,

Ben

On Thu, Apr 18, 2019 at 12:05:04PM -0700, [hidden email] wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF.
>
>         Title           : PKINIT Algorithm Agility
>         Authors         : Love Hornquist Astrand
>                           Larry Zhu
>                           Margaret Wasserman
>                           Greg Hudson
> Filename        : draft-ietf-kitten-pkinit-alg-agility-07.txt
> Pages           : 20
> Date            : 2019-04-18
>
> Abstract:
>    This document updates the Public Key Cryptography for Initial
>    Authentication in Kerberos standard (PKINIT) [RFC4556], to remove
>    protocol structures tied to specific cryptographic algorithms.  The
>    PKINIT key derivation function is made negotiable, and the digest
>    algorithms for signing the pre-authentication data and the client's
>    X.509 certificates are made discoverable.
>
>    These changes provide preemptive protection against vulnerabilities
>    discovered in the future against any specific cryptographic
>    algorithm, and allow incremental deployment of newer algorithms.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-07
> https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Greg Hudson]

On 4/18/19 11:27 PM, Benjamin Kaduk wrote:
> Before I push this off for publication, I just wanted to check whether KDC
> policy had a role in providing downgrade protection in the discovery
> methods from Sections 4 and 5 -- would there be a case where the KDC knows
> to require the stronger CMS type/signing algorithm for a specific
> principal, so that even if the client is tricked into downgrade by an
> attacker, the exchange would still fail?

In any of the three downgrade scenarios the KDC could refuse the use of
the weak hash function as well.  I can add clauses about that:

   It is a matter of local policy whether a client accepts a downgrade
   to a weaker CMS type, and whether the KDC accepts the weaker CMS
   type.

   It is a matter of local policy whether a client accepts a downgrade
   to a weaker certificate, and whether the KDC accepts the weaker
   certificate.

   It is a matter of local policy whether a client accepts a downgrade
   to the old KDF, and whether the KDC allows the use of the old KDF.

Independent of anything described in the draft, an attacker could try to
impersonate the KDC to the client by forging the dhSignedData signature
using a weak hash algorithm, if the client allows that algorithm when
verifying the KDC signature.  Even if the client insists on a newer KDF
using a strong hash function, the attacker could do the key derivation
step using SHA-256 and the new KDF, and just sign the KDCDHKeyInfo with
SHA-1.  An attacker could conceivably do this via a SHA-1 collision (in
order to get the legitimate KDC to sign the same hash as the forged
reply) because KDCDHKeyInfo contains a nonce controlled by the client
when DH keys are not reused--but in that case the legitimate KDC places
a random subjectPublicKey into KDCDHKeyInfo, which might make the attack
impractical.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten