Subject: draft-weber-krb-wg-kerberos-preauth-00

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 15 Sep 2003 17:04:20 -0400

I apologize for not getting this written sooner.  This is still rather
incomplete, but I think I have finally gotten it to a point where
having the working group think about what is there so far might start
to be useful.

Below is a draft that attempts to define a preauthentication framework
which should be more modular than what we currently have for preauth.
I certainly believe that it should replace my previous anon-dh draft.
This draft also tries to solve the problems of extra-tgt, and
draft-ietf-krb-wg-hw-auth, while adding perfect forward secrecy to all
preauthentication.  It may also adaquately solve the problem that the
must-pk-encrypt-sad flag was supposed to solve.  This draft also tries
to solve PKINIT, except that for authenticating the client to the KDC,
it engages in large quantities of handwaving; a future version will
basically just sign the session identifier.  (World peace, an end to
poverty, and a usable intellectual property status for SRP are not
included in this draft, however.)

This is very much a rough draft.  I suspect within a couple weeks I'll
decide that there are things I think are wrong with it, I bet other
people will notice problems, etc.  There are details this version
doesn't bother to fully specify.  This version doesn't have a nice
clean ASN.1 module in an appendix, and we probably want to copy the
stuff it uses from PKINIT, rather than referencing PKINIT.  I'm not
sure if the ASN.1 here is even correct ASN.1; I write ASN.1 mostly by
imitiating other ASN.1; I don't quite fully understanding ASN.1.

One specific issue I'm aware of is that I'm not terribly convinced
that I've got the cleanest way to do the Diffie-Hellman to symmetric
key conversion, and key combining.  I would appreciate feedback
(especially from Sam) about what the best way to do this is.

Another specific issue is that I think a good protocol design probably
requires signing some static data in addition to the session key.  I
don't feel like sorting out exactly what I think that data should be this
afternoon, so I'm not going to worry about that for now, but I expect
that I will fix that in a future revision, assuming that people don't
convince me that continuing in this direction is completely useless.

When using extra-tgt style functionality to authenticate the KDC to
the client, it may be desireable to use tickets for some service other
than the ticket granting service, so that a priviliged process can
hand preauthentication tickets to an unpriviliged process, and not
worry that such tickets will be used to get other priviliges.

INTERNET DRAFT                                         Joel N. Weber II
                                                     September 15, 2003
                                                 Expires March 15, 2004

                  Kerberos Preauthentication Framework
               draft-weber-krb-wg-kerberos-preauth-00.txt

   This document is an Internet-Draft and is subject to all the
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The distribution of this memo is unlimited.  It is filed as draft-
   weber-krb-wg-kerberos-preauth-00.txt, and expires 15 March 2004.
   Please send comments to the author or to [email-masked]

ABSTRACT

   This document defines a framework for preauthentication.  This
   framework uses diffie-hellman to negotiate a key which is used to
   encrypt preauthentication data and to encrypt the EncKDCRepPart.
   This document also defines several preauthentication data types for
   creating various types of signatures against the Diffie-Hellman
   session key, in order to perform authentication.

INTRODUCTION

   Historically, there have been a variety of proposals for
   preauthentication methods in Kerberos, which have in some cases
   solved overlapping problems independently.  For example, PKINIT has
   proposed one solution to the problem of generating a symmetric
   encryption key when the principal has no long term symmetric
   encryption key available; a completely different solution to this
   problem has been proposed for use with single use authentication

Weber             Kerberos Preauthentication Framework          [Page 1]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

   methods.

   The lack of coherency between preauthentication methods is also
   potentially a problem if there is a desire to require the user to
   authenticate using more than one method.

   Another issue is that a well-designed key exchange protocol which is
   intended to protect the confidentiality of network traffic will use
   temporary keys for the encryption, in such a way that if the long
   term keys are eventually compromised, an attacker cannot use them to
   decrypt old network traffic that may have been saved.  This property
   is known as perfect forward secrecy, and is achieved by doing a
   Diffie-Hellman exchange to contribute entropy to the encryption keys.
   PKINIT can provide perfect forward secrecy, but doesn't always; other
   well known preauthentication methods generally do not provide perfect
   forward secrecy at all.

   This framework defines a series of preauthentication data types.  It
   uses Diffie-Hellman to negotiate a key.  This key is used to encrypt
   preauthentication data.  This framework also defines a series of
   preauthentication data types which are used to pass signatures of the
   Diffie-Hellman key.  Finally, once the KDC has recieved sufficient
   evidence that the client is authentic, it sends a ticket, which is
   encrypted in a key derived from the Diffie-Hellman exchange, and
   mixed with symmetric keys if such keys were used for authentication.

