Subject: [extensibility 4] ASN.1 module

From: Sam Hartman <[email-masked]>
Date: Thu, 6 Dec 2001 23:54:15 -0500 (EST)

It turns out this will not be the last message.  I don't quite have
the per-message guidelines for message checksumming and using new
types ready yet, will send those out later tonight or early in the
morning.

Not surprisingly, Tom wrote up the ASN.1 module.  He also included a
few open issues with the module:

* Should we use a new tag number for EncTicketPart2, to distinguish
  from EncTicketPart1?  We could alternatively use a flag bit.  It's
  important to do something along these lines, since if we don't,
  someone could undetectably convert a Ticket2 into a Ticket1 by
  removing the checksum wrapper.

[Currently the module is written assuming yes , although  the answer
will be a bit more complex because of the multiple client
implementation problem.  One possibility is to allow a client to
convert a ticket2 into a ticket1 if the cleartext part of the ticket
is trivial.  We still need to think about how this interacts with
UTF8, but hopefully we'll have a write up on this issue soon.
]

* Do we want to do something about the TypedData monstrosity?

[We at least internally believe yes, not sure if that made it into
this module.  The problem is that the claimed contents of the
octet-string hole in KRB-ERROR changed between 1510 and revisions in a
potentially backward incompatible way.  If really no one uses the
edata field besides for preauthentication errors, then this change is
OK, but unless we are absolutely sure of this, then it creates an
interoperability problem and is better handled by means used elsewhere
in the protocol.]

----------

Kerberos5 {
	iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
} DEFINITIONS	::= BEGIN

Int32		::= INTEGER (-2147483648..2147483647)
		    -- signed values representable in 32 bits

UInt32		::= INTEGER (0..4294967295)
		    -- unsigned 32 bit values

Microseconds	::= INTEGER (0..99999)
		    -- microseconds

KerberosString	::= CHOICE {
	general		GeneralString (IA5String),
	...		-- no extension may be sent
			-- to an rfc1510 implementation --
}

Realm		::= KerberosString
PrincipalName	::= SEQUENCE {
	name-type	[0] Int32,
	name-string	[1] SEQUENCE OF KerberosString
}

KerberosTime	::= GeneralizedTime
			-- with no fractional seconds

HostAddress	::= SEQUENCE  {
	addr-type	[0] Int32,
	address		[1] OCTET STRING
}
HostAddresses	::= SEQUENCE OF HostAddress

AuthorizationData	::= SEQUENCE OF SEQUENCE {
	ad-type		[0] Int32,
	ad-data		[1] OCTET STRING
}

PA-DATA		::= SEQUENCE {
	padata-type	[1] Int32,
	padata-value	[2] OCTET STRING
			    -- might be encoded AP-REQ
}

KerberosFlags	::= BIT STRING (SIZE (32..MAX))

EncryptedData	::= SEQUENCE {
	etype	[0] Int32 -- EncryptionType --,
	kvno	[1] INTEGER OPTIONAL,
	cipher	[2] OCTET STRING -- ciphertext
}

EncryptionKey	::= SEQUENCE {
	keytype		[0] Int32 -- actually encryption type --,
	keyvalue	[1] OCTET STRING
}

Checksum	::= SEQUENCE {
	cksumtype	[0] Int32,
	checksum	[1] OCTET STRING
}

-- handy parameterized type for wrapping authenticated plaintext
Signed{InnerType}	::= SEQUENCE {
        cksum   [0] Checksum OPTIONAL,
        inner	[1] InnerType,
        ...
}

Ticket		::= CHOICE {
        ticket1		[APPLICATION 1] TicketCommon
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
        ticket2		[APPLICATION 4] Signed{TicketCommon}
}

TicketCommon	::= SEQUENCE {
	tkt-vno		[0] INTEGER,
	realm		[1] Realm,
	sname		[2] PrincipalName,
	enc-part	[3] EncryptedData -- EncTicketPart --,
	extensions	[4] TicketExtensions OPTIONAL,
	...
}

-- Encrypted part of ticket
EncTicketPart		::= CHOICE {
	encTicketPart1	[APPLICATION 3] EncTicketPartCommon,
	encTicketPart2	[APPLICATION 5] EncTicketPartCommon
				-- This new version must be used
				-- inside the enc-part of the
				-- ticket2 alternative of Ticket.
				-- Possibly use a flag instead?
}

EncTicketPartCommon	::= SEQUENCE {
	flags			[0] TicketFlags,
	key			[1] EncryptionKey,
	crealm			[2] Realm,
	cname			[3] PrincipalName,
	transited		[4] TransitedEncoding,
	authtime		[5] KerberosTime,
	starttime		[6] KerberosTime OPTIONAL,
	endtime			[7] KerberosTime,
	renew-till		[8] KerberosTime OPTIONAL,
	caddr			[9] HostAddresses OPTIONAL,
	authorization-data	[10] AuthorizationData OPTIONAL,
	...			-- ASN.1 extensions must be excluded
				-- when issued for a rfc1510 service
}

