Subject: Signed KRB-ERR for password aging (re: extensibility)

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Dec 2001 17:27:02 -0500

A KDC MUST respond with an error to any AS-REQ for a client principal
which is expired or has an expired key or pasword. Such KRB-ERRORs can
be signed with a keyed checksum given the new extensible Kerberos. The
key to use for the checksum is the same key that would have been used to
sign the AS-REP had the principal/key/password not been expired.

In the context of the new extensible Kerberos I'd like to see the
following text, or something like it, added to the revisions:

"
When a KDC returns a KDC_ERR_NAME_EXP or KDC_ERR_KEY_EXPIRED KRB-ERROR
in response to an extensible AS-REP then the KDC MUST sign the KRB-ERROR
using the same key that would have been used to sign the AS-REP had the
client principal (or it's key/password) not been expired.
"

Aside: I'd love to see the key-mixing string2key stuff happen, along
with a multi-principal pre-auth type for use with it - that way we can
cut down the number of round trips needed to authenticate users to a
host and also secure the AS exchange with respect to most errors (use the
mixed key for signing where possible, or one of the client principals'
keys should the other be unknown to the KDC).

Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Dec 2001 12:20:35 +0100 (MET)

> client principal (or it's key/password) not been expired.

OUCH, NO please require the exact opposite!

An error message "signed" with the users secret key is all that
one needs to mount an offline dictionary attack.

The KDC should at least require a correct preauthentication before
using the users secret key to sign any error messages.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Dec 2001 12:33:08 +0100 (MET)

Actually, to be more precise:

A KDC must not sign any KRB-ERROR message with the secret key
of any principal except when responding to an AS-REQ that contains
valid PA-DATA *proving* the posession of said key by the requestor.

Even this leaves the KRB-ERROR message vulnerable to dictionary
attacks by a passive observer of the communication (unless
a DCE-like scheme with host-key superencryption of the
exchange is used -- does the DCE superencryption include
the KRB-ERROR message?).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 10:10:57 -0500

> using the users secret key to sign any error messages.

Come now. You'd issue a grace ticket to a password changing service
using the same darned key that you wouldn't sign the KDC_ERR_KEY_EXPIRED
KRB-ERROR?!

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 10:11:25 -0500

Oh yes, this I agree with.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 10:19:11 -0500

BTW, I had a chat with some of the MIT folk about this after the meeting
last week and we discussed the need for pre-auth before signing any
KRB-ERRORs. I forgot to write that up in my post.

And in my first post on this thread I hinted at what you call "host-key
superencryption."

Of course, there is always the possibility that there is no key in which
to sign a KRB-ERROR - that's the trade-off in a symmetric-only crypto
protocol. But if we can get the most important ones signed and if we can
reduce the number of round-trips needed to do initial authentication of
a user to a host (currently that's two round-trips: one AS exchange, one
TGS exchange and a local AP exchange) I think that would be a big win.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 10:44:22 -0500

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

    Martin> Actually, to be more precise: A KDC must not sign any
    Martin> KRB-ERROR message with the secret key of any principal
    Martin> except when responding to an AS-REQ that contains valid
    Martin> PA-DATA *proving* the posession of said key by the
    Martin> requestor.

That's silly.  If the KDC would have responded to a AS-REQ without
preauth data with an AS-REP then signing the krb-error is fine or at
least is not a new exposure.

When writing up krb-error checksumming rules I'm make it clear that a
KDC MUST NOT sign using the long-term key unless it would have used
that long-term key in an AS-REP.  Note in Nico's case he didn't
require that the KDC sign in the long-term key, only in the reply-key.

However  his proposal is somewhat buggy in that  the krb-error does not include a space for padata for the two errors he is talking about so the KDC may not be able to give the client enough information to know what the reply key is.

Nico, sorry I didn't notice that bug after the working group meeting.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:00:36 -0500

> However  his proposal is somewhat buggy in that  the krb-error does not include a space for padata for the two errors he is talking about so the KDC may not be able to give the client enough inform…

Yes, yes. This is why I mentioned before the possible need for a hint in
the Signed{InnerType} of what key is used to key the MAC. I propose an
OPTIONAL Int32 to indicate which key that would be in relation to the
PA-DATA sent in the AS-REQ. Whether that Int32 should be an index into
the PA-DATA or a pre-auth type, I'm not sure yet.

> Nico, sorry I didn't notice that bug after the working group meeting.

That's ok. I noticed last night, though I'd really noticed a week ago...

Remember that thread, where I essentially forgot that your guidelines
were in fact pretty specific about what key to use for signing the
Signed{InnerType}? That was in the message with message id:

<[email-masked]>

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:25:55 -0500

On Tue, Dec 18, 2001 at 11:22:23AM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> 
>     Nicolas> Yes, yes. This is why I mentioned before the possible
>     Nicolas> need for a hint in the Signed{InnerType} of what key is
>     Nicolas> used to key the MAC. I propose an OPTIONAL Int32 to
>     Nicolas> indicate which key that would be in relation to the
>     Nicolas> PA-DATA sent in the AS-REQ. Whether that Int32 should be
>     Nicolas> an index into the PA-DATA or a pre-auth type, I'm not
>     Nicolas> sure yet.
> 
> I don't think that the integer telling you what key to use is such a
> good idea.  You don't have such an integer in an AS-REP and you get
> along fine.  I think if you provide space in the krb-error for the
> padata things will work out.

Ok. That is fair.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 11:22:23 -0500

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Dec 2001 17:18:16 +0100 (MET)

> least is not a new exposure.

I agree for the case when a KDC does not require preauth data that
an attacker can request tickets for arbitrary principals and start
to mount offline dictionary attacks.  Attacking the "signature"
might require slightly less CPU cycles than attacking the
encrypted ticket (because of the random confounder in encrypted blobs).

However there is a significant difference when the KDC requires
preauth data, and I think that any KDC accessible via the internet
should require preauth data ...

> require that the KDC sign in the long-term key, only in the reply-key.

Btw. what is with KRB-ERROR integrity protection when using PKINIT?

-Martin

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 11:53:38 -0500

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

    Martin> However there is a significant difference when the KDC
    Martin> requires preauth data, and I think that any KDC accessible
    Martin> via the internet should require preauth data ...

Agreed, but out of scope for the IETF really.

    Martin> Btw. what is with KRB-ERROR integrity protection when
    Martin> using PKINIT?

Under Nico's proposal pkinit is just another preauth; the KDC could
include the appropriate padata in the the KRB-ERROR, encrypt a reply
key in the public key and use that to sign the krb-error.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:59:21 -0500

> encrypted ticket (because of the random confounder in encrypted blobs).

Is there no random confounder in the keyed MACs? That would be a
problem. Can that be added if missing?

> should require preauth data ...

Amen.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 18 Dec 2001 12:29:10 -0500

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

    Nicolas> Is there no random confounder in the keyed MACs? That
    Nicolas> would be a problem. Can that be added if missing?

Depends for MACs based on crypto systems there is a confounder.
However for MACs based on HMAC and a hash there is no confounder.
Since the confounder would need to be public for such checksum types
it wouldn't add anything.