PA-DH-PARAMS-REQ

   To request a Diffie-Hellman group from the KDC, the client sends
   preauthentication data of type PA-DH-PARAMS-REQ, with the following
   structure as the preauthentication data:

   PA-DH-PARAMS-REQ-ENTRY    ::= SEQUENCE {
           min               [0] UInt32
           max               [1] UInt32
           preferred         [2] UInt32
   }

   min, max, and preferred are sizes of the group in bits.

PA-DH-PARAMS-REP

   The KDC replies to PA-DH-PARAMS-REQ by sending a KRB-ERROR containing
   a pa-data element of type PA-DH-PARAMS-REP, with a value of type PA-
   DH-PARAMS-REP-ENTRY:

   PA-DH-PARAMS-REP-ENTRY    ::= SEQUENCE {
           kvno                    [0] UInt32

Weber             Kerberos Preauthentication Framework          [Page 2]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

           serverPublicValue       [1] SubjectPublicKeyInfo
   }

   The kvno value MUST uniquely identify the contents of the
   serverPublicValue for the duration during which it is valid, which
   MUST be 30 minutes.  The KDC MUST accept requests using the same kvno
   during that duration from any network address and port number.  The
   client MUST only use the parameters recieved when communicating with
   the same KDC.

   The message including PA-DH-PARAMS-REP MUST also include an ETYPE-
   INFO2 entry, which is used to pass the list of acceptable enctypes,
   and the corresponding salt and string to key parameters to be used in
   converting the Diffie-Hellman key to a key usable by the cryptosystem
   choosen.

PA-DH-ENC-REQ

   PA-DH-ENC-REQ-ENTRY    ::= SEQUENCE {
           kvno                    [0] UInt32
           clientPublicValue       [1] BIT STRING
           enc-pa-data             [2] EncryptedData -- PA-DATA
   }

   The KDC MUST be prepared to deal with replays of this message; it can
   do so using a replay cache, whose entries must be kept until the
   serverPublicValue parameters associated with the particular kvno
   expired, or by simply having behaviors which are not harmful when an
   attacker causes a replay.

   In order to prevent the possibility of the KDC being required to keep
   state, any elements which are included in the enc-pa-data which
   partially authenticate the user MUST be included in subsequent PA-DH-
   ENC-REQ messages where additional user authentication elements are
   added.

   If the KDC does not issue a ticket, it replies with a KRB-ERROR of
   type KDC_ERR_PREAUTH_REQUIRED, with a PA-DH-ENC-REP containing pa-
   data elements replying to the pa-data elements which were enclosed in
   PA-DH-ENC-REQ.

   The key used to encrypt the enc-pa-data field is determined by taking
   the Diffie-Hellman shared secret, encoded as FIXME, converting it to
   base64.  The output of the base64 function is referred to as the
   session identifier.  The output of the base64 function is also feed
   through the string-to-key function to generate the key used for
   encrypting PA-DH-ENC-REQ and PA-DH-ENC-REP elements.  That key is
   used for PA-DH-ENC-REQ with a key usage value of FIXME.

Weber             Kerberos Preauthentication Framework          [Page 3]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

PA-DH-ENC-REP

   PA-DH-ENC-REP-ENTRY    ::= SEQUENCE {
           enc-pa-data             [0] EncryptedData -- PA-DATA
   }

   The KDC's reply to any pa-data elements it recieves inside a PA-DH-
   ENC-REQ are enclosed in a PA-DH-ENC-REP element, and encrypted using
   the same key, but instead with a key usage value of FIXME.

PA-NONCE

   A pa-data type of PA-NONCE is used by the client to make sure that
   the message from the KDC is fresh, and not a replay of a previous
   message that the KDC had sent to the client.  The KDC simply copies
   the pa-data value it recieves to the reply it sends, discaring the
   PA-NONCE value when issuing a ticket.

PA-KDC-SHARED-SECRET-SIGN-REQ

   PA-KDC-SHARED-SECRET-SIGN-REQ enclosed in a PA-DH-ENC-REQ is used to
   ask the KDC to generate a cksum of the session identifier using a
   particular principal's long term key.  This provides one mechanism by
   which the client can verify the identity of the KDC when using a weak
   secret for user authentication.

   The KDC MUST reject this request if the principal named by sname has
   a weak password; failure to reject this request would allow an
   attacker to get ciphertext encrypted in the weak key which would
   allow an offline brute-force attack.  FIXME: how does the KDC return
   an error in that case?

   PA-KDC-SHARED-SECRET-SIGN-REQ-ENTRY ::= SEQUENCE {
           sname           [0] PrincipalName
   }

PA-KDC-TGT-SIGN-REQ

   PA-KDC-TGT-SIGN-REQ enclosed in a PA-DH-ENC-REQ is used to ask the
   KDC to generate a cksum of the session identifier using the session
   key of a ticket granting ticket; this is useful in cases where the
   realm of the key being used by the client to verify the server's
   identity is different than the realm the client is requesting a
   ticket for, making PA-KDC-SHARED-SECRET-SIGN-REQ unusable.

   PA-KDC-TGT-SIGN-REQ-ENTRY ::= SEQUENCE {
           ticket          [0] Ticket
   }

Weber             Kerberos Preauthentication Framework          [Page 4]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

PA-KDC-SIGN-REP

   When the KDC recieves a PA-KDC-SHARED-SECRET-SIGN-REQ or PA-KDC-TGT-
   SIGN-REQ element, it replies with a PA-KDC-SHARED-SECRET-SIGN-REP
   element, enclosed in a PA-DH-ENC-REP.  The cksum is made with a key
   usage value of FIXME against session identifier, using the long term
   key of the principal specified in the PA-KDC-SHARED-SECRET-SIGN-REQ,
   or the session key of the ticket in the PA-KDC-TGT-SIGN-REQ.

   PA-KDC-SIGN-REP-ENTRY ::= SEQUENCE {
           cksum           [0] Checksum
   }

PA-KDC-PK-SIGN-REQ

   To request that the KDC sign the session identifier using a public
   key, the client sends PA-KDC-PK-SIGN-REQ inside a PA-DH-ENC-REQ,
   including information about what certificates it trusts.

   PA-KDC-PK-SIGN-REQ-ENTRY ::= SEQUENCE {
       trustedCertifiers       [0] SEQUENCE OF TrustedCAs OPTIONAL,
                                   -- A list of CAs, trusted by
                                   -- the client, used to certify
                                   -- KDCs.
       kdcCert                 [1] IssuerAndSerialNumber OPTIONAL,
                                   -- Defined in CMS.
                                   -- Identifies a particular KDC
                                   -- certificate, if the client
                                   -- already has it.
   }

PA-KDC-PK-SIGN-REP

   The KDC replies to PA-KDC-PK-SIGN-REQ with a PA-KDC-PK-SIGN-REP
   element enclosed in a PA-DH-ENC-REP element.

   PA-KDC-PK-SIGN-REP-ENTRY ::= SEQUENCE {
           dhSignedData            [0] ContentInfo,
                                       -- Type is SignedData.
                                       -- Content is KDC-PK-SIGN-REP-DATA
                                       -- (defined below).
   }

   KDC-PK-SIGN-REP-DATA ::= SEQUENCE {
           sessionid            [0] OCTET STRING
   }

Weber             Kerberos Preauthentication Framework          [Page 5]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

PA-AUTH-METHODS

   Every PA-DH-ENC-REP element the KDC sends MUST contain a PA-AUTH-
   METHODS element.  The partialsuccess field has a value of 1 if the
   client sent authentication data which partially authenticates the
   client, and which is correct so far; otherwise that field has a value
   of 0.  methods contains a list of pa-data types which can be used to
   authenticate the client.

   PA-KDC-SIGN-REP-ENTRY ::= SEQUENCE {
           partialsuccess   [0] Int32
           methods          [1] SEQUENCE OF Int32
   }