-- encoded Transited field
TransitedEncoding	::= SEQUENCE {
	tr-type		[0] Int32 -- must be registered --,
	contents	[1] OCTET STRING
}

-- ticket extensions: for Ticket2 only
TicketExtensions	::= SEQUENCE OF SEQUENCE {
	te-type		[0] Int32,
	te-data		[1] OCTET STRING
}

TicketFlags	::= KerberosFlags
	-- reserved(0),
	-- forwardable(1),
	-- forwarded(2),
	-- proxiable(3),
	-- proxy(4),
	-- may-postdate(5),
	-- postdated(6),
	-- invalid(7),
	-- renewable(8),
	-- initial(9),
	-- pre-authent(10),
	-- hw-authent(11),
	-- transited-policy-checked(12),
	-- ok-as-delegate(13),
	-- anonymous(14),
	-- cksummed-ticket(15)

AS-REQ	::= CHOICE {
	as-req1		[APPLICATION 10] KDC-REQ-COMMON
				(WITH COMPONENTS {
					...,
					req-body (WITH COMPONENTS {
						...,
						till PRESENT
						-- also excluding
						-- ASN.1 extensions
					})
					-- also excluding
					-- ASN.1 extensions
				}),
	as-req2		[APPLICATION 6]  Signed{KDC-REQ-COMMON}
				(WITH COMPONENTS {
					...,
					cksum ABSENT
				})
}
TGS-REQ	::= CHOICE {
	tgs-req1	[APPLICATION 12] KDC-REQ-COMMON
				(WITH COMPONENTS {
					...,
					req-body (WITH COMPONENTS {
						...,
						till PRESENT
						-- also excluding
						-- ASN.1 extensions
					})
					-- also excluding
					-- ASN.1 extensions
				}),
	tgs-req2	[APPLICATION 8]  Signed{KDC-REQ-COMMON}
}

KDC-REQ-COMMON	::= SEQUENCE {
	pvno		[1] INTEGER,
	msg-type	[2] INTEGER,
	padata		[3] SEQUENCE OF PA-DATA OPTIONAL,
	req-body	[4] KDC-REQ-BODY,
	...		-- The usefulness of this extension marker
			-- is debatable, as there is one in req-body.
}

KDC-REQ-BODY	::= SEQUENCE {
	kdc-options		[0] KDCOptions,
	cname			[1] PrincipalName OPTIONAL
				    -- Used only in AS-REQ --,
	realm			[2] Realm
				    -- Server's realm
				    -- Also client's in AS-REQ --,
	sname			[3] PrincipalName OPTIONAL,
	from			[4] KerberosTime OPTIONAL,
	till			[5] KerberosTime OPTIONAL
				    -- was required in rfc1510;
				    -- still required for compat versions
				    -- of messages --,
	rtime			[6] KerberosTime OPTIONAL,
	nonce			[7] INTEGER,
	etype			[8] SEQUENCE OF Int32 -- EncryptionType
				    -- in preference order --,
	addresses		[9] HostAddresses OPTIONAL,
	enc-authorization-data	[10] EncryptedData OPTIONAL
				     -- Encrypted AuthorizationData
				     -- encoding --,
	additional-tickets	[11] SEQUENCE OF Ticket OPTIONAL,
	...
}

KDCOptions	::= KerberosFlags
	-- reserved(0),
	-- forwardable(1),
	-- forwarded(2),
	-- proxiable(3),
	-- proxy(4),
	-- allow-postdate(5),
	-- postdated(6),
	-- unused7(7),
	-- renewable(8),
	-- unused9(9),
	-- unused10(10),
	-- unused11(11),
	-- unused12(12),
	-- unused13(13),
	-- requestanonymous(14), 
	-- canonicalize(15), 
	-- disable-transited-check(26),
	-- renewable-ok(27),
	-- enc-tkt-in-skey(28),
	-- renew(30),
	-- validate(31)

AS-REP		::= CHOICE {
	as-rep1		[APPLICATION 11] KDC-REP-COMMON
				(WITH COMPONENTS {
					...,
					req-cksum ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	as-rep2		[APPLICATION 7]  Signed{KDC-REP-COMMON}
				(WITH COMPONENTS {
					...,
					req-cksum PRESENT
				})
}
TGS-REP		::= CHOICE {
	tgs-rep1	[APPLICATION 11] KDC-REP-COMMON
				(WITH COMPONENTS {
					...,
					req-cksum ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	tgs-rep2	[APPLICATION 9]  Signed{KDC-REP-COMMON}
				(WITH COMPONENTS {
					...,
					req-cksum ABSENT
				})
}

KDC-REP-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	padata		[2] SEQUENCE OF PA-DATA OPTIONAL,
	crealm		[3] Realm,
	cname		[4] PrincipalName,
	ticket		[5] Ticket,
	enc-part	[6] EncryptedData
			    -- EncASREpPart or EncTGSRepPart --,
	req-cksum	[7] Checksum OPTIONAL,
	...
}

EncASRepPart	::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart	::= [APPLICATION 26] EncKDCRepPart

EncKDCRepPart	::= SEQUENCE {
	key		[0] EncryptionKey,
	last-req	[1] LastReq,
	nonce		[2] INTEGER,
	key-expiration	[3] KerberosTime OPTIONAL,
	flags		[4] TicketFlags,
	authtime	[5] KerberosTime,
	starttime	[6] KerberosTime OPTIONAL,
	endtime		[7] KerberosTime,
	renew-till	[8] KerberosTime OPTIONAL,
	srealm		[9] Realm,
	sname		[10] PrincipalName,
	caddr		[11] HostAddresses OPTIONAL,
	...		-- ASN.1 extensions must be excluded
			-- when sending to rfc1510 implementation
}

LastReq		::=	SEQUENCE OF SEQUENCE {
	lr-type		[0] Int32,
	lr-value	[1] KerberosTime
}

AP-REQ		::= CHOICE {
	ap-req1		[APPLICATION 14] AP-REQ-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-req2		[APPLICATION 18] Signed{AP-REQ-COMMON}
}

AP-REQ-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	ap-options	[2] APOptions,
	ticket		[3] Ticket,
	authenticator	[4] EncryptedData -- Authenticator --,
	extensions	[5] ApReqExtensions OPTIONAL,
	...
}

ApReqExtensions	::= SEQUENCE OF SEQUENCE {
	apRepExt-Type	[0] Int32,
	apRepExt-Data	[1] OCTET STRING
}

APOptions	::= KerberosFlags
	-- reserved(0),
	-- use-session-key(1),
	-- mutual-required(2)

-- Unencrypted authenticator
Authenticator	::= [APPLICATION 2] SEQUENCE  {
	authenticator-vno	[0] INTEGER,
	crealm			[1] Realm,
	cname			[2] PrincipalName,
	cksum			[3] Checksum OPTIONAL,
	cusec			[4] Microseconds,
	ctime			[5] KerberosTime,
	subkey			[6] EncryptionKey OPTIONAL,
	seq-number		[7] UInt32 OPTIONAL,
	authorization-data	[8] AuthorizationData OPTIONAL
}

AP-REP		::= CHOICE {
	ap-rep1		[APPLICATION 15] AP-REP-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-rep2		[APPLICATION 19] Signed{AP-REP-COMMON}
}

AP-REP-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	enc-part	[2] EncryptedData -- EncAPRepPart --,
	extensions	[3] ApRepExtensions OPTIONAL,
	...
}

ApRepExtensions	::= SEQUENCE OF SEQUENCE {
	apRepExt-Type	[0] Int32,
	apRepExt-Data	[1] OCTET STRING
}

EncAPRepPart	::= [APPLICATION 27] SEQUENCE {
	ctime		[0] KerberosTime,
	cusec		[1] Microseconds,
	subkey		[2] EncryptionKey OPTIONAL,
	seq-number	[3] UInt32 OPTIONAL
}

KRB-SAFE	::= [APPLICATION 20] SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	safe-body	[2] KRB-SAFE-BODY,
	cksum		[3] Checksum,
	...		-- ASN.1 extensions must be excluded
			-- when sending to rfc1510 implementations
}

KRB-SAFE-BODY	::= SEQUENCE {
	user-data	[0] OCTET STRING,
	timestamp	[1] KerberosTime OPTIONAL,
	usec		[2] Microseconds OPTIONAL,
	seq-number	[3] UInt32 OPTIONAL,
	s-address	[4] HostAddress,
	r-address	[5] HostAddress OPTIONAL
}

KRB-PRIV	::= [APPLICATION 21] SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	enc-part	[3] EncryptedData -- EncKrbPrivPart --,
	...
}

EncKrbPrivPart	::= [APPLICATION 28] SEQUENCE {
	user-data	[0] OCTET STRING,
	timestamp	[1] KerberosTime OPTIONAL,
	usec		[2] Microseconds OPTIONAL,
	seq-number	[3] UInt32 OPTIONAL,
	s-address	[4] HostAddress -- sender's addr --,
	r-address	[5] HostAddress OPTIONAL -- recip's addr --,
	...		-- ASN.1 extensions must be excluded
			-- when sending to rfc1510 implementations
}

KRB-CRED	::= CHOICE {
	krb-cred1	[APPLICATION 22] KRB-CRED-COMMON
				-- excluding ASN.1 extensions --,
	krb-cred2	[APPLICATION 17] Signed{KRB-CRED-COMMON}
}

KRB-CRED-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	tickets		[2] SEQUENCE OF Ticket,
	enc-part	[3] EncryptedData -- EncKrbCredPart --,
	...
}

