Subject: How to extend Kerberos without breaking it?

From: Richard M Feezel <[email-masked]>
Date: Tue, 4 Dec 2001 13:09:32 -0500

All,

I'm wrestling with an idea that would require a minor extension to the 
Kerberos 5 protocol.

I would like to have the AS_REP contain a value generated by the Kerberos 
authentication service (KDC) placed in both the portion of the message 
readable by the client and in the ticket readable by the server.

When a client subsequently requests a service ticket from the KDC, this extra 
value would be copied into the portion of the response readable by the server 
for which the ticket was requested.  Thus this value, which is a result of 
the original authentication, would be propagated into all tickets issued as a 
result of that authentication.

In other words, the value would be authoritatively produced by the 
KDC and would not be able to be overridden by the client when requesting 
service tickets.  The "authorization data" field does not meet my needs 
because the contents of that field are supplied by the client rather than the 
KDC.  I suppose it would be possible for the KDC to add a data element to the 
authorization data field (and remove any value of this special type that the 
client might try to supply).

It appears straightforward enough to add new fields to the asn.1 encoding of 
requests and responses but can I do this without breaking clients that don't 
know about this extra field?

All thoughts and suggestions would be appreciated,
-- 
Richard M. Feezel
Software Innovations, Inc.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 04 Dec 2001 13:10:38 -0600

The message should be sent to the [email-masked]. 

Will you be at the IETF meeting next week? 

It sounds like you want to do exactly what Microsoft does with the
authorization data type AD-WIN2K-PAC This is generated by the 
KDC, and passed on in all tickets.  I am missing something?

> know about this extra field?

No it is not straight forward, please try and work within the framworks which
is already in place, or is about to be added the the Revisions. 

-- 

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Dec 2001 14:27:05 -0500

Hmmm, the current edition of the revisions doc does not describe where
the ticket extensions go, nor does it describe the TE ASN.1 definition.

IIRC there was to be a new KDC-REP field of type "SEQUENCE OF
TicketExtensions" which is a sequence of two fields, a te-type integer
and a te-data octect string.

The revisions only mentions ticket extensions in the appendix, along
with this comment:

"
(Still pending, Tom Yu's request to change the application codes on KDC
message to indicate which minor rev of the protocol - I think this might
break things, but am not sure).
"

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Derek Atkins <[email-masked]>
Date: 04 Dec 2001 15:52:16 -0500

> readable by the client and in the ticket readable by the server.

You really haven't mentioned what you're trying to accomplish here,
but the session key fits these requirements almost exactly..  The
session key is located in both portions of as AS_REP and TGS_REP (the
part readable by the client and also in the service key).  Similarly,
the client always uses that session key when sending authenticators to
services.

Since you haven't described the _real_ problem you're trying to
solve, I'll just point out that you've been vague. :)

Have a nice day :)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Francois Leclerc <[email-masked]>
Date: Wed, 05 Dec 2001 14:19:19 -0600

Hello,

I would propose the following text for change in the draft:

page 2 chapter 2
From
"    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
    combination with DSA keys as the primary, required mechanism. "

To
"
    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
    combination with DSA and RSA keys as the primary, required 
    mechanisms:

    The server Shall implement RSA and DSA, the client Should 
    implement RSA or DSA."

[Rational] 
Arguments in favor of RSA algorithm in the architecture
. Smartcard & PKI market for RSA is bigger than the DSA 
(US government) market.
. RSA algorithm is the base of SSL use of PKI on the Internet.
. Major SIM (smartcards in phone) vendors have RSA in their
current generation smartcards for WAP phones. There are hundreds of
million of phones and SIMs deployed through out the world.
. PKINIT is to bridge PKIX and KRB-WG. The main public key algorithm 
in use in PKIX is RSA.
. When PKINIT started, RSA was encumbered by a patent, this is
no longer the case.
. This is a work started in CAT WG "Common authentication technology"
not exclusive authentication technologies.

Arguments relative to the "RSA or DSA on the client".
. A DSA javacard applet is likely to use 7Kb out of a 32 Kb FIPS 140-1 
Javacard limiting the number of keys in use in the card.

. In a javacard, space is a premium, the user has to balance between
space for data and space for application. In a corporate environment,
the interest of the user is to keep his/her history of encryption keys;
controlled access to confidential corporate information is the goal.
In a mobile phone market, smartcard space means new customer 
application like banking & purchase.
Better customer service and reduced fraud are the goals.
The choice of smartcard implemented algorithm is a matter of the 
smartcard issuer based on his threat model: 
The burden of interoperability is better suited by the server. 

With Regards,
--FL