Subject: RE: pk-init-29

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 14 Nov 2005 22:28:22 -0800

Steven Bellovin said the following in the CRYPTOGRAPHIC HASH WORKSHOP, "Agility is hard to get right unless you actually trying to deploying a new algorithm". 

Lacking of standard definitions as what is algorithm agility, all I found in this information age are blogs. Burt Kaliski @ RSA says the following in his blog:

"A protocol or system has algorithm agility if it is possible to upgrade or replace an algorithm without changing the protocol or system. The system may employ new tags or identifiers to indicate the use of a different algorithm, and the protocol flow may vary. The design and implementation of the protocol or system, however, must be flexible enough to handle the new algorithm -- even an algorithm not envisioned when the design was originally produced."

In the case of PKINIT, the signature algorithms are pretty much tied with the client certificate and the KDC certificate: Let's say you have ECDSA certificates, you won't choose to do RSA signing with your ECC keys. So I believe all these discussions boil down to figure out which hash algorithm to use, for that you can get a fair good hint from the signature algorithm in the certificates. 

Since we are anticipating a hash upgrade in the near future, should we punt the hash algorithm negotiation till then? It is fairly clear to me that the existing messages are flexible enough such that we can do that negotiation with backward compatibility in the future. One example approach would be what I proposed earlier.

PKINIT has been in the draft mode for more than a decade now, shall we get the spec out without hash algorithm negotiation for now, given we do not negotiate hash algorithms in other part of the same protocol?

-- Larry

-----Original Message-----
From: Liqiang(Larry) Zhu 
Sent: Monday, November 14, 2005 12:08 PM
To: Sam Hartman
Cc: Love Hörnquist Åstrand; [email-masked]
Subject: RE: pk-init-29

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> 
> writes:

>>    Liqiang(Larry)> IMO, crypto-agility does not mean all algorithms
>>    Liqiang(Larry)> have to be negotiated on the wire. 

> No, that's exactly what it means.

What if the protocol has only one message, such as the case of GSS-API Kerberos with no server authentication? 

there are protocols out there can not be fixed in order to negotiate. I suspect SMIME/CMS falls into such category.

> We do need to look at hash agility both for the DH KDF and for
> signatures and for cert selection.  We don't need to support
> negotiation today but we do need to confirm we can add it in a
> backward compatible manner.

I believe this can be done with the help of extensibility marker we have today.

> In other words it needs to be the case that a KDC must return a well
> defined and unique error for each use of hashes and it must be the
> case that this error is intended to take TD.

In order to avoid another unsigned error, I would propose to allow signature algorithms in the supportedCMSTypes field of AuthPack.

          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
                                      OPTIONAL,
                   -- Type AlgorithmIdentifier is defined in
                   -- [RFC3280].
                   -- List of CMS signature and encryption algorithms 
                   -- supported by the client in order of (decreasing) 
                   -- preference.

Appropriate and equivalent language should be added into the main body as well.

This way, if an error occurs, the KDC does not need to send back anything other than an error (perhaps with text in the error).

Do you agree with this change then?

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, November 14, 2005 11:48 AM
To: Liqiang(Larry) Zhu
Cc: Love Hörnquist Åstrand; [email-masked]
Subject: Re: pk-init-29

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> IMO, crypto-agility does not mean all algorithms
    Liqiang(Larry)> have to be negotiated on the wire. 

No, that's exactly what it means.

For Love's initial question it is fine if the client sends all the
algorithms it supports because if the server returns an error then the
client cannot succeed.

We do need to look at hash agility both for the DH KDF and for
signatures and for cert selection.  We don't need to support
negotiation today but we do need to confirm we can add it in a
backward compatible manner.

In other words it needs to be the case that a KDC must return a well
defined and unique error for each use of hashes and it must be the
case that this error is intended to take TD.