Subject: [Ietf-krb-wg] gnuftp.raeburn.org

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2011 17:32:28 -0500

I'm working on the referrals draft.
One of the corner cases we spent a lot of time on is gnuftp.raeburn.org.
The idea is that someone wants to create a local alias  for a remote
service.
So, for example, in his local namespace, Ken creates an alias
gnuftp.raeburn.org for ftp.gnu.org.
The gnu.org folks don't know about this alias.

When you ask the raeburn.org KDC for
host/[email-masked], it needs to give you a referral to
the gnu.org domain. However, it also  needs to convince the client to
change the principal name.

It's really important that you cache this under the principal name you
asked for, not what you get back, otherwise you could open up some
significant attacks.

I have one process question: should we specify this.  I think we should
do so if someone's going to implement it.  I believe I can justify
implementing a client if someone will implement KDC support. If it
happens that no one is willing to step forward and say they will
implement a KDC, then I don't think we should specify this.  If the KDC
support that is implemented is for MIT Kerberos, we can even get this
shipped.  If it is not, then the MIT Kerberos core team would need to
evaluate the testing implications.

If we do specify the behavior, where should the information be returned?
I can see two options

1) enc_padata 

2) padata requiring FAST.

Option 1 is relatively easy, but if we're going to go that route I think
we should make a rule for when enc_padata is used vs when normal padata
is used.

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

---

From: Greg Hudson <[email-masked]>
Date: Thu, 17 Feb 2011 18:24:59 -0500

On Wed, 2011-02-02 at 17:32 -0500, Sam Hartman wrote:
> implement a KDC, then I don't think we should specify this.

I agree, in the sense that it adds complexity, which we already have too
much of, and I'm not currently aware of cases where the lack of this
functionality would be a major blocker to reducing DNS reliance.

If that awareness changes, I don't think anything stops us from
specifying this functionality in a later standard.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Feb 2011 18:41:13 -0500

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Wed, 2011-02-02 at 17:32 -0500, Sam Hartman wrote:
    >> I have one process question: should we specify this.  I think we
    >> should do so if someone's going to implement it.  I believe I can
    >> justify implementing a client if someone will implement KDC
    >> support. If it happens that no one is willing to step forward and
    >> say they will implement a KDC, then I don't think we should
    >> specify this.

    Greg> I agree, in the sense that it adds complexity, which we
    Greg> already have too much of, and I'm not currently aware of cases
    Greg> where the lack of this functionality would be a major blocker
    Greg> to reducing DNS reliance.

FYI, I didn't see anyone step forward and say they planned to implement.
So, in the preliminary draft 12 I circulated, I had removed this option.

I have not seen comments on that draft and guess I should do the
editorial pass I spoke of and post it as an an actual I-D.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg