Subject: RFC1964 & AES - sequence number size should be increased

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2003 13:17:24 -0700

RFC1964 has 32-bit sequence numbers.  These should probably be bumped to
64-bit.  And what should happen when sequence numbers wrap around?  (not
just across zero but across the initial sequence number for a context).

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 21 May 2003 18:48:10 -0400

> just across zero but across the initial sequence number for a context).

This isn't specific to AES, and isn't specific to the GSS mechanism
either.

Kerberos (according to Clarifications) uses 32-bit sequence numbers.
We don't address wraparound there either -- nor any recommended
per-cryptosystem limits for amount of data, number of messages, etc,
before rekeying.  (Rekeying?  What's that?)

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 May 2003 20:58:31 -0700

> This isn't specific to AES, and isn't specific to the GSS mechanism

Well, no, it isn't.  But as long as we define the revision of the mech
*not* in terms of Kerberos messages (w/ some extensions - remember the
KRB-SAFE-X discussion?) then we have to think about such things as
sequence numbers for the mech separately from sequence numbers for the
Kerberos messages.  Since the mech revisions are likely to happen before
the Kerberos V extensions I focused my note on the mech.

> before rekeying.  (Rekeying?  What's that?)

Yes, rekeying.

I think the GSS-API could stand minor revision for introducing rekeying,
but enlarging the sequence number space would lessen the need for such a
revision.  Do we have enough material for re-opening CAT?  Well,
probably - but I'll save Sam the trouble and ponder aloud if we have
enough time for CAT :)

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 19:17:53 +0200 (MET DST)

> probably - but I'll save Sam the trouble and ponder aloud if we have

Sorry, but rekeying is impossible inside a GSS-API mechanism,
the architecture doesn't allow it.

The only method (and the one that rfc1964 requires by limiting
the context lifetime) is that the application caller establishes
a new security context, switches from using the old to using
the new synchronized with its communication peer and deletes the
old security context, a fairly complex procedure that requires
provisions in the application's communication protocol
which many applications simply don't offer (Microsoft
apparently goofed this part of SSPI/GSS-API that's why
they backed out the security context expiration which
is *required* by rfc-1964 from their W2K Kerberos before
W2Krc1 after they had activated it for W2Kbeta3 and it
broke each and every of their applications when the
security context expired...)

Rekeying needs a negotiation between two peers,
and a generic GSS-API caller may be doing uni-directional
communication only as soon as the token exchange from
the security context establishment is finished
(like the data connection of an FTP with GSS-API)

-Martin

PS: Designing an application protocol that performs
    GSS-API security context "refresh" becomes quite complex,
    depending on how clever and robust you intend to make it.
    e.g. - what do you do when either side has no (more) access
           to credentials?
         - you need to make sure that the new security context
           authenticates the exact same peers as the original
           (i.e. you might need to request the correct credentials in
            case you have access to more than one)
         - what do you do when security context establishment fails?
           (keep using the original context until it expires?)
         - do you retry security context establishment in case
           credential unavailability or security context establishment
           failures might be a temporary problem?  how often and how fast
           do you retry?
         - what if the new security context lifetime is not longer or
           even shorter than that of the original?  Fortunately the
	   security context lifetime in rfc-1964 Kerberos is derived
           from the credential lifetime (actually the service ticket
           lifetime which is derived from the TGT lifetime), so
           by checking the credential lifetime with a rfc-1964 mechanism
	   one doesn't need to go through security context negotiation
           to find out that the new context will not offer a longer
           lifetime than the original ...
         - When do you refresh a security context? With enforced
           security context expiration as required by rfc-1964 and
           implemented by MIT Kerberos, the security context may
           expire while a protected message is still "in transit",
           be it on the network or in a message queue.  This can
           happen even with perfectly synchronized clocks.
           How good can you predict both the maximum clock skew
           and communication latency between the message protection
           call by peer a and the message unprotection call by peer b?

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 22 May 2003 14:04:14 -0500

> the architecture doesn't allow it.

Not today, but maybe with some extensions to the architecture.

See the http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt
which came out of the GGF, where there is a newer version is due soon:
http://www.ggf.org/documents/Drafts/default.htm

