Subject: more comments on clarifications

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 18 Nov 2002 17:14:06 -0500

Section 1.2 - last paragraph:
    "wether reverse resolution is used."
     ^^^^^^
     whether

1.3 -paragraph 2
    "embedded in a tickets authorization data"
                   ^^^^^^^
                   ticket's

2.5 Proxiable and Proxy tickets
  - There was some discussion a while back as to
  the actual use of proxy tickets.  Does anyone
  know of any implementations that make use of
  proxy tickets?   It seems that their practical use
  is largely theoretical and they are really of very
  limited value.

3.2.2 paragraph 2
      "for user to user authentciation - see section"
                        ^^^^^^^^^^^^^^
                        authentication
3.5.2
   Requiring that the sender's address as reported by the OS
   matches the sender's address in the request will be problematic
   in multi-homed environments as well as the NAT environment
   case mentioned.   Perhaps an additional comment that the
   directional address type should be used in any case where the
   sender's address may not match the address in the message
   would be appropriate.

3.6.1 - last paragraph
   "if the session key is a DES or tripple DES key."
                                   ^^^^^^^
                                   triple

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Nov 2002 19:57:00 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> 2.5 Proxiable and Proxy tickets - There was some
    Wyllys> discussion a while back as to the actual use of proxy
    Wyllys> tickets.  Does anyone know of any implementations that
    Wyllys> make use of proxy tickets?  It seems that their practical
    Wyllys> use is largely theoretical and they are really of very
    Wyllys> limited value.

No, but I think most implementations do support them.  As such I think
they should stay in at this point.

---

From: Ben Cox <[email-masked]>
Date: 19 Nov 2002 08:42:00 -0500

>   is largely theoretical and they are really of very

If I recall correctly (and I freely admit that it's possible that I
don't), the DCE PAC mechanism was based on proxy tickets.

-- Ben

-- 
Ben Cox <[email-masked]>

---

From: Clifford Neuman <[email-masked]>
Date: Tue, 19 Nov 2002 06:18:34 -0800 (PST)

All of the PAC work, both DCE, and the Microsoft Extensions use the
proxy concept.  However the proxy concept does not necessarily require
the the "proxiable" ticket flag be used.

In any event, this flag existed in 1510, and clarifications should not
be changing that - i.e. we shoud leave it.  

Looking back at what we SHOULD have done, we should not have
distingushed between proxiable and forwardable.  The different is
simply that proxiable is like forwardable, but it can not be used to
request a new TGT, only some other service ticket.

Forwardable is clearly used in many places, and the only real issue
there is that forwardable would not be necessary if we did not embed
address restrictions in tickets.

Delegation in Kerberos requires either the use of forwardable tickets,
proxiable tickets, or addressless tickets.

Clifford Neuman

   Mailbox-Line: From [email-masked]  Tue Nov 19 07:42:06 2002
   From: Ben Cox <[email-masked]>
   Cc: ietf-krb-wg <[email-masked]>
   References: <[email-masked]>
   Content-Type: text/plain
   Mime-Version: 1.0
   X-Mailer: Ximian Evolution 1.2.0 
   Date: 19 Nov 2002 08:42:00 -0500
   Content-Transfer-Encoding: 7bit
   Sender: [email-masked]
   Precedence: bulk
   X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
   X-Spam-Level: 

   -- Ben

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 19 Nov 2002 09:52:00 -0600

>   sender's address may not match the address in the message

[FWIW, I don't think the following affects the clarifications
 document.]

Actually using directional addresses is tougher than it seems for
existing applications.  Existing APIs allow applications to specify
(for krb5_mk_priv) for none, one, or both of the sender and local
addresses be checked.  If addresses are specified, the application
must somehow know what address type to use.  This is generally not a
problem for the IPv4/IPv6 case, as operating system interfaces may be
used to determine the appropriate addresss type.  But in order to use
directional addressses, the recipient must know in advance that the
sender will be using directional addresses.

Take the change/set-password protocol as an example.  The change/set
password server cannot specify directional addresses (with existing
APIs), since the requests it will receive (from existing clients) will
contain IP addresses.  There are some solutions for this case:

   - Bump the change/set-password protocol version.  Version 2 will use
     network addresses.  Version 3 will use directional addresses.
     Everything else stays the same.  The change/set-password server
     could then look at the protocol version to determine what type of
     addresses to use with krb5_rd_priv.  (Or maybe version 3 includes
     an additional hint field accomplishing the same thing.)

   - Never check addresses.  (This seems to be the easiest thing to do
     at this time.)

   - Extend the API so that applications can specify more than one
     set of addresses that would be acceptable in krb5_rd_priv (and
     rd_safe).

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 10:55:44 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    Jacques>    - Never check addresses.  (This seems to be the
    Jacques> easiest thing to do at this time.)

But a violation of the spec.  ANd it is important that this be a
violation of the spec because of reflection attacks.

    Jacques>    - Extend the API so that applications can specify more
    Jacques> than one set of addresses that would be acceptable in
    Jacques> krb5_rd_priv (and rd_safe).

MIT at least will extend the API or at least address comparison functions.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Nov 2002 10:19:35 -0600

> sender will be using directional addresses.

KRB-PRIV/SAFE/CRED always require a sender address (KRB-CRED is sortof
exempted).

We need some rules for how to handle the introduction of the directional
address type.  Just because one party to a Kerberos exchange supports it
doesn't mean that the other does.  Perhaps, no definitely we should have
a new error; KRB_AP_ERR_BADADDR is the most appropriate error that we
have, but it's not appropriate as we need to distinguish "unsupported
addr type" from "dude, someone's playing games with your packets" (did I
miss a more appropriate error?).  In any case, rfc1510 should have
defined such an error but didn't, probably because one would never
expect an implementation to use an address type that is not consistent
with the actual network address type in use.

