Subject: [Ietf-krb-wg] framework-12 comments

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 10 Jun 2009 07:10:46 -0700

-12 contains the following comment

    o  Whether the contents of the KDC reply can be verified by the
       client principal

I find "client principal" to be unclear. How can "[email-masked]" or lha  
verify the reply.

Maybe the client implementation can verify the reply using external  
configuration, is that "client principal" ?

Love

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jun 2009 16:30:24 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> -12 contains the following comment o Whether the contents of
    Love> the KDC reply can be verified by the client principal

    Love> I find "client principal" to be unclear. How can
    Love> "[email-masked]" or lha verify the reply.

    Love> Maybe the client implementation can verify the reply using
    Love> external configuration, is that "client principal" ?

The intent here is to discuss whether the entity named by the client
kerberos principal can verify the reply.

The client host often cannot verify the reply because the client host
does not know whether the KDC is being spoofed without an ap-req
exchange.

However the client principal--you for example--know that you are not
spoofing the KDC.  That plus the party on the other end knowing the
right long-term key is sufficient for you to verify the KDC reply.

Often we use client principal as a shorthand for the name of the
client principal.  I'm not using it that way.  I'd be happy if you'd
like to suggest more clear text.
Would "entity named by the client principal" be more clear?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 10 Jun 2009 13:34:56 -0700

> does not know whether the KDC is being spoofed without an ap-req

The client can verify the the reply if the KDC have a fast preauth  
type using public key crypto and configuration on client. Talking  
about the "client principal" make no sense in this case.

The flag is if the reply is verfied, so remove everything about client  
principal and just say "reply verfied" ?

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jun 2009 16:52:52 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:
    Love> The client can verify the the reply if the KDC have a fast
    Love> preauth type using public key crypto and configuration on
    Love> client. Talking about the "client principal" make no sense
    Love> in this case.

True, but not what this flag is about.

    Love> The flag is if the reply is verfied, so remove everything
    Love> about client principal and just say "reply verfied" ?

I think that would make things ambiguous.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 10 Jun 2009 14:33:26 -0700

> True, but not what this flag is about.

Then I don't understand what the flag is all about and why we need it.

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Jun 2009 17:42:14 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> Then I don't understand what the flag is all about and why
    Love> we need it.

OK.  Kerberos today gives a weak form of KDC verification.  It's
notthird-party verifyable.  However, if you know the client password
and no one is spoofing the KDC, you can get this level of verification
by being able to decrypt the as-rep.

This flag tracks whether you have at least that confidence in the KDC reply.

Examples of things that clear this flag: anonymous pkinit.  Examples
of things that set this flag: using the long-term key for something;
signing the reply with a digital signature.

This flag needs to be distinguished from a stronger form of KDC
verification that might also be provided.  A mechanism might prove the
KDC identity to the client implementation independent of concerns
about spoofing.  Examples include an ap-req or signing the KDC reply.
The pre-auth framework does not care about this stronger form of KDC
verification,but needs to be clear in what is' providing.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 10 Jun 2009 18:57:34 -0700

> verification,but needs to be clear in what is' providing.

So since this is a generic code path, the stronger form result in what  
flag been set ?

And how does later code determine is a stronger method have been used,  
for example, anon-anon-dh + signed reply ?

Love

---

From: Larry Zhu <[email-masked]>
Date: Thu, 11 Jun 2009 03:08:08 +0000

Perhaps it is less ambiguous to say "Whether the origin of the KDC reply can be verified by the client principal"?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Love Hörnquist Åstrand
Sent: Wednesday, June 10, 2009 6:58 PM
To: Sam Hartman
Cc: Kerberos-wg -
Subject: Re: [Ietf-krb-wg] framework-12 comments

Love

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Jun 2009 17:22:58 -0400

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

    Larry> Perhaps it is less ambiguous to say "Whether the origin of
    Larry> the KDC reply can be verified by the client principal"?

If that makes someone happier
I'd be happy to make the change.

I don't think Love and I are managing to understand each other enough
for me to respond to his concern affectively.  We seem to be talking
past each other.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Thu, 11 Jun 2009 22:01:23 +0000

If the proposed change addresses Love's concerns, then please proceed to make the change.

--Larry

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 11 Jun 2009 15:16:20 -0700

I still don't understand why this is a FAST state flag.

Will we have a replay verified by PK-INIT flag too ?

How about a verified by FAST preauth type-17 flag ?

Love

---

From: Larry Zhu <[email-masked]>
Date: Thu, 11 Jun 2009 22:58:49 +0000

Whether the identity of KDC is authenticated is one of the most critical elements in the design of any pre-authentication method. And this flag is to indicate whether the KDC is authenticated.