Even if we don't have enought time for CAT, others might. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 May 2003 15:28:09 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Nicolas Williams wrote:
    >>  > Kerberos (according to Clarifications) uses 32-bit sequence
    >> numbers.  > We don't address wraparound there either -- nor any
    >> recommended > per-cryptosystem limits for amount of data,
    >> number of messages, etc, > before rekeying.  (Rekeying?  What's
    >> that?)
    >> 
    >> Yes, rekeying.
    >> 
    >> I think the GSS-API could stand minor revision for introducing
    >> rekeying, but enlarging the sequence number space would lessen
    >> the need for such a revision.  Do we have enough material for
    >> re-opening CAT?  Well, probably - but I'll save Sam the trouble
    >> and ponder aloud if we have enough time for CAT :)

    Martin> Sorry, but rekeying is impossible inside a GSS-API
    Martin> mechanism, the architecture doesn't allow it.

I don't believe this is accurate.  The closest thing I can find is the
requirement that GSSAPI tokens can be processed out of order.

It would be useful if you would explain why you think this is true.

    Martin> The only method (and the one that rfc1964 requires by
    Martin> limiting the context lifetime) is that the application
    Martin> caller establishes a new security context, switches from
    Martin> using the old to using the new synchronized with its
    Martin> communication peer and deletes the old security context, a
    Martin> fairly complex procedure that requires provisions in the
    Martin> application's communication protocol which many
    Martin> applications simply don't offer (Microsoft apparently
    Martin> goofed this part of SSPI/GSS-API that's why they backed
    Martin> out the security context expiration which is *required* by
    Martin> rfc-1964 from their W2K Kerberos before W2Krc1 after they
    Martin> had activated it for W2Kbeta3 and it broke each and every
    Martin> of their applications when the security context
    Martin> expired...)

I think you will see significant pressue to revisit this issue as well
during RFC 1964 revisions.

    Martin> Rekeying needs a negotiation between two peers

Not strictly true.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 13:02:07 -0700

> the architecture doesn't allow it.

Nor did I claim otherwise.  I wrote "the GSS-API could stand minor
revision for introducing rekeying..." and I think that is true, that is,
the GSS-API could be revised to allow for rekeying.

One way would be to have GSS_Get_MIC() and GSS_Wrap() return an error
indicating that a rekey is required and then the existing sec context
could be used in a new gss_init/accept_sec_context() token exchange.

Another way would be to have GSS_Get_MIC() and GSS_Wrap() return
GSS_S_FAILURE and expire the context immediately, thus forcing the app
to setup a new context or terminate the session.

The GSS-API could be revised in such a way without having to revise
existing mechanisms, though also revising those would be a good thing.

> (like the data connection of an FTP with GSS-API)

Clearly, applications and application protocols that use the GSS-API
would have to be modified to support rekeying too, but even when used
with a version of the GSS-API that supports rekeying legacy apps could
fail gracefully.  Graceful failure is the key here.

>     e.g. - what do you do when either side has no (more) access

Rekeying is not the same thing as "refreshing" - I take the latter to be
about refreshing expired sec contexts, and the former about refreshing
expired session keys.  One requires fresh credentials (refreshing), the
other (rekeying) does not.

In any case, applications already have to deal with context expiration.

Also, I don't want the GSS-API extended to support refreshment of
expired contexts thank you - just rekeying.

>             case you have access to more than one)

Again, there's a very clear [to me] distinction between rekeying and
refresshing.

>            (keep using the original context until it expires?)

The same thing you'd do upon context expiration - whatever that might
be.

>            failures might be a temporary problem?  how often and how fast

If credentials are not available then new contexts can't be established.

Again, see the disctinction between...

>            even shorter than that of the original?  Fortunately the

Rekeying would not change context expiration times.  It would only
change session keys.

>            call by peer a and the message unprotection call by peer b?

Contexts in need of rekeying would still be usable to verify MIC tokens
and unwrap wrap tokens - but they could not be used to make new ones.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 15:05:05 -0500

BTW, I did not mean to start a discussion on how to design GSS-API
extensions for rekeying.  I know the GSS-API does not support rekeying
today and believe it could with some revision.  That's it.

Of course, it's important to clarify the distinction between rekeying
security contexts and refreshing expired security contexts, which I just
did.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 22:21:08 +0200 (MET DST)

> Not today, but maybe with some extensions to the architecture.

Nope, I mean it, seriously.

You would have to define something that isn't
backward compatible with existing GSS-API (v2), so it's
far beyond an "extension".

> Even if we don't have enought time for CAT, others might. 

Well, that document is not a GSS-API extension, but a major
redesign.  Unfortunately it is significantly less generic
than the original GSS-API so that hardly anything of the
new stuff can be implemented by about 90% of the GSS-API
mechanisms that I know -- the reason why *I* care little about
this proposal.

The lack of abstraction in the proposal is so significant, that
I seriously doubt that applications could portably use any of
the new functionality (in the sense how GSS-API v2 defines
portable applications).

Personally, I think that several aspects of the proposal are
*extremely* mechanism- or even implementation-specific --
which should better be indicated in the document.

There's nothing wrong when several gssapi mechanisms that
share implementation details, but this should not be confused
with the high level of abstraction present throughout GSS-API v1/2.

Several years ago the SESAME project issued an I-D about
gssapi extensions (mostly about authorization IIRC), but although
these extensions where fairly generic, there wasn't any real interest
outside the SESAME community and so the document authers didn't
even follow through to get the document published as an informational RFC.

The same happened to the GAA extensions (I don't know the current
status of that initiative, i.e. whether it's been adopted anywhere
outside the community that developed it and whether the spec
is still "circulated" in the IETF as I-D or informational RFC).

I wouldn't mind if the GGF gss extensions would be tagged as
the effort of a particular interest group for their subset
of gssapi mechanism and published as an informational RFC,
but I would be violently opposed to see it disguised as
a generic extension on the standards track.

The great thing about GSS-API v1/2 is really that when a gssapi
mechanism supports a particular GSS-API feature at all, then this feature
can ALWAYS be made available at the API, and any years-old
portable(!!) gss-api based application out in the field will
be able to use it as is (i.e. requiring not a single change
to the application code).  We've been doing just that since 1996,
and our list of supported third-party gssapi mechanisms grows
4-5 new entries every year.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 13:46:43 -0700

> far beyond an "extension".

GSS_Get_MIC() and GSS_Unwrap() can return errors.  Introducing a new
error to indicate the need for rekeying would cause existing
applications to fail gracefully (since they have to be prepared to
handle errors now, and they can use gss_display_status() to log/display
error messages that indicate failure-due-to-need-to-rekey).

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 23:02:51 +0200 (MET DST)

Now it seems that we're fighting over terminology rather than
technology/architecture issues.

"Rekeying" means that the crypto-system renegotiates a new session
key and ensures that this is done securely (i.e. that noone
can walk in and replace one of the peers) without the application
getting bothered or even noticing that it happened.  And the
crypto-system controls itself the validity of the keys and
can perfectly synchronize the switch and make sure all messages
protected at one side can still be unprotected on the other
before deleting the old keys (policy permitting).

"Refreshing" a security context means that the crypto-system is
totally unaware that the application is trying to replace an
existing security context that it thinks should be refreshed
or which the gssapi mechanism reported to be expired and no
longer usable.  In the refreshing case, the *application* has
to make sure that the new security context identifies the
exact same identities as the original one, the *application*
has no control about when a security context exactly expires
and may have to deal with protected messages that arrive
on an expired security context, and the *application* has
to deal with changed/unavailable credentials that may
impair the possibility to create a suitable replacement
security context.

In the "refreshing" case the crypto-system has no way to
distinguish whether an application is trying to use several
security context in parallel or whether is trying to "refresh"
a single security context.

In essence, "refreshing" is much more difficult to implement
since the application has no authority over the lifetime of
a security context.

But in order to use rekeying, the crypto-system would require
the ability to enforce negotiation token transport on the
application, which GSS-API only allows for the initial
security context establishment.  Once the security context
has been successfully established, the only thing that a
mechanism can do is returning "GSS_S_CONTEXT_EXPIRED"
from any of the message protection/unprotection calls,
which is really not easy to deal with at the application
level -- you'll find very few applications that will
be able to cope gracefully with this behaviour.

> could be used in a new gss_init/accept_sec_context() token exchange.

Since the GSS-API v2 spec doesn't provide for such strange contortions
none of the existing mechanism and apps can use or implement such behaviour.

> to setup a new context or terminate the session.

That's not rekey but refresh and exactly what I've been claiming
and describing.  There are probably very few applications that
will try to deal gracefully with security context expiration.
My code in our app will attempt security context refresh, and
although it's not perfect, I haven't had complaints from MIT since
I added support for security context refresh to our app in 1996.

> other (rekeying) does not.

Exactly.

> In any case, applications already have to deal with context expiration.

I think that's an illusion ...
probably 99.5% treat it just like any other error code from message
protection calls -- mainly because only Kerberos defines&enforces
security context expiration at the GSS-API, and even here the majority
of the installed base (W2K Kerberos) dropped it because the apps
above it were unable to cope with it.

The whole issue about session key lifetime and security context
refresh was discussed in depth on the CAT-IETF mailing list even before
I joined CAT in 1995.  If there had been a solution for "rekeying",
it would been part of GSS-API v2, but there simply isn't one.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 23:09:40 +0200 (MET DST)

> error messages that indicate failure-due-to-need-to-rekey).

Now what is "fail gracefully" supposed to mean here?

Do you mean that you get an error message visualized before
the application panics and exits?

As I mentioned before, handling fatal GSS_S_CONTEXT_EXPIRED
return codes from message UNprotection calls gss_unwrap() and
gss_verify_mic() "gracefully" (this time in the sense how everybody
else uses this word) might prove quite difficult, since the
contents of the protected message can no longer be recovered
and will have to be re-send by the communication peer protected
under a new security context, which requires an application-level
retransmit queue... happy coding!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 14:22:48 -0700

> technology/architecture issues.

I think you and I are in agreement on the terminology.

> none of the existing mechanism and apps can use or implement such behaviour.

Sure they can, if updated - if not they should fail gracefully.

> will try to deal gracefully with security context expiration.

Yes.

> > other (rekeying) does not.

See?  No disagreement on terminology :)

> above it were unable to cope with it.

Er, NFS (v2, v3 and v4) w/ RPCSEC_GSS handle context expiration
correctly.  It can be done.

For less sophisticated apps quitting is a perfectly valid strategy for
dealing with context expiration (perhaps not acceptable to some users,
but still valid).

Also, GSS-APIvn features could be negotiated between the application and
the GSS-API layer.

> it would been part of GSS-API v2, but there simply isn't one.

I believe something can be done, as long as v2 apps fail gracefully and
v2 mechs are either not updated to support rekeying or they are updated
to support vN features _and_ negotiation thereof feature (both, the
initiator and acceptor applications would have to indicate support for
vN features for the updated mechs to negotiate their use).

In the case of rekeying I do believe that applications can fail
gracefully.  So I believe it can be done - that others didn't 8 years
ago does not sway me.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 23:31:58 +0200 (MET DST)

> requirement that GSSAPI tokens can be processed out of order.

Where did you read that -- it definitely doesn't apply to GSS-API.

Context establishment token can ONLY be processed in order.
Whether message protection tokens (wrapped app data or MIC tokens)
can be processed our of order is (a) implementation dependent and
(b) dependent on the security context flags/features SEQUENCE and REPLAY.

A mechanism implementation may enforce either or both SEQUENCE or REPLAY
protection on messages, whether the application wants this or not.

Some gssapi mechanism don't implement SEQUENCE or REPLAY protection at all,
and for those it might be possible to process protected message successfully
out of order.  However I won't count on it, really.

For those mechanisms that implement or enforce either SEQUENCE or REPLAY,
a single out-of-order, duplicated or dropped message will result
in an error from message unprotection and it's quite difficult to
say how to get back in sync with the peer after such an error --
and since it's not defined in the published mechanism specs the
exact behaviour after an error will differ among independent
implementations...

It might be a little tricky to *offer* out-of-order message unprotection
when one is using a stream-cipher like RC4, I assume, one would have
to create a seperate keystream for every single message.

>     Martin> Rekeying needs a negotiation between two peers

Well, hacks are conceivable for particular situations,
but not a portable solution that will work for all mechanisms,
which is what is required to become a GSS-API feature rather
than a implementation/mechanism specific hack.
 
Well, if you try to piggy-back it onto a message protection token,
then you will have to deal with the predictions of gss_wrap_size_limit()
and either cause sub-optimal fragmentation by the application or
break the promise (and the application) when you try to rekey. :-o

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 14:42:32 -0700

> the application panics and exits?

Yes.  Note that an application like NFS w/ RPCSEC_GSS might not "panic"
so much as destroy the failing security context and attempt
reestablishment (I'll have to look and see what our implementation
would do - I doubt it would panic, but the behaviour might still not be
acceptable, but I assert that it gracefuly handles context expiration).

> retransmit queue... happy coding!

Presumably the previous keys would remain available for messages whose
sequence numbers precede the rekey point and which have not been
received yet.  In fact, I'd insist on such behaviour.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 May 2003 23:58:38 +0200 (MET DST)

> correctly.  It can be done.

I've never looked at RPCSEC_GSS, but I assume it is a combination
of a GSS-API with a transport protocol framework and a transport
mechanism fully controlled by RPCSEC_GSS -- in which case this
middleware is able to hide security context renegotiations
completely from the application caller (in calling semantics not in
latency/network waits).  However this is not the general GSS-API caller.

Microsoft seemed either unwilling or unable to extend their RPC mechanisms
to cope with security refresh -- but mainly it would only have addressed
those applications that use RPC, leaving all other direct callers of SSPI
(GSS-API) out in the rain.

> dealing with context expiration (perhaps not acceptable to some users,

You get what you pay for.  For what they pay us, our customers would
likely complain about a "graceful failure" (as you called it).  :)

> gracefully.  So I believe it can be done - that others didn't 8 years

It'll take a while to come up with a usable and consistent vN spec,
then it'll take a few years before implementors add vN features,
if it catches any momentum at all.

I know long IPv6 has been under discussion now and how urgently
it was needed several years ago already -- still a lot of the
software that is written today isn't IPv6-ready, but a lot of
this software will be in uses for many years to come.

So better don't hold your breath...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 15:27:29 -0700

Yes.

> latency/network waits).  However this is not the general GSS-API caller.

Any app should be able to fail gracefully when contexts expire, really,
even if it means quitting.

> (GSS-API) out in the rain.

I'll let Microsoft address this :)

But please see my note about GSS-API vN feature negotiation.

> likely complain about a "graceful failure" (as you called it).  :)

Sure - fix the app.  Or better yet let's make sure that any GSS-API
extensions are negotiable, both, between the application and the GSS-API
implementation, and between initators and acceptors (obviously the
responsibility for the latter would fall to the mechanisms).

> if it catches any momentum at all.

Right.  Which is why it's silly to spend much effort talking about this
now.  We know it can be done, technically - we just don't have the time
and so it may not happen.

> So better don't hold your breath...

This precisely why I proposed increasing the sequence nunmber space for
the rfc1964 krb5 mechanism when it gets updated for AES support - the
updates to rfc1964 for AES *will* happen, and soon, particularly
compared to any GSS-API vN timelines :)

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 23 May 2003 00:37:48 +0200 (MET DST)

> acceptable, but I assert that it gracefuly handles context expiration).

The spec probably doesn't prevent a sensible implementation,
but I definitely wouldn't bet on Sun to provide a mature implementation
these days.  The code quality of Kerberos 5 GSS-API shipping with Solaris
seems worse than MIT Kerberos Beta 5 (buggy and not conforming to
both rfc-2743/2744 and rfc-1964).

> received yet.  In fact, I'd insist on such behaviour.

Well, that seems to be to late already -- neither rfc1964 insists
on it nor do all Kerberos 5 implementations implement it in that fashion...

MIT-Kerberos5 v1.1  src/lib/gssapi/krb5/k5unseal.c:
kg2_unwrap_priv(context, minor_status, ctx, ptr, bodysize, output, qop_state)
...
    if (now > ctx->endtime) {
        free(plain.data);
        *minor_status = 0;
        return(GSS_S_CONTEXT_EXPIRED);
    }

