Subject: RE: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 10 Oct 2003 01:43:00 -0700

Ken Raeburn wrote:

>> Section 1:

>> Next to last paragraph: I don't think this is a great description.
>> How would you classify RC4 based on this?  An I-D came out, but no
RFC
>> yet.  I would hope that if an RFC came out now, it would be in terms
>> of a kcrypto profile.  So, if you get an RC4 session key, should you
>> assume support for CFX, or the Microsoft RC4 mechanism extension?
>> (And how about 3DES?  The write-up I did on MIT's extension never
>> became an RFC.)  Maybe better would be to list the types that are not
>> supported this way.

Jeff brought up this point too. The clarification really should
enumerate all of the enctypes which are not "newer". 

I am now less optimistic for putting the list into the clarifications.
Should we go ahead adding the list here?  Because whether an enctype is
"newer or not" is also tied to the decision whether to use ETYPE_INFO2
or ETYPE_INFO, I will be a bit sadden if we end up defining the
not-newer enctypes in this draft.  

I want to bring this up to the attention of Doug and he would know the
IESG-last-call status for the clarifications. 

>> If the acceptor specifies a subkey, and the initiator is thus
required
>> to start using it on receipt, under what circumstances should/may the
>> acceptor start flagging as errors tokens received without the
>> AcceptorSubkey flag set?

It should not be enforced by the acceptor or the initiator, but rather
it is enforced by the sender and not enforceable by the receiver. The
text here serves two purposes:

1) it tells implementers that acceptor-subkey always wins, this was not
clearly stated before.
2) it allows implementations that do not support prot_ready to discard
initiator-asserted-subkey.  

I do not think prot_ready is that useful after all.

>> If this is, as I suspect, merely a clarification of RFC 1964, and not
>> actually different from what interoperable RFC 1964 implementations
>> are doing, please mention that.

What is needed here is a reference to 2743 and 2744, if we have that, it
should be clear, right?

>> Sections 4.2.4, 4.2.6.1 and 4.2.6.2:

>> I think the Wrap-without-confidentiality and MIC tokens should order
>> the header and application data fields the same way.  Otherwise, an
>> attacker who can force one application message to contain

>> 	<fake-MIC-header> <stuff>

>> may be able to then construct a MIC token over an application message
>> containing

>> 	<stuff2> <fake-Wrap-header>

>> if the cryptosystem in use is one for which the key usage number does
>> not actually perturb the encryption.  (We couldn't require that,
>> remember, because we need DES to be conformant.)

I do not understand this one. Note both MIC and
Wrap-without-confidentiality tokens use get_mic(), in other words, they
use the same usage number (that is Kc when using simplified profiles).
Also token headers for MIC and Wrap-without-confidentiality are slightly
different (for example one has RRC the other contains fillers)

>> Since there's no prohibition against a non-zero RRC in Wrap tokens
>> without confidentiality, I'll plan to exercise that in the MIT code.

Yes, Wrap tokens without confidentiality need to be rotated too when
SSPI applications are supplied with 3 buffers (instead of 4 buffers).

Thanks, Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Thursday, October 09, 2003 7:09 PM
To: [email-masked]
Subject: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

As I said, most of these are fairly minor things...

Section 1:

Next to last paragraph: I don't think this is a great description.
How would you classify RC4 based on this?  An I-D came out, but no RFC
yet.  I would hope that if an RFC came out now, it would be in terms
of a kcrypto profile.  So, if you get an RC4 session key, should you
assume support for CFX, or the Microsoft RC4 mechanism extension?
(And how about 3DES?  The write-up I did on MIT's extension never
became an RFC.)  Maybe better would be to list the types that are not
supported this way.

Section 2:

If the acceptor specifies a subkey, and the initiator is thus required
to start using it on receipt, under what circumstances should/may the
acceptor start flagging as errors tokens received without the
AcceptorSubkey flag set?

Section 3:

First paragraph: "applications which use the default QOP are not
guaranteed to be portable across implementations..."; shouldn't this
be applications which *don't* use the default?