EncKrbCredPart	::= [APPLICATION 29] SEQUENCE {
	ticket-info	[0] SEQUENCE OF KrbCredInfo,
	nonce		[1] INTEGER OPTIONAL,
	timestamp	[2] KerberosTime OPTIONAL,
	usec		[3] Microseconds OPTIONAL,
	s-address	[4] HostAddress OPTIONAL,
	r-address	[5] HostAddress OPTIONAL
}

KrbCredInfo	::= SEQUENCE {
	key		[0] EncryptionKey,
	prealm		[1] Realm OPTIONAL,
	pname		[2] PrincipalName OPTIONAL,
	flags		[3] TicketFlags OPTIONAL,
	authtime	[4] KerberosTime OPTIONAL,
	starttime	[5] KerberosTime OPTIONAL,
	endtime		[6] KerberosTime OPTIONAL,
	renew-till	[7] KerberosTime OPTIONAL,
	srealm		[8] Realm OPTIONAL,
	sname		[9] PrincipalName OPTIONAL,
	caddr		[10] HostAddresses OPTIONAL
}

TGT-REQ		::= [APPLICATION 16] SEQUENCE {
        pvno            [0] INTEGER,
        msg-type        [1] INTEGER,
        sname           [2] PrincipalName OPTIONAL,
        srealm          [3] Realm OPTIONAL
}

KRB-ERROR	::= CHOICE {
	krb-error1	[APPLICATION 30] KRB-ERROR-COMMON
				-- excluding ASN.1 extensions --,
	krb-error2	[APPLICATION 23] Signed{KRB-ERROR-COMMON}
}

KRB-ERROR-COMMON ::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	ctime		[2] KerberosTime OPTIONAL,
	cusec		[3] Microseconds OPTIONAL,
	stime		[4] KerberosTime,
	susec		[5] Microseconds,
	error-code	[6] Int32,
	crealm		[7] Realm OPTIONAL,
	cname		[8] PrincipalName OPTIONAL,
	realm		[9] Realm -- Correct realm --,
	sname		[10] PrincipalName -- Correct name --,
	e-text		[11] KerberosString OPTIONAL,
	e-data		[12] OCTET STRING OPTIONAL,
	...
}

-- preauth stuff follows

PA-ENC-TIMESTAMP	::= EncryptedData -- encrypted PA-ENC-TS-ENC
PA-ENC-TS-ENC		::= SEQUENCE {
	patimestamp	[0] KerberosTime -- client's time --,
	pausec		[1] Microseconds OPTIONAL
}

-- remove PA-ENC-TIMESTAMP2?

PA-ENC-TIMESTAMP2	::= EncryptedData -- encrypted PA-ENC-TS2-ENC
PA-ENC-TS2-ENC		::= SEQUENCE {
	patimestamp	[0] KerberosTime -- client's time --,
	pausec		[1] Microseconds OPTIONAL,
	pachecksum	[2] Checksum OPTIONAL
			    -- keyed checksum of KDC-REQ-BODY
}

PA-AS-REQ		::= as-req2<AS-REQ

END

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Dec 2001 09:32:14 -0500

What is TGT-REQ? It's defined but not referenced.

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: Sam Hartman <[email-masked]>
Date: 07 Dec 2001 09:49:43 -0500

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

    Nicolas> What is TGT-REQ? It's defined but not referenced.  Nico

A message for user 2 user; it's something Tom has been tossing around
and has discussed at a few IETF meetings.  IT allows you to request a
TGT from server to do u2u.

It may be useful in handling some of the issues John and you brought
up; I hope to have comments on that today.

If it doesn't end up being necessary and the WG doesn't want it in
revisions we can remove it or move it to another document as
appropriate.

---

From: Richard M Feezel <[email-masked]>
Date: Fri, 7 Dec 2001 11:57:14 -0500

I've looked through the draft and don't see mention of AES.

Isn't this a good time to specify an encryption type so that implementers at 
least have the option?  Especially in light of the following announcement.

-- 
Richard M. Feezel
Software Innovations, Inc.

High hopes for new 256-bit encryption 
Reuters 
December 5, 2001

WASHINGTON-- The U.S. government has updated its encryption standard for 
computer transmissions, replacing an aging standard first put in place in 
1977, the Commerce Department said on Tuesday.

When the new Advanced Encryption Standard, or AES, is adopted by the 
government and private businesses, it should significantly strengthen the 
privacy and security of a wide variety of computer transactions, from 
cash-machine withdrawals to Internet shopping to sensitive e-mails.

"The AES will help the nation protect its critical information 
infrastructures and ensure privacy for personal information about individual 
Americans," Secretary of Commerce Don Evans said in a press release.

Scientists at the Commerce Department's National Institute of Standards and 
Technology (NIST) tested various mathematical formulas for four years before 
settling on one developed by two Belgian scientists, Joan Daemen and Vincent 
Rijmen, Commerce said.

The winning formula, called Rijndael, scrambles communications by generating 
random key numbers 128, 192 or 256 digits long.

A 128-bit key size can create 340 undecillion different possible 
combinations, or 340 followed by 36 zeros. A 256-key size allows for a total 
combination set of 11 followed by 76 zeros.

By comparison, the old Data Encryption Standard, or DES, used keys that were 
56 digits long, allowing for a total combination set of 72 followed by 15 
zeros.

Specialized computers can now crack a DES key after several hours of number 
crunching, NIST said on its Web site.

Assuming that someone built a machine that could crack a DES key in one 
second, it would still take that machine 149 trillion years to crack a 
128-bit key, according to NIST.

The government will allow AES-enabled software to travel beyond its borders, 
NIST said. The government for years imposed export limits on the strength of 
encryption programs before easing them in the 1990s. 

_______________________________________________________________
Copyright (c) 1996-2001 Reuters Limited. All rights reserved. Republication 
or redistribution of Reuters content is expressly prohibited without the 
prior written consent of Reuters. Reuters shall not be liable for any errors 
or delays in the content, or for any actions taken in reliance thereon.

-- 
Richard M. Feezel
Software Innovations, Inc.

---

From: Ken Raeburn <[email-masked]>
Date: 07 Dec 2001 14:52:09 -0500

> I've looked through the draft and don't see mention of AES.

It's in the works.  See draft-raeburn-krb-rijndael-krb-01.txt.  There
are still some open questions.  Whether it'll be incorporated into
kerberos-revisions or not is also an open question, dependent on how
quickly each specification nears completion.

Ken

---

From: Marcus Watts <[email-masked]>
Date: Sat, 08 Dec 2001 18:45:41 -0500

> I've looked through the draft and don't see mention of AES.

Ken Raeburn <[email-masked]> replied
> quickly each specification nears completion.

I believe the open issues are:

(1) string to key -- how many iterations, and should it be variable?
	I think that 1 or 2 iterations is fine, and a large number
		is undesirable.
	John Brezak wants to see some large number, sufficient to add
		"1 second of delay" on the client, but is willing
		to invent some tuning method (using pa-etype-info)
		to make it variable, and is apparently even willing
		to make it depend on the type of device used (but
		what if one moves back & forth?)
	Paul Leach suggested there were better ways ways, such as
		using a local strong secret, to protect a weak
		password.
(2) hash algorithm.  Raeburn's draft recommends a hash twice the
	size of the key.  Doubling the hash size is useful when
	using a digest straight, to avoid the birthday attack.
	Doubling is not necessary, and in some respects undesirable
	when using an hmac.  It may be sufficient to use sha-1 or
	sha256 and to truncate to the block size.
(3) there's some other minor tuning that could be done to the key
	derivation function, basically to avoid certain sorts
	of collisions.  (distinguishing between [email-masked] and [email-masked]
	in the salt, passing crypto identifier and output length into hash.
	Pkcs5 itself isn't so smart about pws > hash size.)
(4) I'd like to see ciphertext stealing.  I haven't seen anyone
	else express an opinion on this, either way.
(5) It may be reasonable to drop the 384 & 512 bit variants, and
	concentrate on standardizing the 128 bit variant.
	MIT k5 may need an additional number for the "raw" crypto
	family, but it would be best to avoid this.

Other minorness:
supplying 64 and 65 character sample vectors.
raeburn actually describes rijndael, serpent & twofish.  Is
	it necessary or desirable to specify all 3 at once?
that whole telnet mess.
gssapi constants should be defined too.

I don't know if there are any other open issues with AES/k5, these are
just the ones I remember.

I don't remember seeing anything past what I posted.  People may
have been distracted by other events.  

Raeburn had asked about cell phone computing power.  I found
these in an hour of web surfing:
	http://www22.verizon.com/About/Community/learningcenter/Articles/article/?articleId=1034
		says the DSP is "about 40 mips".  The DSP is not what would
		be doing the pw hash though.
	http://www.zdnet.com/zdnn/stories/news/0,4586,5097115,00.html
		says some cell phones have ARM microprocessors, but no
		mention of clock speed.  Does support Java, which
		has its own performance issues.
	http://www.3gnewsroom.com/3g_news/jul_01/news_0946.shtml
		another mention of ARM.  This is "future" stuff though.
	http://mobilz.h1.ru/per.htm
		Actually describe GSM phone (but keeps mentioning Startac).
		Motorola Startac has 68332/338 MCU, at 13 Mhz.  68332 is
		a 16-bit chip, apparently has 32-bit core though.  1 M rom
		(flash).  64K ram.  8K EEPROM.
	http://www.tele-servizi.com/janus/hardware.html
		More on Startac.
	http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MC68332&nodeId=02M0ylfWcbfM0yqVyDvb
		describes 68332 in more detail
(I have a startac, which I think is a newer lower-end dual-band digital phone.)

I think, in very rough terms, a cell phone, or at least a Startac,
could be compared to a Macintosh IIci or a Sun-3/75 in terms of speed.
I actually have one of each sitting in my office.  They're not powered
up, because we moved and I haven't gotten around to doing anything with
them.  If anyone is really curious, though, I could get numbers easy
enough.  As I recall, they're not blazingly fast.

I also promised some performance numbers.  I'll post those separately.

				-Marcus Watts
				UM ITCS Umich Systems Group

---

From: Ken Raeburn <[email-masked]>
Date: 09 Dec 2001 18:59:32 -0500

> I believe the open issues are:

Good summary, though you touched on an issue or two I hadn't been
aware of myself....  :-)

