Subject: RFC1964 and AES

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 25 Nov 2002 16:28:11 -0600

Micheal Eisler who just joined the list brings
up some good questions about AES and GSSAPI QOP. 

In the MIT krb5-1.2.6 source is a file called src/lib/gssapi/krb5/3des.txt
which is a draft of "Triple-DES Support for the Kerberos 5 GSSAPI Mechanism"
It defines GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200

This would indicate that we might a document like this for AES. 
Or what is the default if qop_req=0? 

"Eisler, Michael" wrote:
> 
> > AES would be:
> > AES Encryption for Kerberos 5
> > http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael
> > -krb-02.txt
> > (This should be listed as a krb-wg draft.)
> >
> > These three would be submitted at the same time, as they each
> > depend on each other.
> > The Clarifications mandates that AES be implemented. MIT and
> > Microsoft appear to
> > be willing to implement AES.  I would expect other vendors too.
> >
> > > Yes, my immediate interest is in Kerberos for NFS, especially a
> > > follow on to RFC1964 that implements AES.
> >
> > When these three drafts are accepted, they should work with
> > RFC1964, since it just
> > uses Kerberos, as the Kerberos code, not the GSSAPI will set
> > the encryption
> > used.
> 
> Except that:
> 
>         - no QOP values are defined for the AES protection algorithms
>         - what does the default QOP now mean? That RFC1964 doesn't define
>                 it so it makes interoperability a bit of a pain. It's even
>                 more painful once AES is added. Do the i-ds you point to
>                 mention SHA-1 integrity? Even more pain (no QOPs, and
>                 the default QOP is even fuzzier).
> 
> When I brought up these sorts of issues with John Linn years ago, he said
> that he thought that the addition of new algorithms to RFC1964 would
> at minimum require a new OID.
> 
> SPKM's handling is better IMHO ... the QOP is always zero, and the underlying
> algorithms are negotiated within SPKM. As long as the initiator and target
> negotiate the strongest algorithms, with a minimum floor (which is
> how I specified SPKM-3), life is good.
> 
>         -mre

-- 

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

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 25 Nov 2002 19:48:28 -0500

> It defines GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200

The approach I used in that document was to add another number for a
new encryption system.  That doesn't automatically extend to new
encryption systems.  The new draft I've got in the works defines new
SEAL_ALG and SGN_ALG values to indicate "the encryption type of the
session key or subkey, and its associated checksum type".  That
requires some restructuring of the messages, because RFC 1964 assumed
plain (unauthenticated) encryption, with an initial vector, keyed
checksums, specific block sizes, etc., and the Kerberos crypto
framework works differently.

Publication of the kcrypto-gss draft would effectively be blocked on
getting the Kerberos crypto doc published first, so I've set it on the
back burner while the crypto draft needs work.  I should be back on it
soon.

BTW, the 3des GSS code in the MIT distribution does not match
3des.txt.  I may update the document, but will probably drop it from
IETF submission, or make it informational.

>> at minimum require a new OID.

Interesting.  I've heard nothing about this (though I haven't really
tried to get his opinion specifically on it), but it seems to me to be
little different from adding encryption types to Kerberos.

>> how I specified SPKM-3), life is good.

My take is that the current QOP handling in RFC 1964 is not
extensible, so as far as I'm concerned, it's always the default of 0
(or is simply ignored) and 0 means "use the session key type and use
one of the RFC 1964 algorithm specifications for DES keys".  In other
words, the encryption type is derived from the Kerberos exchange, with
some special cases.

Ken

---

From: Marcus Watts <[email-masked]>
Date: Mon, 25 Nov 2002 23:03:28 -0500

I have a somewhat aging modified version of gssapi that does
rc6+cast5 - this meant i had to go through, find all the magic
numbers, and fix them.  Most of them were just sizes of things
which were straight-forward enough to make configurable to the
(usually) obvious values where needed, but some were constants
that went out on the wire.

Hm.  for the good it does, I have:
 enum sgn_alg {
   SGN_ALG_s                   = 's',  /* XXX experimental MDW for cast/rc6: sha1*/
   SGN_ALG_DES_MAC_MD5           = 0x0000,
   SGN_ALG_MD2_5                 = 0x0001,
   SGN_ALG_DES_MAC               = 0x0002,
   SGN_ALG_3                     = 0x0003, /* not published */
   SGN_ALG_HMAC_MD5              = 0x0011, /* microsoft w2k; no support */
   SGN_ALG_HMAC_SHA1_DES3_KD     = 0x0004
 };
 enum seal_alg {
   SEAL_ALG_r             = 'r',       /* XXX experimental MDW for cast/rc6 */
   SEAL_ALG_c             = 'c',       /* XXX experimental MDW for cast/rc6  */
   SEAL_ALG_NONE            = 0xffff,
   SEAL_ALG_DES             = 0x0000,
   SEAL_ALG_1               = 0x0001, /* not published */
   SEAL_ALG_MICROSOFT_RC4   = 0x0010, /* microsoft w2k; no support */
   SEAL_ALG_DES3KD          = 0x0002
 };

SGN_ALG_s was sha-1; SEAL_ALG_r was rc6, SEAL_ALG_c was cast.  I
figured ascii letters would make debugging a bit easier.  I would have
used negative numbers but there weren't provisions for negative numbers
or an experimental space.  I figured it will take quite a while to get
up to 99 protocols.

An annoying feature of the code and probably of the protocol, which I
didn't address, was that it has its own notion of checksums,
confounders, and packing data which only mostly parallelled code in the
krb5 crypto library.

As I was going through the code, it seemed to me that there
was a certain amount of redundancy between the sgn/seal values,
and the k5 ticket itself -- there was a 1-1 mapping between the
k5 ticket key, and the sgn+seal pair.  The actual code doesn't
cleanly allow for it, but the protocol might: it may be possible
to look at the key first and use that to derive the allowed
algorithms from that.  If so, it might be possible to say
	SEAL_ALG_KD = 0x0002
and let the key type itself drive DES vs. AES vs. whatever.

Probably that's as much as matters for IETF, but for the good it does,
most of the real crypto specific code seems to be in:
	accept_sec_context.c
	configure
	gssapiP_krb5.h
	init_sec_context.c
	k5seal.c
	k5unseal.c
and I'd certainly be willing to share code.  I'm also willing to try
to come up with a version that interoperates with other people's code.

Also, I've been meaning to sit down with NFSv4 code and see how
their code differs from mine, and try to come up with similar
patches to that.

					-Marcus Watts
					UM ITCS Umich Systems Group

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 26 Nov 2002 10:48:32 -0600

After looking at RFC 2743, 2744, and 1964, I agree with Ken. A QOP of GSS_C_QOP_DEFAULT
i.e. 0, will have the underlying mechanism do its best. i.e. with 
Kerberos use the appropriate encryption (if conf_req_flag==1) and checksums for 
the session key. I would assume that any use or AES for session keys would
continue to do this. 

But if there are to be additional choices, then a new draft would be needed
to supplement 1964, and define the new flags. Note that 
draft-brezak-win2k-krb-rc4-hmac-04.txt it says Microsoft only supports QOP=0.
i.e. no additional flags where defined. The MIT des3.txt and code does
define some new bits for the QOP. 

I believe Michael's questions have to deal with NFS using gss_warp, 
and supporting the krb5, krb5i and krb5p with AES. 
I am assuming: 
krb5 does not use gss_wrap, 
krb5i uses gss_wrap with qop_req=GSS_C_QOP_DEFAULT, conf_req_flag = 0
krb5p uses gss_warp with qop_req=GSS_C_QOP_DEFAULT, conf_req_flag = 1
Then there should be no changes required to use AES, as long as the
session key has been selected by the underlying Kerberos to be AES.
 
So from the application programer, there are no changes, but there still 
needs to be a document like 3des.txt and draft-brezak-win2k-krb-rc4-hmac-04.txt
to define the additional protocol bits and message formats. 

--

---

From: Mike Eisler <[email-masked]>
Date: Tue, 26 Nov 2002 13:03:00 -0800

> krb5 does not use gss_wrap,

it uses gss_get_mic on the ONC RPC header, 
with qop_req set to whatever
produces the MD5/DES algorithms for 
integrity/privacy. 

> krb5i uses gss_wrap with qop_req=GSS_C_QOP_DEFAULT, conf_req_flag = 0

gss_get_mic, with qop_req set as noted above.

> krb5p uses gss_warp with qop_req=GSS_C_QOP_DEFAULT, conf_req_flag = 1

gss_wrap with qop_req set as noted above, 
and conf_req_flag = 1.

> session key has been selected by the underlying Kerberos to be AES.

The concern I have is that the administrator 
of the network service, in this
case NFS, might want to explicitly guarantee 
that some files are exported with
AES protection and for another set of files, 
not care if it's DES or AES (I
can't iamgine, given AES's speed advantages 
that the admin would prefer DES over AES).
NFS server's don't get to select the session 
key right ... this is between
the entity that acquires the ticket (the NFS 
client) and the KDC. So, using the
existing programming interfaces in GSS-API, 
how does the NFS server, when
it unwraps GSS tokens, know what it is getting?

Defining explicit QOP values for AES would solve the issue.

It's always been a puzzle to me as to why
GSS-API has a QOP notion in the
programming interface if it is expected to 
always have a value of GSS_C_QOP_DEFAULT.
It has similarly been puzzling that for Kerberos
V5, GSS_C_QOP_DEFAULT can mean
different things among different implementations
of RFC1964. Interoperability, when
it occurs, seems to be a miracle. 

	-mre

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 26 Nov 2002 15:59:54 -0600

> produces the MD5/DES algorithms for

Do you actually set a value other then GSS_C_QOP_DEFAULT? 
If you do, you should look closely at the implementations
you are using to see if the default gives you the same results,
then consifer using the default. This way when AES is added, 
you will get it by default if the session key was AES.
 
> that the admin would prefer DES over AES).

I can't imagine either. 

The problem here is that only one session key will have been exchanged.
So I don't see how you could use a DES session key to do AES,
or a AES session key to do DES. 

> key right ... 

Not via GSSAPI. With straight Kerberos the client can 
provide a list of e-types. Then if the KDC has
keys for that type it will select one.  

> this is between

The GSS looks at that. But it does not tell the calling application
what type of key or encryption is being used. 

> Defining explicit QOP values for AES would solve the issue.

Not really, see above as only one session key is available. 

> of RFC1964. 

No, I don't think it does. It means use the methods best suited
for the session key being used. 

> Interoperability, when

--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Nov 2002 17:13:45 -0500

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> Do you actually set a value other then GSS_C_QOP_DEFAULT?
    Douglas> If you do, you should look closely at the implementations
    Douglas> you are using to see if the default gives you the same
    Douglas> results, then consifer using the default. This way when
    Douglas> AES is added, you will get it by default if the session
    Douglas> key was AES.

Note that if Ken's draft is written correctly, you will either get AES
or an error if you use GSSAPI and the session key is AES.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Nov 2002 17:09:03 -0500

>>>>> "Mike" == Mike Eisler <[email-masked]> writes:

    Mike> The concern I have is that the administrator of the network
    Mike> service, in this case NFS, might want to explicitly
    Mike> guarantee that some files are exported with AES protection
    Mike> and for another set of files, not care if it's DES or AES (I
    Mike> can't iamgine, given AES's speed advantages that the admin
    Mike> would prefer DES over AES).  NFS server's don't get to
    Mike> select the session key right ... this is between the entity
    Mike> that acquires the ticket (the NFS client) and the KDC. So,
    Mike> using the existing programming interfaces in GSS-API, how
    Mike> does the NFS server, when it unwraps GSS tokens, know what
    Mike> it is getting?

It doesn't and this is outside the scope of GSSAPI to provide.  The
administrator can make sure that the KDC only issues AES tickets; from
a standards track level this is guaranteed to work because AES will be
mandatory to implement for Kerberos.

I suspect that by the time we have implementations of Kerberos
clarifications we'll also have Ken's GSSAPI draft.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 26 Nov 2002 16:48:15 -0600

Mike Eisler wrote:
> Sam Hartman wrote:

I agree with Sam.

> Then why does GSS-API have a QOP parameter?

Some additional flexability as it is "Generic Security Services" But that does
not mean every implementation can support multiple QOP. With Kerberos you
will still be limited to what can be supported bu the session key. 

> Except that there are Kerberos V5 implementations dating to RFC1510. They
> were compliant when RFC1510 was published and simply issuing an edict that
> they are now noncompliant doesn't solve the practical problem.

They can still be 1510 compliant. Clarifications is designed to be inter operate
with these and will fall back to DES, if the principals and policies will allow 
DES to continue to be used. 

>   -mre
> 
> p.s.: If this is uninteresting I'll go back to lurking, which was my intent
> until Doug invited me to comment.

No, please comment. You original questions have brough out the fact that we need
the GSSAPI doc for AES as well. 

--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Nov 2002 17:44:35 -0500

>>>>> "Mike" == Mike Eisler <[email-masked]> writes:

    Mike> Then why does GSS-API have a QOP parameter?

For cases when you support multiple QOPs; I suspect that US export
control regulations of the time were one motivation.

But with Kerberos for any given ticket ther's really only one valid
encryption type.

I would object to defining quality of protection values for each
Kerberos enctype as it would require that we revise the GSSAPI
specification each time we add a new Kerberos crypto system.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 26 Nov 2002 16:51:09 -0600

> specification each time we add a new Kerberos crypto system.

I agree, and I don't think it is nessesary for you applicaiton,
given the constraint that you have to use the protection based 
on the session key. 

