[kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)

Christer Holmberg via Datatracker
Eric Rescorla has entered the following ballot position for
draft-ietf-kitten-pkinit-alg-agility-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

IMPORTANT
I think this document would benefit greatly from describing the
downgrade properties of each of the axes on which algorithms
can be negotiated against various forms of compromise in the
digest function.

The relevant case is one in which the client and KDC both support
one weak and one strong algorithm. Can the attacker either

(1) force them to complete a handshake with a weak algorithm
or
(2) convince one side that the other side supports a weak algorithm
and then interpose itself as that side.

Specifically it would be useful to know which attacks are possible
with a collision attack versus a preimage attack (though this
can sometimes be hard to know).


Here is one case of a potential real downgrade attack (though not a
very powerful one).

The client sends a KRB-REQ signed with algorithm A, the attacker
forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
weaker algorithm. This causes the client to retry with that weaker
algorithm. Is this attack detectable? It's not clear to me how (though
it maybe could be if the message were folded into the transcript).

OTOH, I don't think that the equivalent attack on the cert signer
algorithms is necessarily very useful because presumably the certs are
public already. OTOH, it might force the client into using some weaker
key.


I'm having a little trouble following the point in S 3. Is the idea
that the paChecksum is always SHA-1 and you don't add a way to negotiate
it, so you are instead folding the information into the KDF? If so,
I think we need to work through the chain of logic here. As I understand
it, the paRequest is included in the AuthPack, which is signed. So
presumably the idea is that the AuthPack is signed with SHA-256
but because paChecksum is SHA-1, the binding is weak, right? But
can you safely send a SHA-256 signature to a KDC which you have
never talked to before? Can't you just get downgraded by the attack
I describe above? Can you help unpack this for me?


MINOR
I wish you were using HKDF, but I don't think this is a dealbreaker.


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)

Robbie Harwood
Eric Rescorla via Datatracker <[hidden email]> writes:

> IMPORTANT
>
> I think this document would benefit greatly from describing the
> downgrade properties of each of the axes on which algorithms can be
> negotiated against various forms of compromise in the digest function.
>
> The relevant case is one in which the client and KDC both support one
> weak and one strong algorithm. Can the attacker either
>
> (1) force them to complete a handshake with a weak algorithm
> or
> (2) convince one side that the other side supports a weak algorithm
> and then interpose itself as that side.
>
> Specifically it would be useful to know which attacks are possible
> with a collision attack versus a preimage attack (though this can
> sometimes be hard to know).
>
>
> Here is one case of a potential real downgrade attack (though not a
> very powerful one).
>
> The client sends a KRB-REQ signed with algorithm A, the attacker
> forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
> weaker algorithm. This causes the client to retry with that weaker
> algorithm. Is this attack detectable? It's not clear to me how (though
> it maybe could be if the message were folded into the transcript).
>
> OTOH, I don't think that the equivalent attack on the cert signer
> algorithms is necessarily very useful because presumably the certs are
> public already. OTOH, it might force the client into using some weaker
> key.
Hi,

Greg has been kind enough to provide us with a -07 of this document that
should address these concerns in the "Security Considerations" section.

> I'm having a little trouble following the point in S 3. Is the idea
> that the paChecksum is always SHA-1 and you don't add a way to
> negotiate it, so you are instead folding the information into the KDF?
> If so, I think we need to work through the chain of logic here. As I
> understand it, the paRequest is included in the AuthPack, which is
> signed. So presumably the idea is that the AuthPack is signed with
> SHA-256 but because paChecksum is SHA-1, the binding is weak, right?
> But can you safely send a SHA-256 signature to a KDC which you have
> never talked to before? Can't you just get downgraded by the attack I
> describe above? Can you help unpack this for me?
Copying Greg's response from the other thread for completeness:

(I assume "paRequest" is a typo for "paChecksum".)

I don't understand the last part of this question.  If an attacker
substitutes an altered KDC-REQ-BODY via an attack on SHA-1 (either on
the paChecksum itself or on the CMS signature of the SignedAuthPack
containing the checksum), the KDC won't detect the substitution, but the
client will fail to decrypt the reply because the KDC will derive the
reply key with the altered KDC-REQ-BODY and the client will derive the
reply key with the original one.  This protection does not apply if the
attacker manages to downgrade the exchange to the old KDF, of course.

> MINOR
>
> I wish you were using HKDF, but I don't think this is a dealbreaker.

Yeah, bit hard to change that now.

Thanks,
--Robbie

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

signature.asc (847 bytes) Download Attachment