> (1) string to key -- how many iterations, and should it be variable?

Variable is difficult.  A preauth method could control it, but that
wreaks havoc on the crypto abstraction we're proposing in section 6 of
kerberos-revisions, where the passphrase and salt string are currently
the *only* inputs.

> 	I think that 1 or 2 iterations is fine, and a large number

Adding a small number of iterations of an HMAC, it seems to me, should
qualitatively improve the resistance to attacks that reverse some
rounds of the hash function by itself.  A large number is probably
only useful for increasing the cost of the attacker processing a large
number of pass phrases.

> 		using a local strong secret, to protect a weak

Definitely, and we should be using some of them.

> 	sha256 and to truncate to the block size.

I'm curious why it's undesirable with an HMAC.

My main reason for it was the fact that NIST was proposing them to be
used in conjunction with AES.

> 	in the salt, passing crypto identifier and output length into hash.

Easy enough to do, by changing the pass phrase and salt values fed to
the PKCS5 function.  How about, just off the top of my head:

	pkcs5passwd = length(pw) | pw
	pkcs5salt = enctype | length(salt) | salt

?

> 	Pkcs5 itself isn't so smart about pws > hash size.)

I doubt we'll have many cases of that in the near future, but we
shouldn't be doing anything stupid in that regard either.

> 	else express an opinion on this, either way.

Looks interesting, especially considering AES has a larger block size
than we've had with DES.  We still get some expansion because of the
hash value, but it wouldn't be quite so big.

I think this'll still fit fine within the simplified-profile from
kerberos-revisions section 6.  I'll look into it further.

> 	concentrate on standardizing the 128 bit variant.

I'm already planning to drop the middle size.  Doing both small and
large is pretty easy, once we're doing one of them in the first place.

> 	family, but it would be best to avoid this.

For internal uses, we still might, we'll see...  they don't come out
of the officially allocated number space though.

> 	it necessary or desirable to specify all 3 at once?

Not necessary, no.
Useful, perhaps, to demonstrate that random block ciphers (that are
similar in form to des3-cbc) can be plugged in.

> that whole telnet mess.

TLS with Kerberos mechanism?

> gssapi constants should be defined too.

IMHO, no.  A new mechanism should be designed that uses KRB-PRIV and
KRB-SAFE messages and avoids explicitly specifying the enctype info
per message.  If quality of protection needs to be specified, do that
as part of the (sub)session key selection.

> have been distracted by other events.  

Yeah, the non-crypto bits of kerberos-revisions have been more
high-profile lately.  I do still have some work to do on the crypto
bits, I've recently discovered....

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 10:08:35 -0500

Thoughts:

 - How useful is the Signed{InnerType} thing?

   After all, it doesn't provide an encrypted checksum, just a
   checksum, so it appears to be a misnomer.

 - I was thinking this weekend of something that turns out to be
   mentioned in revisions and in the ASN.1 below: a new
   PA-ENC-TIMESTAMP/PA-ENC-TS-ENC that contains an encrypted checksum
   field. It can provide all the necessary protection to AS-REQs.

   The authenticator checksum field of embedded AP-REQ-BODYs in PA-TGS-REQs
   provides all the necessary protection to TGS-REQ-BODYs.

   I think this is a rule well worth establishing: that PA-DATA should
   provide protection for KDC-REQ-BODY.

 - And the thought occurs that it's worth reorganizing KDC-REP such that
   all cleartext fields other than the app-tag/pvno/msg-type/pa-data are
   in a separate KDC-REP-BODY. Then we can have a general rule that
   PA-DATA should provide protection for KDC-REP-BODY. Think about name
   canonicalization...

 - The new PA-ENC-TIMESTAMP2/PA-ENC-TS2-ENC should be present in AS-REPs
   as well to provide protection to the AS-REP-BODY that I posit.

 - Between the new PA-ENC-TIMESTAMP2/PA-ENC-TS2-ENC and the existing
   PA-TGS-REQ then there would be a general solution for protecting KDC
   exchanges.

 - So no, don't remove PA-ENC-TIMESTAMP2/PA-ENC-TS2-ENC!!

 - PA-TGS-REQ, which should really be called PA-AP-REQ, could also be
   used, as I've described in the thread with Matt Crawford about
   draft-ietf-krb-wg-hw-auth-01, to provide authentication of the AS
   to a host when authenticating users.

 - The AP-REQ options and extensions should really be in a separate
   AP-REQ-BODY structure and a new checksum field should be added to the
   authenticator to protect this new AP-REQ-BODY.

 - KRB-ERROR also needs to be restructured in this way and should
   carry optional PA-DATA outside its body so that PA-DATA could protect
   the cleartext body of the error. And there should be an optional
   encrypted checksum outside the body as well. The optional PA-DATA
   would be used in errors in response to KDC-REQs and the optional
   checksum would be used in errors in response AP-REQs.

 - With such changes the Signed{InnerType} thing would be obviated, no?

Thoughts?

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 11:06:48 -0500

A few more thoughts added below. And my apologies for quoting all of the
original...

>    authenticator to protect this new AP-REQ-BODY.

 - AP-REP should also be reorganized like so and should bear an
   encrypted checksum field for the AP-REP-BODY.

>    checksum would be used in errors in response AP-REQs.

 - Clearly there would be instances where a KRB-ERROR could not carry
   any PA datum or encrypted checksum to protect its body. That's
   life...

>  - With such changes the Signed{InnerType} thing would be obviated, no?

 - A variant of PA-ENC-TIMESTAMP could be added to implement Paul
   Leach's idea of using a strong host key along with a user key for
   password protection.

   Such a PA type would contain a sequence of

   {principal name, realm name, kvno}

   to name the principals whose keys are being used. It would also
   include a nonce, perhaps.

   A key mixing function would be defined whose inputs are the
   keys/enc-types in question, plus the nonce and an enc-type, and
   whose output would be the key to use for encrypting the timestamp.

   A possibility for a key mixing function might be: concatenate the
   keys in network byte order in the same order as the principals listed
   in the pa datum, add in the nonce, hash.

   This combined with the KDC including the same PA type in the AS-REP
   would allow hosts to authenticate the AS to them as well as to the
   users logging in in one go.

   This might all be done in the name of the same new, extensible
   PA-ENC-TIMESTAMP2.

 - The use of the such a PA-ENC-TIMESTAMP2 as well as for the use of
   PA-TGS-REQ/REP to authenticate the AS to users' client hosts, could
   be implemented via a local daemon on each host that accepts an
   AS-REQ-BODY over IPC and returns the relevant PA data. This same
   daemon would also accept AS-REPs and would validate them and their
   PA-DATA...

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 13:25:24 -0500

On Mon, Dec 10, 2001 at 01:16:48PM -0500, Sam Hartman wrote:
>     Nicolas> Thoughts: - How useful is the Signed{InnerType} thing?
> 
>     Nicolas>    After all, it doesn't provide an encrypted checksum,
>     Nicolas> just a checksum, so it appears to be a misnomer.
> 
> It provides a keyed MAC.
> 
> I think this is preferable to doing hackish things like having padata
> include protection for the kdc-req-body because you can solve the
> problem generally once with the signed type rather than solving it
> again and again with each padata.

Where does the key come from?

Nico

---

From: Sam Hartman <[email-masked]>
Date: 10 Dec 2001 13:16:48 -0500

It provides a keyed MAC.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 13:55:57 -0500

> Where does the key come from?

In fact, I don't think it's remotely hackish to have padata take care of
protecting the kdc-req-body. The padata are related, no, must be related
to the source of the key with which to key the Signed{InnerType}
checksum - if you're using some hardware auth that provides key material
you'd want to use that for the Signed{InnerType} key.

Well, how does one specify the source for a key for Signed{InnerType},
particularly if there may be more than one such keys?

So certainly having the key, for KDC exchanges, come from pa-data, is
good (a principal's long term key could be said to be associated with
PA-ENC-TIMESTAMP). And for AP exchanges the key comes from the ticket
or authenticator, if there's a sub-key.

And no, not all pa-data would have to be able to provide protection for
the kdc-req-body. I was not suggesting that. I was merely suggesting
that where pa-data are used that cannot provide protection then the KDC
exchange could not be protected any more than it is now.

