Subject: Dropping krb_priv and krb_safe in extensions

From: [email-masked] (Sam Hartman)
Date: Tue, 6 Jul 2004 14:24:01 -0400 (EDT)

I was thinking about extensions and wondering whether we believe that
it is desirable to continue to have krb_priv and krb_safe message
formats.  The conclusion I came to is that I can't think of a way of
getting rid of them, but I don't really like them.  The krb_priv and
krb_safe message formats don't really add anything to GSSAPI; it is a
redundant feature set.  The current GSSAPI formats are not ASN.1 based
and thus have more predictable lengths.  It is probably easier to
implement them in hardware.  If we design a counter mode AES correctly
it will clearly be easier to implement GSSAPI context tokens in
hardware than Kerberos messages.

However using raw Kerberos messages does give you some flexibility you
don't have with GSSAPI.  You can send arbitrary krb_cred messages at
any point in time; you can use features of ap_reqs not exposed through
GSSAPI; and with most implementation you get finer grain control over
what is sent.

However I think we're stuck with the raw Kerberos messages for two
reasons.  First, some protocols do actually use krb_priv.  Second, I
can't think of a good way of getting rid of the krb_priv and krb_safe
messages.  I don't consider it acceptable to require all applications
to use gss_init_sec_context to set up a Kerberos context.  Especially
as we define ap_req extensions, that's simply not the right interface
for everything someone might want to do.  So it seems like you'd need
to have some way to construct a gss context given a Kerberos context.

Perhaps these ramblings will encourage someone to come up with a good
solution to the problem.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 06 Jul 2004 15:26:31 -0400

>getting rid of them, but I don't really like them.

What specifically don't you like about krb_{priv,safe}?

- People should be using GSSAPI message formats
- The API is a pain
- They're too heavyweight for most users
- Something else
- Some combination of the above

(I have no particular love for these message formats either, but my
dislikes are probably different than yours).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Jul 2004 16:13:33 -0400

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    >> I was thinking about extensions and wondering whether we
    >> believe that it is desirable to continue to have krb_priv and
    >> krb_safe message formats.  The conclusion I came to is that I
    >> can't think of a way of getting rid of them, but I don't really
    >> like them.

    Ken> What specifically don't you like about krb_{priv,safe}?

They are an additional message format that is less clean than the
GSSAPI message formats for hardware acceleration and other purposes
and gives us no additional functionality.  Krb_safe is particularly
bad because of the few people who implement it, at least one
implementation does not follow the spec at all.  Also, GSS provides
gss_getmic which you cannot do with Kerberos.

--Sam

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 06 Jul 2004 16:29:37 -0400

>gss_getmic which you cannot do with Kerberos.

I'm not arguing your first couple of points, but regarding gss_getmic()
... it at least seems you can do that with some of the [KCRYPTO]
operations (like, specifically, the get_mic() [KCRYPTO] operation).
Okay, GSS_GetMIC() has a sequence number in there, so there's no
corresponding Kerberos message format, you'd have to construct one
yourself ... but in my mind, "it's possible, but it's complicated and
is probably not a good idea" is very different than "it's not possible".

--Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 06 Jul 2004 16:58:35 -0400

There are several reasons why I expect KRB_SAFE and KRB_PRIV to not go away.
The first one being that there are existing protocols which implement 
them.  The enumeration
of which we are unable to specify.  As such any attempt to remove the 
functionality from the
Kerberos 5 library would cause an unknown quantity of angst for 
administrators of applications
that rely on them.  They will only know that the functions are gone when 
they attempt to
install the applications on a new OS version which contains a krb5 
library that does not provide
them.

The second reason is that there is not a one to one correspondence 
between GSS and Kerberos
functionality.  The feature sets are slightly different and it is 
conceivable that one would in the
future need access to additional features of Kerberos which are not 
accessible through the GSS
interface.  We could of course add more private extensions to GSS to 
export the additional
functionality but would that really be a good idea?  GSS is supposed to 
provide for portability
between authentication mechanisms.