Section 4.1.1.2:

If this is, as I suspect, merely a clarification of RFC 1964, and not
actually different from what interoperable RFC 1964 implementations
are doing, please mention that.

Section 4.2.1:

With the sequence number and direction indicator now no longer in the
same field, there is no logical reason to combine their descriptions
into one section when the other fields are described in separate
sections.  They should all be described in separate sections.

Sections 4.2.4 and 4.2.6.x:

The draft repeatedly refers to "the checksum operation defined in the
crypto profile" and similar phrases.  The crypto framework, or rather
a profile based on it, does not specify a unique checksum type that
must be used with a given encryption type.  It does, however, specify
a checksum type that is mandatory to implement if the encryption type
is supported.  In general, there is no reason a des-cbc-md5 encryption
key cannot be used to make an rsa-md4-des checksum, if it is known
that the receiver supports the latter.  It's because of the lack of
negotiation or any field for specifying the checksum type that the
cfx-02 mechanism chooses to always use the required checksum type.

Sections 4.2.4, 4.2.6.1 and 4.2.6.2:

I think the Wrap-without-confidentiality and MIC tokens should order
the header and application data fields the same way.  Otherwise, an
attacker who can force one application message to contain

	<fake-MIC-header> <stuff>

may be able to then construct a MIC token over an application message
containing

	<stuff2> <fake-Wrap-header>

if the cryptosystem in use is one for which the key usage number does
not actually perturb the encryption.  (We couldn't require that,
remember, because we need DES to be conformant.)

Section 4.2.5:

Since there's no prohibition against a non-zero RRC in Wrap tokens
without confidentiality, I'll plan to exercise that in the MIT code.

Section 4.2.4, 4.2.6.2:

In the wrap-with-confidentiality case, "filler" is used to describe
two different things, an octet field in the token header, and an
optional insert between the application data and the copy of the token
header.  Perhaps a different word could be used for one of the two
cases?

Section 6:

What does "use of Kerberos Version 5 extensions" mean?  I think I know
what you mean by it, but the spec should be useful to an implementor
(now, or 10 years in the future) who isn't keeping tabs on the working
group discussions.

Section 9.1:

Fix the typo ("Kerveros") and the author list for [KRBCLAR].  (Of
course, we'll have to wait for it and the other drafts to go to RFC
before cfx can, so updates will be needed for that reason also.)

Sorry, I still haven't gotten to looking at the error codes yet.

As for the "generic token framing" thread, I've got no strong opinion,
except that Martin's suggestion to reserve the token-id ranges that
would correspond to the wrapper, if we don't always use the wrapper,
is a good one.  I had some concerns about that when dropping the
framing was first suggested, but never investigated.

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Oct 2003 11:20:48 -0400

> IESG-last-call status for the clarifications.

Yes; I think this is worth fixing before clarifications is published as an 
RFC.  The current wording is too ambiguous; it depends on the reader to 
determine in what order certain specs were issued, which may not correspond 
to RFC numbers, and/or to make a determination as to whether particular 
specs were issued "simultaneously".

Interestingly, Ken, you've called out all the execption cases I know about. 
The only "older" enctypes AFAIK are the existing DES, 3DES, and RC4 
enctypes, some of which are not described in RFC's.

The gssapi-cfx document, then, should refer to the list in [KRBCLAR].

> initiator-asserted-subkey.

I don't think this is good enough.  If prot_ready is supported, then an 
initiator may construct a per-message token using an initiator-subkey, 
before it has received the AP-REP from the acceptor.  For prot_ready to be 
useful, the acceptor must be willing and able to process such a message. 
However, if the acceptor does not at some point start rejecting per-message 
tokens which do not use the acceptor-subkey, then we don't really have 
acceptor-subkey-wins; we have initiator-does-whatever-he-wants.

> I do not think prot_ready is that useful after all.

It may save round trips in some application protocols.  That's often 
beneficial.

> (now, or 10 years in the future) who isn't keeping tabs on the working

Well, you can't actually refer to kerberos-extensions without waiting for 
it.  Fortunately, you don't have to:

