Subject: Re: [Ietf-krb-wg] fast and patypes in KRB-ERROR

From: Sam Hartman <[email-masked]>
Date: Thu, 14 May 2009 19:46:11 -0400

[I think these points need to be considered in a broader context than just the MIT implementation.
I think I've included enough context.]

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used.  I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC

    Srinivas> 2.  KDC replies with KRB-ERROR containing the above
    Srinivas> pa-types along with PA-ENCRYPTED-CHALLENGE (for user
    Srinivas> principals having pre-auth required set)

    Srinivas> 3.  kinit can check for PA-FX-FAST and
    Srinivas> PA-ENCRYPTED-CHALLENGE and send a fast request
    Srinivas> containing pa-enc-challenge padata.

    Srinivas> 4.  KDC sends tgt using FAST on successful
    Srinivas> authentication

    Srinivas> I know that MIT kinit doesn't support this behaviour but
    Srinivas> other vendors can support this.  Any advice or issues
    Srinivas> you foresee?

Probably this is more of an IETF issue than an MIT issue.  My concern
about doing this is that the negotiation of which fast factors are
supported would be unprotected.

Consider a client with the policy: * prefers fast with OTP, but will
fall back to FAST with encrypted challenge.

I think you have a relatively weak password, so it is in my interest
to get you to fall back to encrypted challenge.  I delete OTP from the
initial unprotected error.

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

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 15 May 2009 09:38:45 +0530

used. 

[Srinivas Cheruku] Yes, I understand that cookie is a must when FAST is used
to continue conversation. But why should it be included in a non-fast
initial request to KDC? Does this mean that FAST enabled KDC sends the
cookie always irrespective of the request uses FAST or not? For me, as the
request doesn't use FAST, there is no need of any cookie. 

 I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

[Srinivas Cheruku] ok

[Srinivas Cheruku] yes, make sense.

[Srinivas Cheruku] The client policy and the pre-auth to be used is not an
issue as KDC can send the respective pre-auth type e.g.
PA-ENCRYPTED-CHALLENGE or PA-OTP-CHALLENGE based on the client policy along
with PA-FX-FAST. But, I agree that the pre-auth negotiation with fast
factors would be unprotected.

[Srinivas Cheruku] I think you meant if a eavesdropper changes the OTP
pre-auth in unprotected KRB-ERROR with PA-ENCRYPTED-CHALLENGE? If that is
the case, though enc-challenge is received by KDC it would again ask for OTP
fast factor.

Thanks,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 15 May 2009 12:31:05 +0530

Sam wrote:...
>supported would be unprotected.

[Srinivas Cheruku] I was thinking on this more. 
What affect would it have if the negotiation of fast factors is not
protected? 
When non-fast request is sent to KDC, it returns KRB-ERROR e-data containing
PA-FX-FAST. This is also not protected PA-FX-FAST can also be deleted from
initial unprotected error. If this happens, the client would send non-fast
request containing enc-timestamp instead of generating a fast request. It
depends on the KDC policy to allow non-fast requests or not.

If we take the case of adding PA-ENCRYPTED-CHALLENGE or PA-OTP-CHALLENGE
along with PA-FX-FAST to unprotected error, then if these are deleted in
transit, then client maynot send OTP or ENC-CHALLENGE, but if the KDC is
configured so that the client requires these, then it won't generate the
ticket and would again asks for the same.

So, where do we see a potential risk of sending PA-ENCRYPTED-CHALLENGE or
PA-OTP-CHALLENGE along with PA-FX-FAST in unprotected error. Am I
overlooking something?

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 May 2009 06:45:31 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> Sam wrote:...
    >> Probably this is more of an IETF issue than an MIT issue.  My
    >> concern about doing this is that the negotiation of which fast
    >> factors are supported would be unprotected.

    Srinivas> [Srinivas Cheruku] I was thinking on this more.  What
    Srinivas> affect would it have if the negotiation of fast factors
    Srinivas> is not protected?  When non-fast request is sent to KDC,
    Srinivas> it returns KRB-ERROR e-data containing PA-FX-FAST. This
    Srinivas> is also not protected PA-FX-FAST can also be deleted
    Srinivas> from initial unprotected error. If this happens, the
    Srinivas> client would send non-fast request containing
    Srinivas> enc-timestamp instead of generating a fast request. It
    Srinivas> depends on the KDC policy to allow non-fast requests or
    Srinivas> not.
Larry and I have proposed a mechanism that we can use to protect the
negotiation of FAST itself.

That mechanism could be extended to protect FAST itself, but it is our
proposal to the WG not to involve that complexity.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg