Takeshi Takahashi <takeshi_takahashi@xxxxxxxxxx> writes:
> Reviewer: Takeshi Takahashi
> Review result: Ready
>
> I do not see any serious issues on this draft and enjoyed reading it.
> I have only minor questions for the purpose of deepening my
> understanding of the draft.
Awesome, thanks for taking a look! Let me see if I can help.
> 1. In section 5, regarding the The TD-CERT-DIGEST-ALGORITHMS-Data
> message, who embed the rejectedAlgorithm field? If it will be the KDC,
> why does the KDC need to fill and distribute this information to the
> others?
It has to be the KDC. I believe the purpose of sending
TD-CERT-DIGEST-ALGORITHMS-DATA is to enable clients that have multiple
certificates to retry, to enable debugging without KDC access, and
worst-case to allow the user to request re-issuance of the certificate
in question.
rfc4556 section 3.2.2 (PKINIT's specification for how to handle client
requests) states:
If the digest algorithm used in generating the CA signature for the
public key in any certificate of the request is not acceptable by
the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the
code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data
MUST be encoded in TYPED-DATA, although none is defined at this
point.
The important part here is that it applies to *any* certificate in the
request. Sending the rejectedAlgorithm helps figure out which cert is
problematic. There are other ways this could have been accomplished,
but that ship has sailed.
(Finally, the KDC doesn't technically "need" to send this structure; if
it wishes for some reason to be mysterious, the draft specifies that the
KDC "can OPTIONALLY send a list of digest algorithms".)
> 2. In section 8 (security consideration), it is stated that "to do
> otherwise allows an active attacker to perform a downgrade attack". In
> my understanding of the draft, arbitrary algorithm could be used (if
> the negotiation reaches agreements). I wonder if there is any
> mechanism that discourages the negotiation of using insecure
> algorithms. For instance, the list of algorithms that must be treated
> with care could be listed somewhere?
The security properties we're counting on from underling algorithms
(like SHA1) here are pretty normal. Personally, I don't think we should
be tracking algorithm security for Kerberos separately than from the
rest of the crypto ecosystem - for instance, sha1 weakening affects TLS
and everyone else just as it does us.
That said, there have been two RFCs so far about removing algorithms
from Kerberos: 6649 (1DES and export-strength RC4) and 8429 (3DES and
the rest of RC4). Adoption of these is difficult, however, since some
sites require interop with older setups (such as Windows Server 2003)
that don't support AES. The result is that Kerberos implementations
tend to enable by default only a subset of the algorithms they fully
support. Making the tradeoff between security and interoperability is
left as a policy decision.
On the management side, Linux distros have been working to tie all these
different configuration knobs together in one place. I'm sure there are
others, but in Fedora we use the crypto-policies [1] project to handle
weakenings/deprecations of various algorithms across the software in the
distribution.
Thanks,
--Robbie
1: https://gitlab.com/redhat-crypto/fedora-crypto-policies
Attachment:
signature.asc
Description: PGP signature