"use of a version of Kerberos later than Kerberos Version 5 Specification 
2".

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Oct 2003 19:34:44 +0200 (MET DST)

> not-newer enctypes in this draft.  

I have also asked to have the list in the CFX document in case
some behaviour in CFX should directly depend on that list.

From what I know there once was a Kerberos5 implementation from
OpenVision (then Veritas, then Platinum, now Computer Associates)
which supported a 40-bit RC4 encryption type for reasons of crypto
export in 1997.

> 1) it tells implementers that acceptor-subkey always wins, this was not

Each peer can only enforce its own key for sending.

And if the initiator uses
   gss_init_sec_context(unidirectional) ->
   gss_wrap                             ->
   gss_wrap                             ->
   gss_delete_sec_context()
then it will never even see an acceptor subkey.
When the initiators implementation supports prot_ready,
then the initiator could even do this with mutual authentication
before it gets to see the acceptors subkey in the final context-level
token (but which may never get used then).

Why do we need an acceptor-subkey at all?

I don't see any real value in it.  Some people might get deceived
that this would enable them some sort of policy control over the
session key (like a server-enforced small key size), however
as far as I know the IETF refuses to standardize crypto control
hooks for governments into its protocols.

As long as the client uses the authenticating tickets' session key 
in the generation of the initiator subkey (e.g. XOR plus weak key
elimination) there shouldn't be any problem with the initiator's subkey.

> initiator-asserted-subkey.  

Huh -- 2) sounds wrong.  A security context should always use a subkey,
so discarding would be stupid, replacing with an acceptor-generated
random subkey would be the only reasonable alternative.

> I do not think prot_ready is that useful after all.

I can understand that Microsoft doesn't have any use for it since
most of their authentication protocols don't support it and so
they cannot use it.

However the original proposal came from IBM for specifically for use
with their Kerberos implementation to allow a stateless server side
for a mutually authenticated secure request-reply protocol.

There definitely is use for it and there was broad consensus in the
CAT working group that this feature was useful.

If you cannot make a very strong technical point why prot_ready
ought to be dropped, then it should definitely be accounted for
in the CFX spec.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 10 Oct 2003 18:00:16 -0400

(One more bit of nitpicking to add: Use "octet" for the basic network
data unit.  A "byte" is a host artifact, and may be more or less than
8 bits, even though such choices have become relatively unpopular.)

> use the same usage number (that is Kc when using simplified profiles).

According to section 2, Wrap (with or without confidentiality) uses
key usage 22 or 24, and MIC uses 23 or 25.

> different (for example one has RRC the other contains fillers)

Yes, and they have different token ids.  My point is, since the header
is included in the beginning in one case, and at the end in the other,
including fake headers at the opposite ends can lead you to
checksumming the exact same data for two messages.  If the key usage
value doesn't perturb the checksum, then if an attacker can arrange
for one of the messages to be sent, then that attacker can construct
the other message.

In more detail:

Wrap without confidentiality uses:

     WrapWOC(M) = WrapHeader | M | GetMic(M | WrapHeader)

MIC tokens use:

     MIC(M) = MICHeader | GetMic(MICHeader | M)