PA-CLIENT-SHARED-SECRET-SIGN

   A principal which wishes to authenticate itself to the KDC using a
   long term symmetric encryption key sends PA-CLIENT-SHARED-SECRET-
   SIGN, enclosed in a PA-DH-ENC-REQ element.

   PA-CLIENT-SHARED-SECRET-SIGN-ENTRY ::= SEQUENCE {
           cname           [0] PrincipalName,
           cksum           [1] Checksum
   }

   cname is the name of the client attempting to get tickets.  cksum is
   a cksum of the session identifier, using the long term key of the
   principal named by cname, and a key usage value of FIXME.

   FIXME: cname already appears in the KDC-REQ-BODY.  Is putting it here
   really the right way to integrity protect it, and do we even need
   integrity protection for it?

   The key used to create the cksum is also used, but with a key usage
   value of FIXME, to perturb the key used to encrypt the EncKDCRepPart.

PA-CLIENT-PK-SIGN

   FIXME: this should be specified, so that a client with a public
   signing key can authenticate itself to the KDC.

SAM

   PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2 elements may be included in
   PA-DH-ENC-REP and PA-DH-ENC-REQ elements, respectively.  When this is
   done, encryption within PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2
   happens in exactly the same was as if they were not enclosed in PA-
   DH-ENC-REP and PA-DH-ENC-REQ.

Weber             Kerberos Preauthentication Framework          [Page 6]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

   If the send-encrypted-sad flag is not set, the SAD is used to perturb
   the EncKDCRepPart of the AS-REP, with a key usage value of FIXME.
   However, the key used to encrypt the EncKDCRepPart is never perturbed
   by the long term key as a result of the long term key being used in
   PA-SAM-RESPONSE-2; PA-CLIENT-SHARED-SECRET-SIGN can be used if this
   is desired.

EncKDCRepPart KEY DERIVATION

   The output of the Diffie-Hellman function is converted to some binary
   format which is padded in such a way that it will fit the block sizes
   of any and all keys from elements such as PA-CLIENT-SHARED-SECRET-
   SIGN.  FIXME: this document needs to describe exactly how that is
   done.  That block is then encrypted with each key from a user
   authentication element, in the order they appear in the PA-DH-ENC-
   REQ, if any.  Next, the block is base64 encoded, and the output of
   the base64 function is fed through the string-to-key function, using
   the string to key parameters that were provided in the ETYPE-INFO2
   element in the same KRB-ERROR message as the PA-DH-ENC-REP.  The
   resulting key is used with a key usage value of FIXME to encrypt the
   EncKDCRepPart.

SECURITY CONSIDERATIONS

   Ideally, the client should know a key which will allow it to use PA-
   KDC-SHARED-SECRET-SIGN-REQ, PA-KDC-TGT-SIGN-REQ, or PA-KDC-PK-SIGN-
   REQ to verify the identity of the KDC, and should do this
   verification before sending any user authentication data which may
   have a weak key.

   However, if a weak key is being used, the use of Diffie-Hellman will
   protect against passive attacks, and this protocol can be used to
   detect a man in the middle attack.

   Once the KDC sends a set of paramters in a PA-DH-PARAMS-REP, it MUST
   to accept the corresponding kvno value in an unlimited number of PA-
   PFS-REQ requests for at least a half hour plus allowable clock skew.
   Therefore, if the client tries to reuse a kvno value for the Diffie-
   Hellman parameters, and finds that they are no longer usable, it can
   reasonably conclude that it has hit a man in the middle attack.

   Care should be taken that the parameters are preserved across
   reboots, so that a KDC crashing does not appear as a man in the
   middle attack.

   PA-SAM-REDIRECT should be distrusted if it is recieved after the
   client starts sending user authentication data.

Weber             Kerberos Preauthentication Framework          [Page 7]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

   Automatically retrying with the master KDC upon failure will render
   this MitM attack detection useless.

AUTHOR'S ADDRESS

   Joel N. Weber II
   185 Lowell St #2
   Somerville MA 02144-2629
   Email: [email-masked]