(That's the most recent Kerberos source that I have lying untarred
 on my 'puter.)

The funny part:  there are two variants of wrap/unwrap in MIT Kerberos,
one from pre-rfc1964 and one for rfc1964.  As far as I understand
this code snipped is for the newer variant while the code for the
v1 variant seems to return the unwrapped buffer along with
GSS_S_CONTEXT_EXPIRED.

Keep in mind, however, that GSS_S_CONTEXT_EXPIRED has always been
a fatal routine error, so valid unprotected data along with this
error code are not to be expected.  I had requested to allow
a distiction between informational and fatal errors for the
sequencing-related status codes for GSS-API v2, but since
GSS_S_CONTEXT_EXPIRED had always been a fatal routine error,
this couldn't be changed.

rfc2743.txt:
   2.3.4: GSS_Unwrap call
...
   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
   have expired, so that the requested operation cannot be performed.

Since you have no assurance (from the GSS-API spec!) that the integrity
could be performed on the message and was successful when you get
an output buffer along with GSS_S_CONTEXT_EXPIRED from gss_unwrap()
you should be processing that data at all.  Similar for gss_verify_mic(),
the portable application writer must not make any assumptions whether
a message integrity check was performed and succeeded when gss_verify_mic()
fails with GSS_S_CONTEXT_EXPIRED.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 15:36:31 -0700

> exact behaviour after an error will differ among independent

Yes, the GSS-API doesn't really provide a mechanism for out-of-sequence
recovery because it does not expose sequence numbers to the
applications.  So applications have to get sequencing right on their
own, which makes GSS-API's out-of-sequence detection feature pretty much
useless unless: a) the application is very simple and relies on the
transport to provide ordered delivery and b) the application is prepared
to either quit or restart when out-of-sequence delivery is detected.

> to create a seperate keystream for every single message.

I imagine so.  I've not looked at how the rfc1964 mech works with RC4
lately so I don't know how it works.

> than a implementation/mechanism specific hack.

I'm convinced now that many new features beyond what GSS-APIv2u1
provides would have to be negotiable.  But Sam's right, it should be
possible to rekey each direction of a GSS-API security context
transparently without the application even knowing.  However, in the
general case some mechanisms might wish to perform a new, protected DH
key exchange for rekeying, so that in the general case rekeying is
really one of those features that would have to be negotiated.

> break the promise (and the application) when you try to rekey. :-o

Something like that.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 15:44:07 -0700

> both rfc-2743/2744 and rfc-1964).

Bugs get fixed and what we'll ship soon enough is much improved.

> on it nor do all Kerberos 5 implementations implement it in that fashion...

Only because rfc1964 does not envision rekeying, yes.  I was talking
about rekeying, not context expiration.

[...]
> this couldn't be changed.

RFC2743 is quite clear about this, yes.

GSS_S_CONTEXT_EXPIRED is not a supplementary status code either.  That's
the key distinction when it comes to GSS_Unwrap() and GSS_Verify_MIC()
status codes and determining whether those functions did what they were
supposed to and failed "softly."

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 22 May 2003 20:11:37 -0400

Wow, this discussion really took off.
My two cents....

Back where we started:

> the Kerberos V extensions I focused my note on the mech.

If we go with a custom crafted message format, yes, we could probably
extend the sequence numbers for enctypes other than DES (and the
nonstandard 3DES and RC4 extensions) without much difficulty.

Either way, though, I keep hoping that in the long run we'll scrap the
current mech and go with something fully based on Kerberos-extensions
messages with minimal additions.  None of this "unless you're using
DES" type stuff.

>> before rekeying.

This has caused quite a bit of discussion, and of course I didn't mean
to suggest that we should fix it in order to deploy AES in
GSSAPI/krb5.  Better to fix them -- or at least make the issues and
recommendations be explicitly documented -- at the Kerberos level,
either for Extensions or when moving to Draft Standard.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 May 2003 21:29:05 -0700

> messages with minimal additions.  None of this "unless you're using

Well, which is it?  A re-design of the mech in terms of clarified
kerberos + minor extensions (KRB-SAFE-X) or rfc1964+?  We can choose
only one (because why re-do the mech again later?)

My preference is for making minor Kerberos extensions so the mech can be
re-specified in terms of Kerberos messages (for AES and newer enctypes).
But you knew that already :)

> either for Extensions or when moving to Draft Standard.

Yes.  But if we are going to go with rfc1964+ then let's fix the
sequence number stuff in there because I doubt we'll get to re-specify
the mech in terms of extended Kerberos V after extending rfc1964 (would
we really specify, implement and deploy two versions of the mech?)

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 23 May 2003 15:21:50 +0200 (MET DST)

Nicolas Williams wrote:
> I wrote:

Just because it could be hammered to fit the words of the GSS-API spec
doesn't make it a good idea.  There are several aspects that need
to be addressed.