Now, if I arrange for one side to send

     MIC(M' | FakeWrapHeader)

then the data on the wire includes:

     GetMic(MICHeader | M' | FakeWrapHeader)

and so I can construct a message containing

     WrapWOC(MICHeader | M')

which the receiver will, I believe, consider valid.  If a Wrap token
containing MICHeader|M' can be made "interesting" to the receiver,
maybe I can break into your system.  The fake header can use whatever
sequence number it wants, so I could drop the message into the data
stream right away, or much later.

> SSPI applications are supplied with 3 buffers (instead of 4 buffers).

Ah, right.  Didn't recall offhand if there was a reason for it; the
justification only refers to encryption.  Obviously, yes, you'll need
it.

> which supported a 40-bit RC4 encryption type for reasons of crypto

Huh.  You learn something new every day.  If I ever knew that, I
forgot it long ago....

> Why do we need an acceptor-subkey at all?

If its use can be enforced by the acceptor, then its use proves to the
acceptor that the initiator is live and not a replay attack.  Given
some additional constraints (like not using the same service principal
in any Kerberos application service -- GSSAPI or not, since this is a
Kerberos issue -- that doesn't do equivalent replay prevention without
a replay cache), the acceptor side can forego the replay cache with no
loss of security.

But if any messages will be accepted using the initiator-provided
session or subsession key, then the replay cache is needed, unless the
protocol requests are idempotent (and, again, various other
constraints are met).

The replay cache management can be a performance issue if a server is
very heavily used.  MIT has performance issues in this area when the
replay cache is large.  Heimdal, AFAIK, doesn't support the replay
cache at all, which is a potential security problem.  I don't know
about Microsoft's implementation.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 10 Oct 2003 19:09:50 -0400

Jeffrey Hutzelman <[email-masked]> writes:

> Well, you can't actually refer to kerberos-extensions without waiting
> for it.  Fortunately, you don't have to:
>
> "use of a version of Kerberos later than Kerberos Version 5
> Specification 2".

In other words, we're declaring plain old RFC 1964 to be a pre-5.3
application, so a KDC or service shouldn't indicate that the service
principal supports 5.3 until the GSSAPI mechanism is upgraded.  Right?

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 12 Oct 2003 11:44:51 -0400

> principal supports 5.3 until the GSSAPI mechanism is upgraded.  Right?

Hm.  That does seem to be what I said, doesn't it.  I'm not sure we 
actually want that, though.  It's not precisely the same -- the GSS mech 
could be upgraded before or after the Kerberos implementation, and the 
5.3-supported flag should really apply to the service's Kerberos 
implementation.

Perhaps it would be best for the GSSAPI mechanism _not_ to make assumptions 
about what the other side is running.  Of course, then we're stuck until 
the end of time, since there is no standard API for indicating support for 
new features.

I think maybe we want a new OID after all.  Under CFX, both OID's would 
indicate support for the same mechanism, except that the use of the "new" 
mechanism OID would indicate support for new token formats. 
Implementations which support CFX would be expected (REQUIRED) to support 
both OID's; naturally, an RFC1964 implementation will support only the old 
OID.  Note that this doesn't directly solve the problem of knowing when 
both sides support CFX, but it does provide a way for the application to 
indicate that via appliation-specific knowledge such as out-of-band 
mechanism negotiation or knowledge that the application protocol will only 
be used with sufficiently new GSSAPI implementations.  And, of course, you 
get that negotiation for "free' in applications which use SPNEGO.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Oct 2003 08:51:51 -0700

> >principal supports 5.3 until the GSSAPI mechanism is upgraded.  Right?

Well, almost.  The new mech will be used with pre-extensions Kerberos V
for new enctypes and it will be used with extended Kerberos for all
enctypes by clients that support it (any clients that don't have to be
pre-extensions clients and must not support new enctypes).

> 5.3-supported flag should really apply to the service's Kerberos 

I'm willing to make the tie between the Kebreros V mechanism and the
Kerberos V implementation.  There aren't very many implementations of
either that don't also implement the other (though Samba comes to mind).

> the end of time, since there is no standard API for indicating support for 

This is something that we hope is fixed by the new mechanism - i.e.,
it's extensible (though I'm not thrilled by the details).

> mechanism OID would indicate support for new token formats. 

A new OID would be fine in addition to the negotiation by Kerberos V
minor version / Kerberos V ticket session key enctype.

> get that negotiation for "free' in applications which use SPNEGO.

(And for SSHv2 gss keyex/userauth, and for NFSv2/3/4, and any app that
 does its own GSS-API mechanism negotiation.)

Agreed.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 14 Oct 2003 16:59:22 -0400

You still haven't addressed this point.
I believe we need to change one message or the other, to make them
consistent, or to at least make it impossible for two messages of
different types to result in the same data being checksummed.

> which the receiver will, I believe, consider valid.

Ken