--

---

From: Mike Eisler <[email-masked]>
Date: Tue, 26 Nov 2002 14:39:51 -0800

-mre

---

From: Mike Eisler <[email-masked]>
Date: Tue, 26 Nov 2002 14:55:57 -0800

> Do you actually set a value other then GSS_C_QOP_DEFAULT?

All the implementations we've tested with use GSS_C_QOP_DEFAULT both on
the wire in the NFSv4 security negotiation and in actual calls to gss_get_mic/gss_wrap.

> or a AES session key to do DES.

Since the application is using GSS-API and not a private kerberos library interface,
what I can imagine happening is the GSS-API initiator and target
blindly using DES when they want AES. I'm not assuming the system administrators
of the KDC, the application client, and the application server are the same person.

(Given Sam's comments, I realize the above scenario can't happen because AES is now
mandatory :-) )

	-mre

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Nov 2002 18:02:49 -0500

>>>>> "Mike" == Mike Eisler <[email-masked]> writes:

    Mike> (Given Sam's comments, I realize the above scenario can't
    Mike> happen because AES is now mandatory :-) )

Of course it can; 1) we aren't at a point where AES is actually
implemented or for GSSAPI even specified.

2) You can always implement additional enctypes.

I think that application administrators need to be able to control
what enctypes are registered for their applications in the KDB.
Several things we've assumed over the past few years depend on this.

Unfortunately, Kerberos administration protocols are currently not
standardized and so this becomes a real problem in practice.

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Nov 2002 17:18:16 +0100 (MET)

I'm still alive. :)

> the wire in the NFSv4 security negotiation and in actual calls to

Basically all "portable" gssapi-based applications will use
GSS_C_QOP_DEFAULT because no two mechanisms use the same QOP
values (understandably since they're using entirely different
crypto-protocols) and sometimes even two implementations of
the same mechanism implement different QOPs.

GSS-API is trying to be a panacea that satisfies everybody at the
risk of satisfying nobody (borrowing a quote from the preface of
Donald E. Knuth's The TeXbook).

The QOP was meant to be a hook that allows application tighter
integration with a specific mechanism or a specific implementation
of a mechanism, however its use directly impairs cross-mechanism
portability, which in its most extreme case is "plug'n'play" of
arbitrary mechanisms/implementations at the administrators
discretion.

This is also what rfc-2743, section 1.2.4 Quality of Protection
says.  However what is not explicitly stated but implied by the
spec is that GSS_C_QOP_DEFAULT can *NOT* be limited to one
specific QOP!  Even a mechanism spec that defines only a single
QOP can not do this, as it is always permitted to (a) add
implementation specific additional QOPs or (b) create
a successor spec with new QOPs.

Unfortunately for Kerberos, the use of QOP values for encryption
types has a kind of hen-and-egg problem with the current key exchange
protocol (see below).

The use of GSS_C_QOP_DEFAULT by an application usually means
that the application tries to be portable and either does
not care about the particular crypto algorithms in use or
doesn't have the necessary metaknowledge for a conscious
decision.

For a gssapi mechanism GSS_C_QOP_DEFAULT means that it is
basically free to choose among all the available QOPs.
What QOPs are available may however be limited by the
QOPs supported by the peer (let's hope the mechanism spec
defines a QOP negotiation) and it may be affected by
admin-configurable policy offered by a particular
mechanism **implementation**.

PKI-based mechanisms (e.g. SPKM, but also crypto-protocols that
perform a key exchange more like SSL) have seperated key exchange
(or the establishment of a shared keying material) from the actual
encryption algorithms (ciphersuites) that are going to be used,
and in that situation QOP values are ok and could be used
like ciphersuites in SSL.

However current Kerberos seems to have the key exchange tightly
coupled with the encryption type, so that the selection/negotiation
will have to be performed during "security context establishment".
QOP values can only be passed to the message protection calls,
and that is far too late to give the gssapi mechanism a clue what
an application desires.

The only "portable" method permitted by the current gssapi spec
to affect the "negotiation" of the security context are the
context flags passed to gss_init_sec_context().  Unfortunately
gss_accept_sec_context() doesn't have such an input paramter,
only an output parameter.  This means that server policy issues
are a "local issue", i.e. implementation specific.  It would
be ok to define a mechanism-specific extension to a gssapi
mechanism spec, but this will impair cross-mechanism
portability and does not address the installed base of
mechanisms based on the predecessor spec, so beware!

IIRC Cybersafe used gssapi context flags to request and indicate
non-standard Kerberos enctypes (like RC4 for Micrsoft interoperability)
at the gssapi context establishment time.

-Martin