Perhaps, for protocols which start out synchronously the first
KRB-PRIV/SAFE sender should set the address type (i.e., a sender using
IPv6 should cause the other side to use IPv6, even if it supports
directional).

Finally, authorization data could be used to negotiate address types.
I.e., a client could put in the authz-data field of its AP-REQ's
authenticator a critical element indicating it wishes to use directional -
if the peer returns an error then the client can cache the result and
use an address type consistent with the network address types in actual
use.

Cheers,

Nico

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 19 Nov 2002 12:12:43 -0600

> violation of the spec because of reflection attacks.

*nod*  But the context was change/set-password, and the (expired)
draft for that protocol says,

``
      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
           ... elided ...
                   r-address[5]              HostAddress OPTIONAL
                                                        -- recip's addr
      }
''

and

``The recipient should ignore the sender address field in the KRB-PRIV
   message.''

which is effectively ``don't check addresses''.
(Somewhere else ISTR it being suggested that r-address not be filled in.)

> MIT at least will extend the API or at least address comparison functions.

OK, so that will be the solution moving forward and that is fine by me.
I assume such discussion will take place on [email-masked]?

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 13:20:24 -0500

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

    Nicolas> On Tue, Nov 19, 2002 at 09:52:00AM -0600, Jacques
    Nicolas> A. Vidrine wrote:
    >> Actually using directional addresses is tougher than it seems
    >> for existing applications.  Existing APIs allow applications to
    >> specify (for krb5_mk_priv) for none, one, or both of the sender
    >> and local addresses be checked.  If addresses are specified,
    >> the application must somehow know what address type to use.
    >> This is generally not a problem for the IPv4/IPv6 case, as
    >> operating system interfaces may be used to determine the
    >> appropriate addresss type.  But in order to use directional
    >> addressses, the recipient must know in advance that the sender
    >> will be using directional addresses.

    Nicolas> KRB-PRIV/SAFE/CRED always require a sender address
    Nicolas> (KRB-CRED is sortof exempted).

    Nicolas> We need some rules for how to handle the introduction of
    Nicolas> the directional address type.  Just because one party to
    Nicolas> a Kerberos exchange supports it doesn't mean that the
    Nicolas> other does.  

The rule is simple and already stated: you need to know that both
sides support this.  IN practice you only know this for new
application protocols.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 13:41:53 -0500

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

    Nicolas> Would defining an AD type for negotiating directional
    Nicolas> address type use be out of the question at this time?

Yes, because under clarifications you have no way for the server to
respond to this AD type.

Certainly not an AD type to be included in the core document; if you
can make another document that is useful then by all means do so.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Nov 2002 12:38:33 -0600

> sides support this.  IN practice you only know this for new

This is quite limiting.

Would defining an AD type for negotiating directional address type use
be out of the question at this time?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Nov 2002 12:54:14 -0600

> Yes, because under clarifications you have no way for the server to

There isn't?  There's no error with which to respond to unsupported,
critical authorization data?

Yes, indeed.  Well, then one must be added.  What is the point of having
authorization data in the authenticator, and have it be critical if the
receipient has no error code with which to indicate lack of support for
unsupported AD types??

> can make another document that is useful then by all means do so.

Alright, but see above.

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 19 Nov 2002 12:47:51 -0600

> be out of the question at this time?

I don't think there is anything that needs fixing at the protocol level.
It is a matter of setting the expectations of message recipients.
Today it is a limitation of the API that expectations can only be:
``I'm not going to check the (sender|recipient) address.''   OR
``I expect address type FOO value BAR for the (sender|recipient) address.''

If applications can set more flexible expectations, then I don't think
there is a problem.
``I expect either address type FOO value BAR, or address type BAZ value
  BUZ, ... for the (sender|recipient) address.''

Cheers,