Now, I do buy the argument that using Signed{InnerType} involves fewer
changes to the protocol and existing code. Yes, this is clear. But with
Signed{InnerType} the source of the key is unclear, to me anyways (and
if I'm missing something just clue me in please).

Cheers,

Nico

---

From: Tom Yu <[email-masked]>
Date: 10 Dec 2001 15:16:44 -0500

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

Nicolas> In fact, I don't think it's remotely hackish to have padata
Nicolas> take care of protecting the kdc-req-body. The padata are
Nicolas> related, no, must be related to the source of the key with
Nicolas> which to key the Signed{InnerType} checksum - if you're using
Nicolas> some hardware auth that provides key material you'd want to
Nicolas> use that for the Signed{InnerType} key.

If you wrap the kdc-req with a signature, you can authenticate
the actual set of padata sent to the KDC.

Nicolas> Well, how does one specify the source for a key for
Nicolas> Signed{InnerType}, particularly if there may be more than one
Nicolas> such keys?

Sam has sent some guidelines about choosing keys for signing the
signed types.

[...]

Nicolas> And no, not all pa-data would have to be able to provide
Nicolas> protection for the kdc-req-body. I was not suggesting that. I
Nicolas> was merely suggesting that where pa-data are used that cannot
Nicolas> provide protection then the KDC exchange could not be
Nicolas> protected any more than it is now.

The wrapping of kdc-req rather than using padata to checksum
kdc-req-body is so that the entire kdc-req, including padata that may
be removed from the kdc-req by an attacker, can be protected.

Nicolas> Now, I do buy the argument that using Signed{InnerType}
Nicolas> involves fewer changes to the protocol and existing
Nicolas> code. Yes, this is clear. But with Signed{InnerType} the
Nicolas> source of the key is unclear, to me anyways (and if I'm
Nicolas> missing something just clue me in please).

The source of the key is always unclear if you do not specify it.
Uses of Signed{InnerType} will of course be accompanied by text
explaining how to choose the key with which to authenticate the
InnerType.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 15:29:18 -0500

> the actual set of padata sent to the KDC.

True. This is definitely convincing.

> Sam has sent some guidelines about choosing keys for signing the

I'll look again.

[...]

> explaining how to choose the key with which to authenticate the

Hmmm, given a situation where multiple keys are available, can one
always be chosen algorythmically and in a way that will survive future
extensions?

Perhaps Signed{InnerType} should include a hint? For KDC exchanges the
hint might be an optional pre-auth type identifier... No?

Cheers,

Nico

---

From: Tom Yu <[email-masked]>
Date: 10 Dec 2001 15:44:08 -0500

>> explaining how to choose the key with which to authenticate the

Nicolas> Hmmm, given a situation where multiple keys are available,
Nicolas> can one always be chosen algorythmically and in a way that
Nicolas> will survive future extensions?

We can very likely make the case that future extensions that perturb
the signature-key selection algorithm for Signed{InnerType} must go
through a revision of the protocol framework.

Nicolas> Perhaps Signed{InnerType} should include a hint? For KDC
Nicolas> exchanges the hint might be an optional pre-auth type
Nicolas> identifier... No?

Maybe... but specifying it in a reasonable way without an excess of
complexity seems difficult.  You'd essentially end up creating two
sorts of padata, one that is protected by the Signed{InnerType}, and
one that is not.  I'm not sure we want this level of complexity.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 15:54:46 -0500

> through a revision of the protocol framework.

Hmmm, if, for KDC exchanges, the Signed{InnerType} is related to a
padata element (it is - for AS exchanges with PA-ENC-TIMESTAMP the key
is the long-term key, for TGS exchanges the key comes from the
authenticator in the PA-TGS-REQ) then I would prefer to have the
Signed{InnerType} indicate this. To begin with you lose nothing, and in
the future you gain extensibility.

I'm thinking of my impersonation proposal (I've yet to submit a draft),
where I make use of more than one PA element which could provide a key
for Signed{InnerType}.

?

I was merely suggesting adding an optional Int32 field to
Signed{InnerType} to indicate which padata element from the protected
KDC-REQ/KDC-REP to use for the key for the Signed{InnerType}.cksum. How
is this too complex? Particularly considering that it would be
optional?

That Int32 would either be an index into the padata or a padata-type;
but assuming no more than one element of a given PA type is probably
too limiting, so I would make that Int32 an index into padata...

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: 10 Dec 2001 17:46:53 -0500

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

    Nicolas> Hmmm, given a situation where multiple keys are
    Nicolas> available, can one always be chosen algorythmically and
    Nicolas> in a way that will survive future extensions?
    >>  We can very likely make the case that future extensions that
    >> perturb the signature-key selection algorithm for
    >> Signed{InnerType} must go through a revision of the protocol
    >> framework.

    Nicolas> Hmmm, if, for KDC exchanges, the Signed{InnerType} is
    Nicolas> related to a padata element (it is - for AS exchanges
    Nicolas> with PA-ENC-TIMESTAMP the key is the long-term key, for

No, it is not.  Please read the text sent to the WG; for each message
(including AS-REQ) the checksumming guidelines unambiguously specify
when to include the checksum and what key to use.  Your text clearly
indicates you have not looked at those guidelines.

If after reading the guidelines you still have questions, perhaps we
should deal with those in a face-to-face meeting.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 Dec 2001 23:27:20 -0500

> should deal with those in a face-to-face meeting.

Yes, I did miss read those guidelines and I did miss it -- I'd failed to
understand just how Signed{InnerType} was meant to work.

Ignore the preceding.

Nico