For our application we have some interoperability constraints for
third-party gssapi mechanisms that which will disqualify certain
design decisions and hacks.

Besides requiring the availability of the optional security context
transfer capability (gss_import_sec_context()/gss_export_sec_context())
concurrent multiproccess credential accessibility, we do have 
specific limits on the performance for individual gssapi calls,
and we do have limits on the message protection overhead (i.e.
the size of a MIC token and the growth when app-data is wrapped.

All SPKM1 implementations that were so bold to default to
RSA digital signatures for message integrity protection
significantly exceeded our interoperability constraints for
latency on message protection calls and message size growth
for wrapped data.

Rekeying piggy-backed on message protection could easily
exceed our interoperability constraints.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 May 2003 08:17:48 -0700

> doesn't make it a good idea.  There are several aspects that need

The paragraph from me just above the snippet you quote concedes that
rekeying and any v3 features would have to be negotiable to avoid
breaking v1 and v2 apps.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 May 2003 21:13:13 -0400

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

    Nicolas> Well, which is it?  A re-design of the mech in terms of
    Nicolas> clarified kerberos + minor extensions (KRB-SAFE-X) or
    Nicolas> rfc1964+?  We can choose only one (because why re-do the
    Nicolas> mech again later?)

    Nicolas> My preference is for making minor Kerberos extensions so
    Nicolas> the mech can be re-specified in terms of Kerberos
    Nicolas> messages (for AES and newer enctypes).  But you knew that
    Nicolas> already :)

I share your preference.

However I have a higher priority preference that may conflict.  I
prefer that we get a draft written and agreed to before Microsoft is
forced to do something else.  Remember that while MIT and Heimdal
based codebases have 3DES for GSSAPI, Microsoft may be under some
pressure to get a quick solution to AES.

They may also be a lot less willing than MIT to deploy AES for
Kerberos but not GSSAPI.  Deploying something not for GSSAPI means
very little for them.

---

From: Richard M Feezel <[email-masked]>
Date: Tue, 27 May 2003 18:11:53 -0400

I make no claims to being an expert cryptographer but I've been reading the 
latest boot from Bruce Schneier and Niels Ferguson (Practical Cryptography) 
and I'm particularly interested in seeing an AES encryption mode defined for 
Kerberos.  The books focuses very much on setting a security goal of true 128 
bit level security and then proceeds to describe how basic building blocks 
like block cyphers, hashs, MACs, etc are assembled into useful functional 
units like secure channels.  They make arguments in various places about 
needing 256 bits of key material in order to achieve 128-bit strength 
protections.  They also talk about now much data can be processed with a 
given key before the protection mechanisms break down due to various, well 
understood cryptographic attacks.

Finally they pick specific algorithms and modes which, when combined, will 
achieve true 128-bit protection within certain constraints.  To create a 
secure channel they suggest using AES-256 in CTR mode (with a 32-bit counter) 
and SHA-256 HMAC with 32-bit block sequence numbers and a maximum block size 
of 2^36 bytes (because of the 32-bit counter in the CTR mode).  They argue 
convincingly that processing enough data to result in a sequence number roll 
over isn't VERY BAD.  They don't say "don't go beyond 32-bit sequence 
numbers"  but they start getting concerned beyond that point simply because 
they are concerned about using the same key long enough to process that much 
data isn't a good idea.

After all the above I'd be inclined to suggest that 48 or 64-bit block 
sequence numbers might not be a bad idea because, as I read it, block 
sequence roll-over is worse than the slow degredation in security that 
results from processing too much data with a single key.

I'd also like to raise the question of adopted the particular mode and hash 
that they suggest.  One of the nice things about CTR mode is that no message 
padding is needed.

I also realize that it might be too late in the process to make these kinds of 
changes.  I've been a lurker on the list for over a year but feel like I'm 
just beginning to understand Kerberos and cryptography enough that I might be 
able to make a meaningful contribution.  Also they Schneier/Ferguson book is 
VERY new and has helped me tremendously in undersanding cryptographic 
implementation issues.

Thanks,
Richard Feezel

---

From: Richard M Feezel <[email-masked]>
Date: Thu, 29 May 2003 14:00:02 -0400

Thanks,
Richard Feezel

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 29 May 2003 15:01:55 -0500

If you want this to go to the working group, you should send to it to 
[email-masked]

--