NORMATIVE REFERENCES

   [CLARIFICATIONS] To be replaced with the RFC number for draft-ietf-
   krb-wg-kerberos-clarifications

   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
   progress.

   [RFC2026] S. Bradner, RFC2026, BCP 9:  "The Internet Standard Process
   - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best
   Current Practice.

   [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to
   Indicate Requirement Levels", March 1997.

INFORMATIVE REFERENCES

   [SECSH-TRANSPORT] To be replaced with the RFC number for draft-ietf-
   secsh-transport

IPR NOTICES

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

Weber             Kerberos Preauthentication Framework          [Page 8]


draft-weber-krb-wg-kerberos-preauth-00.txt                  Sept 15 2003

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

COPYRIGHT NOTICE

   Copyright (C) The Internet Society 2003. All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Weber             Kerberos Preauthentication Framework          [Page 9]

---

From: Marcus Watts <[email-masked]>
Date: Mon, 15 Sep 2003 21:47:07 -0400

"Joel N. Weber II" <[email-masked]> sent:
...
> Below is a draft that attempts to define a preauthentication framework
...

Random comments based on a quick read.

The DH shared secret to symmetric key conversion is probably not real
workable as is.  String to key usually requires additional parameters
(salt), and may be designed with additional constraints that are not
important here.  For instance, the current AES string to key function
has an idiosyncratic parameter intended to make it arbitrarily
computationally expensive.  Any symmetric encryption algorithm used in
Kerberos 5 already has a function to take the appropriate number of
'random' bytes and turn them into a valid key.  There are also
functions to take arbitrary numbers of bytes and bash them into fixed
size blocks.  The existing string to key functions already use these,
and I think this could use the same back-end stuff.  Sha-1, nfold, and
the existing "random key" interface should work fine.  The remaining
thing to specify is how to take whatever comes out of DH and map it
into a flat byte stream for sha-1; personally I'd rather see this be a
binary byte (`octet') stream and not hexadecimal or base-64.

The min,preferred,max parameters give the ability for a client to force
the KDC to generate many many separate unique public keys, all of which
it must keep for at least half an hour.  Perhaps it would be better if
the server & client each merely specified a min value, and had some
nebulous undefined max value, except that said max value "must" be at
least some N.  The server could then pick the max of those 2 min
values, or degrade into picking some arbitrarily larger key if it
wants.

There's no hook here for using elliptic curve encryption with DH.

There's stuff towards the end about detecting MITM attacks by requiring
the KDC store all its selected public key choices in non-volatile
storage.  I don't see the value to this operational nuisance.  If you
haven't got a strong secret (either a keytab or a certificate) on the
client, you haven't got any way to stop a KDC impostor from collecting
sufficient information on clients to try breaking weak keys.  Telling
users is interesting, although I doubt most will pay any attention to
it.

I had trouble sorting out how where and how most of the later records
were used.  For instance, does PA-AUTH-METHOD appear inside
PA-DH-ENC-REP-ENTRY or somehow encoded inside a PA-DH-ENC-REP?  I think
I'd rather not see subsidiary data elements called pa-data or have
names that start with PA- (I suppose they could all start with
PAPKINIT-).  It would be nice if some of the places where there were
alternatives were enumerated as to what was possible.  It would also be
nice to see some sort of flow diagram for commmon scenarios, also
pseudo-code for how one handles what to do.

The server's public key apparently comes as a "SubjectPublicKeyInfo"
inside a PA-DH-PARAMS-REP-ENTRY, but the client's public key is in a
BIT STRING in PA-DH-ENC-REQ-ENTRY.  Is there some reason these are
different?

Can the key usage values be named something besides "FIXME"?  Perhaps
naming them and having one section that has defined constants that
defines the usage values?

These are just my first thoughts...

				-Marcus

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 15 Sep 2003 23:29:58 -0400

> computationally expensive.

I think the draft said that when you send the Diffie-Hellman group,
you send the set of string to key parameters, too.  So while this is
kind of displeasing aesthetically, I don't think it's an actual problem.

> Any symmetric encryption algorithm used in

So, I'd been completely oblivious to the existance of random-to-key
until just now.

The only reason I bothered with the base64 is that once I'd decided I
thought I wanted to use string-to-key, I noticed that string-to-key
requires UTF-8, which an octet string is not.  (And then making the
session ID involve base64 was not really thought out at all.)

I would like to have the Diffie-Hellman to symmetric key conversion
not explicitly use sha-1.  If you want to go with a design as
conservative as what Schneier and Ferguson's 2003 book recommends, you
need sha-256.  Regardless of whether you really feel a need to be that
conservative, something that doesn't allow you to easily upgrade to
being that conservative isn't general enough, I think.

I don't have a problem with using a cryptosystem that uses sha1,
though, because you can always later replace it with a cryptosystem
that uses sha256, and Schneier and Ferguson are probably being
excessively paranoid.

random-to-key appears to not necessarily have the property of doing
the right thing if your entropy is not well distributed across the
random value you feed to it, but it seems underspecified.  If I feed
it 2048 bits of data, which contain 256 bits of actual entropy in some
random part of the 2048 bits, does it preserve the 256 bits of entropy
if I'm using 256 bit AES?  (Or even the 160 bits that sha1 deals
with?)  And if so, is that a property that the AES spec happens to
have, or a property that kcrypto says that any decent new cryptosystem
will have?

> values, or degrade into picking some arbitrarily larger key if it

What if we say that the max MUST be at least twice the min, or
something like that?  (Note that I don't think ssh group-exchange
worries about this at all.  If you care about this for the ssh case, I
think IETF-wide last call on that hasn't happened yet, but will real
soon now.)

> There's no hook here for using elliptic curve encryption with DH.

That would be because I have no understanding of elliptic curve
encryption, and its current patent status hasn't left me feeling
terribly inspired to change that.  If you want to make a specific
proposal of how to change the protocol to accommodate this, I don't
think I see any reason to being opposed to doing so.

Note that there's always the option of defining, in a couple of years,
a couple of messages to use instead of the messages defined in this
document, to add elliptic curve support.

But we might also want to think about having language that's general
enough that you can use other data types with these messages later,
and perhaps this demonstrates that my usage of BIT STRING for the
client public Diffie-Hellman value is really stupid from an
extensibility perspective.

> users is interesting, although I doubt most will pay any attention to

``and the ones who will pay attention are going to ask their sysadmin
for a strong secret anyway, and are going to get frustrated when their
sysadmin insists that such a strong secret isn't really needed.''

I don't think the working group is ever going to reach unanimous
consensus on this issue.  I personally don't care too much about the
case where you don't have a strong secret, because I think you should
just never let that case happen.  (I'm not checking the numbers
carefully, but I was estimating the numbers in my head a couple days
ago, and I concluded that, assuming my mental math was right, if you
had a machine that could do the same number of decrypts per second as
the quarter of a million dollar machine that the EFF built in 1998,
but your machine was optomized to search the keyspace of likely
passphrases, it ought to take less than a second to do the number of
decrypts needed to crack a key with an effective 30 bits of entropy,
which ought to cover passwords/passphrases up to 10-20 characters.)
However, the working group has people whose requirements include not
having a strong secret, and doing the best we can with that.

As far as I can tell, Sam Hartman has a strong desire to make some
attempt at detecting man in the middle attacks when you don't have a
strong secret, and that is why that text is there.

> PA-DH-ENC-REP-ENTRY or somehow encoded inside a PA-DH-ENC-REP?

PA-DH-ENC-REP is a pa-data type, and PA-DH-ENC-REP-ENTRY is a data
type for a pa-data value.  This is a convention that some other
Kerberos document follows (clarifications?), but I should probably fix
the text to be more explicit and wordy about this.  (IIRC,
clarifications was rather more wordy about this than the text I
wrote.)

> I think
> PAPKINIT-).

I'm curious what others think on this subject.  I think I'm inclined
to believe that the way I wrote this is correct.

But it's ultimately an aesthetic issue that seems like it's not worth
arguing over.  What we call it isn't going to change the bytes of the
wire encoding of the protocol.

> It would be nice if some of the places where there were

OK, I'll try to do something to make this clearer in the next version.

The basic idea is that there are four phases:

1) PA-DH-PARAMS-REQ/PA-DH-PARAMS-REP

2) authenticate the server to the client, if you have a strong secret
to do this with.  all messages in this phase use
PA-DH-ENC-REQ/PA-DH-ENC-REP as the outer wrapper.  inside that, the
messages you might use are PA-KDC-SHARED-SECRET-SIGN-REQ,
PA-KDC-TGT-SIGN-REQ, PA-KDC-SIGN-REP, PA-KDC-PK-SIGN-REQ, and
PA-KDC-PK-SIGN-REP.

this also has the side effect of getting you a PA-AUTH-METHODS
element.  if you don't have a strong secret, you might send an
essentially empty PA-DH-ENC-REQ to get that PA-AUTH-METHODS element.

When you get a PA-AUTH-METHODS element, you also get an ETYPE-INFO2
element if you might use a password or keytab for authentication, and
you also get a PA-SAM-CHALLENGE2 element if you might use SAM.  (I'm
not sure if ETYPE-INFO2 is sometimes needed for SAM to work right, but
that seems more like a SAM issue than a Diffie-Hellman framework
issue.)

You could use PA-NONCE here, but I'm not sure that you need it.

3) authenticate the client to the server.  again, all messages in this
phase use PA-DH-ENC-REQ/PA-DH-ENC-REP as the outer wrapper.  inside
that, you may have ETYPE-INFO2, PA-CLIENT-SHARED-SECRET-SIGN, messages
for SAM, or messages for public key authentication.

You need to end up with a single PA-DH-ENC-REQ element that contains
*all* of the information needed to authenticate the client to the KDC,
so that the KDC doesn't keep state.  You add a single method each
time, as long as the PA-AUTH-METHODS keeps indicating partial success.

You probably want PA-NONCE here so that an attacker can't confuse the
retrying of authentication.

You may have multiple round trips here, if the first attempt to
authenticate is insufficient or wrong.  This is probably the only
phase where it should be expected that you'll get multiple round
trips.

4) AS-REP

If I put something like the text here into the end of the
introduction, does that help?  Are there things this doesn't cover
clearly enough?

> BIT STRING in PA-DH-ENC-REQ-ENTRY.  Is there some reason these are

Yep.  SubjectPublicKeyInfo includes the Diffie-Hellman group.  I don't
see any reason why the client needs to send the group back to the
server, when we have a kvno to reference it.

The KDCDHKeyInfo structure in PKINIT pre-17 has this:

        subjectPublicKey        [0] BIT STRING,
                                    -- Equals public exponent
                                    -- (g^a mod p).
                                    -- INTEGER encoded as payload
                                    -- of BIT STRING.

which I think is what I was being inspired by.

> defines the usage values?

The whole point of FIXME was ``this is a rough draft that doesn't
bother to resolve this.''  I intend to eventually change it to follow
the style of clarifications in that regard.  I'm well aware that
implementing exactly this draft isn't really quite possible.

Sending it when I did seems rather late for hoping that people will be
able to discuss it intelligently at the interim meeting tomorrow
afternoon, and I figured that whether we pick 26 or 69 as the key
usage value in a particular place isn't going to have a significant
effect on those discussions.  All we need to do is make sure that
things that should have different key usage values do in fact get
different key usage values.

> These are just my first thoughts...

Thanks, that was helpful.  (Especially pointing out the things that
are hard to understand on the first reading, so that I know what is
badly written and therefore difficult to understand.  When my brain
has the interaction between the different messages in a well
understood internal form that's only partly English, it's a bit of a
challenge to figure out how well the document gets things across,
especially when I'm being lazy and not thinking about it very hard.)

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Sep 2003 22:49:07 -0700

Perhaps we ought to first formalize pre-auth.  I.e., come up with a way
to describe what a pre-auth type can do, like:

 - Authentication 
    - initial user-to-KDC authentication
       - strength
    - non-initial user-to-KDC authentication
    - KDC-to-user authentication
    - third-party-to-KDC authentication
    - KDC-to-third-party authentication

 - Session key requirements

 - Key exchange
    - PFS
    - anonymous (i.e., subject to MITM)
    - authenticated
    - key strength

 - "return routability test" (like your PA-NONCE but in the other
   direction)

Then we can design a framework around that.

Perhaps we'll want just a set of rules for how to combine pre-auth types
(possibly including existing types) based on, say, order of appearance
in the pa-data typed hole.

Or perhaps we'll want to have a meta-pre-auth container type that
specifies how to combine the actual pre-auth elements contained by it.

Perhaps we'll want to stay with the existing pre-auth types but modify
their semantics when used within the new framework.

Perhaps we'll want to start fresh with completely new pre-auth types.

But even if we design new pre-auth types we shouldn't bind ourselves to
always starting an AS exchange with a DH exchange.  It is possible that
someone will want to have an SRP pre-auth some day - it wouldn't start
with a DH exchange (though one might should argue that an SRP pre-auth
type would likely never need to be used in conjunction with any other
pre-auth type).

We may also need a way for a KDC to indicate to clients what pre-auth
sequences it is willing to accept.

Also, I'm not sure that we need DH group negotiation to be so explicit -
perhaps the server should pick the DH group based on the client's
AS-REQ's ktypes.  And we should make sure that at some point the KDC
sends a signature of items that the client sent unprotected that are
part of any negotiation, and vice versa.  Of course, negotiating DH
groups by proxy using enctypes may not work so well for enctypes with
variable key lengths.

Cheers,

Nico
--