I am only going to say the following for the purpose of saying it.  I 
don't necessarily support
the idea, but perhaps apps which need to be more Kerberos dependent 
should not use GSS
and Kerberos could provide a new API which makes its additional 
functionality accessible using
wire message formats which are GSS compatible.

- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Jul 2004 17:47:56 -0400

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    Ken> I'm not arguing your first couple of points, but regarding
    Ken> gss_getmic() ... it at least seems you can do that with some
    Ken> of the [KCRYPTO] operations (like, specifically, the
    Ken> get_mic() [KCRYPTO] operation).  Okay, GSS_GetMIC() has a
    Ken> sequence number in there, so there's no corresponding
    Ken> Kerberos message format, you'd have to construct one yourself
    Ken> ... but in my mind, "it's possible, but it's complicated and
    Ken> is probably not a good idea" is very different than "it's not
    Ken> possible".

But kcrypto is neither krb_safe nor krb_priv.  You cannot do getmic
with the combination of krb_priv or krb_safe.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Jul 2004 17:55:35 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> There are several reasons why I expect KRB_SAFE and
    Jeffrey> KRB_PRIV to not go away.  The first one being that there
    Jeffrey> are existing protocols which implement them.  The
    Jeffrey> enumeration of which we are unable to specify.  As such
    Jeffrey> any attempt to remove the functionality from the Kerberos
    Jeffrey> 5 library would cause an unknown quantity of angst for
    Jeffrey> administrators of applications that rely on them.  They
    Jeffrey> will only know that the functions are gone when they
    Jeffrey> attempt to install the applications on a new OS version
    Jeffrey> which contains a krb5 library that does not provide them.

O clearly a library needing to implement clarifications would need to
implement krb_priv.  I'm less convinced about krb_safe.

    Jeffrey> The second reason is that there is not a one to one
    Jeffrey> correspondence between GSS and Kerberos functionality.
    Jeffrey> The feature sets are slightly different and it is
    Jeffrey> conceivable that one would in the future need access to
    Jeffrey> additional features of Kerberos which are not accessible
    Jeffrey> through the GSS interface.  We could of course add more
    Jeffrey> private extensions to GSS to export the additional
    Jeffrey> functionality but would that really be a good idea?  GSS
    Jeffrey> is supposed to provide for portability between
    Jeffrey> authentication mechanisms.

It seems to me that GSS has two main groups of consumers.  One group
uses GSS for portability between security mechanisms.  But there are
applications and even protocols that use krb5 GSS; they would not work
with an arbitrary GSS mechanism.

Why exactly are krb5-specific mechanism extensions a bad idea?

    Jeffrey> I am only going to say the following for the purpose of
    Jeffrey> saying it.  I don't necessarily support the idea, but
    Jeffrey> perhaps apps which need to be more Kerberos dependent
    Jeffrey> should not use GSS and Kerberos could provide a new API
    Jeffrey> which makes its additional functionality accessible using
    Jeffrey> wire message formats which are GSS compatible.

This is also worth considering.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Jul 2004 22:58:10 -0500

> wire message formats which are GSS compatible.

And, pray tell, what is the difference between this and
mechanism-specific extensions to the GSS-API?  :)

We have to keep KRB_SAFE/PRIV for historical reasons.  Oh well, and
that's that.  Let's just not extend them though.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Jul 2004 23:14:36 -0500

> with an arbitrary GSS mechanism.

Do you have any examples?

Neither ONC RPC w/ RPCSEC_GSS apps (e.g., NFS, kadmin[*]), nor ONC RPC
w/ AUTH_GSSAPI (kadmin[*]), nor HTTP Negotiate, nor SSHv2, nor GSS-TSIG,
nor the expired IKEv1 w/ GSS draft, nor a proposal I made in passing for
IKEv2 w/ GSS, are mechanism specific.

[*]  No, kadmin is not really required to use the krb5 mech.  In fact,
     kadmin implementations don't need any mech-specific interfaces, and
     the only one that would really matter to them, relating to ticket
     INITIAL-ness, is typically avoided through the use of a flag in the
     KDB for the kadmin service principal(s).  And a generic interface
     to deal with this could, perhaps, be designed -- we could try.

> Why exactly are krb5-specific mechanism extensions a bad idea?

