Subject: [Ietf-krb-wg] FAST and optional outer request

From: Sam Hartman <[email-masked]>
Date: Thu, 21 May 2009 07:39:00 -0400

In his message
https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007614.html ,
Love proposed making the outer request optional.

I don't support that proposal because I think it would make interop
more challenging.  The only gain I see is saving a few bytes of
network traffic.

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 21 May 2009 10:50:39 -0700

> more challenging.  The only gain I see is saving a few bytes of

Its a security problem since there are pre-auth types using the  
information, and if its anonymous, its not binding pre-auth data to  
the request.

Love

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 May 2009 14:29:16 -0400

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

    Love> 21 maj 2009 kl. 04:39 skrev Sam Hartman:

    >> 
    >> 
    >> In his message
    >> https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007614.html
    >> , Love proposed making the outer request optional.
    >> 
    >> I don't support that proposal because I think it would make
    >> interop more challenging.  The only gain I see is saving a few
    >> bytes of network traffic.

    Love> Its a security problem since there are pre-auth types using
    Love> the information, and if its anonymous, its not binding
    Love> pre-auth data to the request.

I'm sorry.  I don't see how making the outer request optional helps or
hurts the security problem.  I do believe that there is a security
issue, and I've describe what I think it is in a longer other message.
However I don't see how this has to do with whether there is an outer
request--only with what request you bind to.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 21 May 2009 11:32:26 -0700

> request--only with what request you bind to.

If its not there, you can't bind to it. and the binding will fail.

Love

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 May 2009 14:53:25 -0400

Love> 21 maj 2009 kl. 11:29 skrev Sam Hartman:

Love>If its not there, you can't bind to it. and the binding will fail.

I think if we want to change the binding, we should change the
binding.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 27 May 2009 02:36:17 -0400

On Thu, 2009-05-21 at 07:39 -0400, Sam Hartman wrote:
> [...] Love proposed making the outer request optional.
> 

As an implementor, I am not keen on making this change at this date (or
even at an earlier date, given the changes it would require to KDC
request processing), and I do not see any strong advantage to it.  We
can solve the binding issue without such major surgery.

On the other hand, from an academic perspective, I'm not sure how having
the vestigial outer body there makes interop any easier.  A client using
FAST will generally not choose to interoperate with a KDC who doesn't
understand FAST; for instance, your implementation against the
ATHENA.MIT.EDU KDC produces:

equal-rites$ /me/pk/bin/kinit -T /tmp/acred ghudson
kinit: FAST protected pre-authentication required but not supported by
KDC while decrypting FAST reply while getting initial credentials

I guess you get a better error message than you might get if the KDC
barfed on the request instead of processing it, so that's a small
advantage.

Perhaps after encrypted padata
(https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html) is
in play, the outer body will be more useful for ensuring
interoperability, but I haven't thought that through.