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

[Srinivas Cheruku]

    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. 

[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> 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.

[Srinivas Cheruku] yes, make sense.

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

[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.

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.

[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