They aren't.  I just want them to work, where it makes sense, through
stackable mechanisms, but it won't always make sense -- depends on the
particular mechanism stack.  One possible answer is that this can't be
achieved, that mech-specific extensions will have to be re-specified for
any composed mechanisms where it makes sense for them to show through.

This is a reference to the ongoing shim/ioctl debate.

> This is also worth considering.

Six of one, half a dozen of the other.  I'd rather go with mech-specific
extensions to the GSS-API; at least the GSS-API part is specified, which
is much more than can be said about a krb5 API.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 6 Jul 2004 23:38:25 -0500

On Wed, Jul 07, 2004 at 12:37:14AM -0400, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> The distinction is one of expectations.   The GSS API is meant to be 
> portable.  Therefore
> when developers use it they assume they can move from one implementation 
> to another
> and from one authentication method to another without difficulty.
> 
> The KRB5 API is not portable.  It doesn't have the same set of 
> expectations.  Therefore,
> when developers use it they know to expect a high degree of lock in.

The krb5 API is non-standard, non-portable.

Go with mech-specific extensions please.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 07 Jul 2004 00:37:14 -0400

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 07 Jul 2004 10:58:56 -0400

>with the combination of krb_priv or krb_safe.

I thought you said, "You cannot do getmic with Kerberos at all", not
"you cannot do getmic with krb_priv or krb_safe".  The latter, yes, no
question.  Maybe it's more a question of semantics, and isn't worth
arguing about.

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2004 13:33:12 -0400

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

    Nicolas> On Tue, Jul 06, 2004 at 05:55:35PM -0400, Sam Hartman
    >>  It seems to me that GSS has two main groups of consumers.  One
    >> group uses GSS for portability between security mechanisms.
    >> But there are applications and even protocols that use krb5
    >> GSS; they would not work with an arbitrary GSS mechanism.

    Nicolas> Do you have any examples?

Despite what you say, HTTP negotiate has round-trip issues as does the
IKEV1 proposal.  I doubt Microsoft's implementation of http negotiate
would work with anything besides Kerberos or NTLM and the protocol
runs into problems with multi-round-trip mechanisms.

I'm aware of protocols that expect to be able to use krb5 name types,
expect to be able to learn information from krb5 tickets or are in
other ways krb5-specific.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2004 14:54:37 -0400

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

    Nicolas> The krb5 API is non-standard, non-portable.

    Nicolas> Go with mech-specific extensions please.

You realize that one of the extensions we'll need in this case is a
way to get from a krb5_auth_context to a gss contxet.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Jul 2004 11:54:11 -0500

> way to get from a krb5_auth_context to a gss contxet.

Or extensions that use it under the covers, yes.  So?

I have figured out how to deal with mech-specific extensions in a
mechglue, so I am now comfortable with such extensions.

Nico
--

---

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 12 Jul 2004 15:40:07 -0400

>runs into problems with multi-round-trip mechanisms.

Even with Kerberos, the HTTP Negotiate implementation in IIS ignores
the extra exchanges when mutual-auth is enabled.   HTTP is
simply not designed for multiple-round-trip authentication exchanges and/or
the HTTP-Negotiate method was poorly conceived and implemented. 
Either way, its water under the bridge at this point, we are stuck
with both.

-Wyllys

---

From: "D. R. Evans" <[email-masked]>
Date: Wed, 21 Jul 2004 08:56:02 -0600

Sam Hartman said the following at 07/06/2004 03:55 PM:-

> implement krb_priv.  I'm less convinced about krb_safe.

PacketCable uses KRB_SAFE.

   Doc

PS I have been travelling and am now trying to catch up on my several 
thousand e-mails :-(

-- 

-----------------------------------------------------------
Office: +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jul 2004 10:44:17 -0400

>>>>> "D" == D R Evans <[email-masked]> writes:

    D> Sam Hartman said the following at 07/06/2004 03:55 PM:-
    >> implement krb_priv.  I'm less convinced about krb_safe.

    D> PacketCable uses KRB_SAFE.
so?  Do you believe that transitioning to some other message format is
going to be any worse than the changes already involved in extensions?