Subject: Directional HostAddress type requirements

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Feb 2003 11:18:17 -0600

Clarifications doesn't state anywhere [that I can find] what are the
requirements for support and use of the Directional HostAddress type.

I propose simply that:

 - all new protocols SHOULD or MUST use it

 - existing protocols MAY or SHOULD or MUST use it in the context of
   session keys of "new" enctypes

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Feb 2003 14:03:25 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Clarifications doesn't state anywhere [that I can find]
    Nicolas> what are the requirements for support and use of the
    Nicolas> Directional HostAddress type.

    Nicolas> I propose simply that:

    Nicolas>  - all new protocols SHOULD or MUST use it

Is this valid use of requirements language?
Wouldn't the right way to accomplish be to require support in new protocol documents?

    Nicolas>  - existing protocols MAY or SHOULD or MUST use it in the
    Nicolas> context of session keys of "new" enctypes

I object to using the session key type as a protocol version number.
Yes we have done it in the MIT release for the BSD applications, but
that doesn't mean it is reasonable for the IETF.

If you want feature negotiation, use extensions.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 Feb 2003 13:16:55 -0600

> Wouldn't the right way to accomplish be to require support in new protocol documents?

Erm, ok, clarifications should recommend that new protocols, whether
they be described in IETF docs or no, use KRB-SAFE/PRIV/CRED use the
directional address type.  Obviously, Kerberos software libraries should
definitely support it as well; perhaps I was conflating the apps and the
libs.

Regardless, shouldn't clarifications should offer something stronger
that a mere description of the directional host address type?

> that doesn't mean it is reasonable for the IETF.

We have just agreed to do the same thing for ETYPE-INFO/ETYPE-INFO2.

> If you want feature negotiation, use extensions.

While I agree that the extensions work is the place to deal with
negotiation of features in general, and while I'm not particularly
attached to the second point in my proposal, I also do not see a good
reason not to this negotiation.

And now for a related question: what should an RFC1964 (GSS krb5 mech)
acceptor do if the client's token includes a KRB-CRED with a directional
host address type?

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Feb 2003 18:22:30 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> We have just agreed to do the same thing for
    Nicolas> ETYPE-INFO/ETYPE-INFO2.

And they are related to enctypes.

    >> If you want feature negotiation, use extensions.

    Nicolas> While I agree that the extensions work is the place to
    Nicolas> deal with negotiation of features in general, and while
    Nicolas> I'm not particularly attached to the second point in my
    Nicolas> proposal, I also do not see a good reason not to this
    Nicolas> negotiation.

I think my main objection is slippery slope I'd like to draw the line
at using known enctypes for enctype related behavior.

    Nicolas> And now for a related question: what should an RFC1964
    Nicolas> (GSS krb5 mech) acceptor do if the client's token
    Nicolas> includes a KRB-CRED with a directional host address type?

If addressless tickets would be accepted, it should accept the
krb_cred message if the address is initiator.