The abstract data model described here should not have anything specific to a specific pre-auth method therefore we do not have any state to track for PKINIT.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Love Hörnquist Åstrand
Sent: Thursday, June 11, 2009 3:16 PM
To: Larry Zhu
Cc: Kerberos-wg -; Sam Hartman
Subject: Re: [Ietf-krb-wg] framework-12 comments

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 11 Jun 2009 16:05:04 -0700

So that the confusing part.

The flag is not about the specific "authenticated by KDC knows user's  
keys"

Its "authenticated reply, which is authentication done by equivalent  
to KDC user's keys, OR BETTER"

As written today, it looks like it specific to  "authenticated by KDC  
knows user's keys", ie mech specific. So a pk-based auth mech that  
have better knowledge about the reply should not set the flag ?

Also, I have trouble to see where in the process this flag should be  
verified.

Love

11 jun 2009 kl. 15:58 skrev Larry Zhu:

> Whether the identity of KDC is authenticated is one of the most  
> critical elements in the design of any pre-authentication method.  
> And this flag is to indicate whether the KDC is authenticated.
>
> The abstract data model described here should not have anything  
> specific to a specific pre-auth method therefore we do not have any  
> state to track for PKINIT.
>
> --Larry
>
> From: [email-masked] [mailto:ietf-krb-wg- 
> [email-masked]] On Behalf Of Love Hörnquist Åstrand

---

From: Larry Zhu <[email-masked]>
Date: Thu, 11 Jun 2009 23:09:41 +0000

I see your points. Maybe we should say "Whether the origin of the KDC reply can be verified by the Kerberos client"? This way it does not hint to use what the client principal has (i.e. the user keys).

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:[email-masked]]
Sent: Thursday, June 11, 2009 4:05 PM
To: Larry Zhu
Cc: Kerberos-wg -; Sam Hartman
Subject: Re: [Ietf-krb-wg] framework-12 comments

Love

---

From: Larry Zhu <[email-masked]>
Date: Fri, 12 Jun 2009 00:34:21 +0000

'Love Hörnquist Åstrand' wrote:
> Also, I have trouble to see where in the process this flag should be verified.

Just to clarify that where and how this flag is verified would be mechanism specific.

--Larry

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:[email-masked]]
Sent: Thursday, June 11, 2009 4:05 PM
To: Larry Zhu
Cc: Kerberos-wg -; Sam Hartman
Subject: Re: [Ietf-krb-wg] framework-12 comments

Love

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Jun 2009 06:27:07 -0400

>> Also, I have trouble to see where in the process this flag

    Larry> Just to clarify that where and how this flag is verified
    Larry> would be mechanism specific.

Well, I'd think implementation specific.

First, note that this basically only comes up with anonymous pkinit
for FAST armor and authentication sets with mechanisms not yet
defined.

So, I'd have a flag on the mechanism.  If the mechanism replaces the
reply key and does not verify the KDC, then I would not offer that
mechanism with FAST using anonymous principals for armor.  (Offering
the mechanism outside of FAST would be even worse)

If I added authentication set support, then I'd do the following:

1) Have a flag tracking replace reply key and KDC verification on the mechanism.  Never offer an authentication set that has replace reply key and not KDC verify.

2) Keep track of reply key replacements and KDC verifications in my KDC and client.  If I'm about to issue a ticket and I've replaced the reply key but not verified the KDC, issue an error instead and get grumpy at the admin.

3) If the client receives a ticket with a replaced reply key but not
KDC verified then generate an error.  However this is just one
implementation strategy.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Jun 2009 06:28:16 -0400

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

    Larry> I see your points. Maybe we should say "Whether the origin
    Larry> of the KDC reply can be verified by the Kerberos client"?
    Larry> This way it does not hint to use what the client principal
    Larry> has (i.e. the user keys).  -----Original Message----- From:

I agree that this change adds clarity.

---

From: Larry Zhu <[email-masked]>
Date: Fri, 12 Jun 2009 17:14:48 +0000

I would like to add that this KDC verification flag is described in the context outside of FAST in the current document. Since fast provides KDC verification in most cases, I suspect that was why it confuses the reader why the flag is needed at all.

You brought up the cases where FAST does not provide KDC verification itself, and in those cases, I agree how to mark the KDC verification flag would be implementation specific. Perhaps we can merge the text you provide as an implementation note in the next revision if the working group thinks it is helpful to do so.

--Larry

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Jun 2009 13:39:26 -0400

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

    Larry> I would like to add that this KDC verification flag is
    Larry> described in the context outside of FAST in the current
    Larry> document. Since fast provides KDC verification in most
    Larry> cases, I suspect that was why it confuses the reader why
    Larry> the flag is needed at all.  You brought up the cases where
    Larry> FAST does not provide KDC verification itself, and in those
    Larry> cases, I agree how to mark the KDC verification flag would
    Larry> be implementation specific. Perhaps we can merge the text
    Larry> you provide as an implementation note in the next revision
    Larry> if the working group thinks it is helpful to do so.

My personal preference is not to get into that level of implementation
detail.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg