Subject: RE: How about AES support?

From: "John Brezak" <[email-masked]>
Date: Mon, 10 Dec 2001 18:11:35 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Monday, December 10, 2001 1:45 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: How about AES support?
> 
> 
> "John Brezak" <[email-masked]> writes:
> > It really is up to the enctype's string-to-key to define what salts 
> > are used and what they contain.
> 
> But you're talking about constraints imposed by the enctype 
> specification on what salt strings can be used, which I don't 
> like. Whether that's acceptable is something we need to 
> decide -- and if so, what do we need to add to section 6 to 
> provide for it?

I think we need to discuss this. There are enctypes that have a
completely different
notion of "salt" with regard to user secret to key generation. A
generalization
of "salt" to include enctype specific data would enable this mechanisms.

> 
> > On these personal devices, wouldn't you just precompute the 
> key when 
> > the user's password is entered and use that for most cases?
> 
> I would probably enter it only when I needed it, and write my 
> software to wipe it as soon as I was done with it.  Other 
> people may be happy with encrypting the key in a scheme that 
> is less CPU-intensive (but then leads to easier compromise if 
> the device is stolen).

I suspect that you will find these things to be constant on personal
devices:

1) The user will be given the option to save the secret on the device
2) Users who do not save the secret will pick a simple password to enter
on
that particular device.

> Ken

---

From: Ken Raeburn <[email-masked]>
Date: 18 Dec 2001 11:29:39 -0500

Some of us talked a bit last week about some of the issues around the
AES draft and kerberos-revisions issues that affect it.  I think we've
gotten a few things settled now.  I still need to address some of the
issues raised by Marcus Watts.  (Sorry, Marcus, I think your original
message in September slipped through the cracks, but I've dug it up
again.)

Here's a brief summary:

In kerberos-revisions (or the separate kerberos-crypto draft):

- string-to-key has an integer "salt type" argument currently, it'll
  be replaced with an opaque blob (octet string) for "extra
  string-to-key parameters", which will be defined in an
  enctype-specific way.  All salt strings must be valid, but parameter
  "blobs" can be constrainted, and string-to-key may report an error.

- a new method will be added for providing the default parameters when
  they're not provided some other way

- a new preauth message will be defined to pass the parameters

- DES-based encryption systems will get a parameter block that is
  supposed to contain a zero, which AFS (probably left unspecified, at
  least in revisions) will diverge from; the details need ironing out

For AES:

- PKCS #5 will likely be used in this draft.  The parameter "blob"
  will be some encoding of the number of iterations.  String-to-key
  will use that value, perhaps with some sort of bounds checking
  (bounds as yet to be chosen), and the default value will be 1000
  iterations.

- Serpent and Twofish might be included, for those who want something
  to fall back on should Rijndael be broken.  Or, they might not, to
  keep the specifications a little simpler.  I'm mildly in favor of
  keeping them, some others were mildly(?) opposed.  Didn't ask for WG
  consensus.  (I don't recall if this question came up in London.)

(Guys, did I miss anything?)

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Dec 2001 11:52:08 -0500

> - a new preauth message will be defined to pass the parameters

Shouldn't these parameters be passed as additional fields of the enc
timestamp PA?

> Ken

Cheers,

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: Marcus Watts <[email-masked]>
Date: Tue, 18 Dec 2001 16:44:29 -0500

>   "blobs" can be constrainted, and string-to-key may report an error.

When I was doing cast5/rc6, I found it necessary to make the salt be an
"opaque" structure.  The two parameters I encoded were the salt
function type, and data specific to that salt function.  Even with DES,
the fact that this is not done is unfortunate; there are really 2
different DES salt functions, "mit" and "afs", and the way this is
passed is sort of a hack.  When a specific key is used (ie, when
returning a ticket) then the server can indicate this using either
PADATA_PW_SALT or PADATA_AFS3_SALT.  If a ticket isn't being returned,
then there is no way (sort of guessing to look at PADATA_ETYPE_INFO and
decide what sort of salt function goes with the salt being passed.

With my cast5/rc6 experiments, I added support for 3 string to key functions:
	"mit" -- the MIT des3 key nfold stuff (minus the des3 parity generation)
	"grex" -- as described at the end of
		http://www.cyberspace.org/staffnote/passwd.html
	"crypt" -- keys taken from a Unix passwd database, -- could
		in turn be "old", "new", "md5", blowfish".  old, new
		and blowfish have salt function specific parameters.
I also added support for ece based preauthentication, which meant I
*had* to parse the etype_info field and get the salt function -- the
DES hack just wasn't going to cut it for me.  In the end, I used the
existing PADATA_ETYPE_INFO and PADATA_PW_SALT types -- my reasoning: salt
is already enc specific, and a client that doesn't know how to apply
string to key to a given blob is not going to work anyways.

If I have managed to parse my subroutine calls right, I think I used
this for the opaque blob:
	OpaqueSaltData ::= SEQUENCE {
		salt-type[0]	Int32,		--salt function
		contents[1]	OCTET STRING	--can be further interpreted
						--  by salt function
	}
where salt-type could be one of:
	normal		0
	v4		1
	norealm		2
	onlyrealm	3
	special		4
	afs3		5
	[reserved]	-1	--wildcard matching in MIT
	crypt		-2
	grex		-3
salt-type could probably be collapsed to (v4,v5,afs,??? crypt,??? grex);
I was just returning what kdc keeps in its database.
I think this allows lots of flexibility: salt functions are free
to add their own extra parameters; software that doesn't support
a particular tweak can just ignore it.

Note that I have a problem here which also exists with Brezak's proposal
to add that ugly iteration count in:
	It's possible for the MITM to return bogus padata information.
In my case, the bad guy could pass back crypt(old, 8char pw salt),
captured the bogus return using the bad key, then run "crack" to find a
key that will decrypt the bogus result.  With Brezak's proposal,
something similar is possible: simply pass in an iteration count of 1.
(At least, this is a problem if you accept that a count of 1000 actually
adds useful security...)

The fix for this would be to put client side configuration data in
that specifies the minimal allowable level of "security".  This could
get ugly, since we appear to have more than one dimension to 'security':
	bit length
	"computational complexity"
	"I can't stand that" ugly factor

Having opaque enc specific salt data is a *Good* thing.  I would propose
defining that as:
	function type
	opaque per-function data (salt string, iteration count, ...)

Passing in security data in enc specific salt data, with no means
of client side checking, is a *Bad* thing.

>   they're not provided some other way

A config file option?  Probably applies to both client & server.

> - a new preauth message will be defined to pass the parameters

Is anyone else worried about over-poliferation of padata types?
I'd rather see it use the existing PADATA_ETYPE_INFO and PADATA_PW_SALT
unless there is some good reason to believe it will break something.

>   least in revisions) will diverge from; the details need ironing out

Are you thinking of fixing the PADATA_AFS3_SALT vs PADATA_ETYPE_INFO mess?
That would almost justify inventing new padata types.

>   (bounds as yet to be chosen), and the default value will be 1000

Again, I'd like to see that defined as:
	function type, [function specific blob]
		where blob would contain salt and perhaps other junk.

Did I mention that I really hate that count of 1000 ?  I think this is
making it harder to do some applications (such as the previously mentioned
cellular phone thing), while adding little in the way of security (at least
9 bits of performance difference between fastest & slowest current hardware,
padata hole I mentioned above).

				-Marcus Watts
				UM ITCS Umich Systems Group

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Dec 2001 19:38:08 -0500 (EST)

> Shouldn't these parameters be passed as additional fields of the enc

No.  They have nothing to do with actual preauthentication; they're a use
of the pa-data field as a typed hole.  They'll actually appear as part of
pa-data coming _from_ the KDC, indicating the parameters the client should
use when calling string-to-key -- just as alternate salt strings are sent
now.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Dec 2001 20:05:43 -0500 (EST)

> "opaque" structure.  The two parameters I encoded were the salt

Because you didn't already have the opaque parameter structure Ken has
proposed, you had to overload the salt in a similar way to what was
previously proposed for AES.  IMHO that's a bad thing -- salt strings are
by convention derived in specific ways, and are intended to act as a sort
of confounder to be combined with the password as input to the
string-to-key function.  PADATA-ETYPE-INFO not withstanding, they were
never intended to be enctype-specific.

I believe that overloading the salt string in this way, especially to make
it something other than text, is a bad idea.  I especially believe it's a
bad idea to have any string-to-key function which can be induced by bogus
salt data to do bad or undefined things, or which does not accept all
strings as acceptable salts.

> 		http://www.cyberspace.org/staffnote/passwd.html

grex had its own string-to-key?

> (At least, this is a problem if you accept that a count of 1000 actually

The solution to this is to set a minimum iteration count that you believe
results in sufficient security.  If I understand correctly, Brezak's model
is that some sites will want to set the iteration count _higher_ than the
default in order to gain some impression of greater security (I'm not
qualified to opine as to whether such an impression would be accurate).

> A config file option?  Probably applies to both client & server.

No; he means that the definition of a crypto system will be extended such
that each crypto system has a function which returns the parameter blob
that corresponds to the (universal) defaults.  The setting of site-wide
defaults or client-side limits, while important, is IMHO out of scope.

> unless there is some good reason to believe it will break something.

We're actually talking about a single new preauth type which would be used
to simultaneously provide the salt string, list of valid enctypes, and
parameter block for each enctype.  Because the parameter block is an
OCTET-STRING, we don't need a new padata type for each enctype.

> That would almost justify inventing new padata types.

Yes, that's exactly the idea.  The approach that I proposed was that the
OCTET-STRING parameter for DES string-to-key functions would be defined
such that a first octet of 1 is reserved for indicating the use of the AFS
string-to-key algorithm, as we do now with the "salt type" parameter.
Then the PADATA_ETYPE_INFO2 could be used to pass this parameter on a
per-enctype basis.  In the absence of PADATA_ETYPE_INFO2, the parameter
blocks would be treated as the default for each enctype, except that
the presence of PADATA_AFS3_SALT would be taken to mean the same as if
parameters for all DES enctypes were set to use the AFS string-to-key.

> padata hole I mentioned above).

I actually believe I've come up with a much better solution to the
cellular phone thing.  The last proposal I saw was that such "slow"
devices would have some key stored on the device which would be used to
preauthenticate, thus proving to the KDC that it was OK to use the
"weaker" key.  The problem with this is that it requires the KDC to keep
multiple keys for the same enctype, and requires both the client and KDC
to use preauth-based policy to guess which key to use.

Instead, I propose that the KDC know and use only the key that results
from performing the full 1000 iterations.  Instead of storing a private
authentication key, the device then stores a value which is the XOR of the
real key with the key produced by using only 100 rounds.  Then the client
can construct the real key at any time by performing only the fast
100-round version of the string-to-key, followed by XOR'ing the result
with the stored data.  This method requires no special support from the
KDC, requires no protocol changes, and allows the required strength to be
set at each device on a per-device basis.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 14:12:53 -0500

> strings as acceptable salts.

I've been bitten in a similar way with MIT krb5: the client code
examines only the first ETYPE-INFO entry when creating PA-DATA in
response to a pre-auth require error, and the KDC sorts those
ETYPE-INFO entries in the same order as the keys were in the KDB entry
for the client princ.

Add a new preferred enctype and old client fall down, go poom.

The solution is to treat each PA type as having a function to produce
PA-DATA and whose arguments include all the relevant information, from
configuration and from KRB-ERRORs. The string2key() functions are really
specific to a PA type (PA-ENC-TSTAMP) - they too should get all the info
they need.

But I don't like speaking of a "blob" when we can just define what those
arguments ought to be. For PA-DATA functions that may get to be a bit
difficult because they need other inputs (passwords, cryptocard
interactions, etc...), but we should try anyways.

> qualified to opine as to whether such an impression would be accurate).

Actually, the stuff we're talking about on the "retry: PKINIT" thread
should suffice to detect spoof KRB-ERROR attacks. I.e., the client
should include a random nonce in the request which the KDC should repeat
in the response, particularly if the response is unauthenticated.

> OCTET-STRING, we don't need a new padata type for each enctype.

Hmmm. Perhaps each PA-DATA entry included in a KRB-ERROR should have its
own enctype and salt list or lists.

Really, both the ETYPEs and the salts are related to a few PA types.
ETYPEs that apply to, say, PKINIT, wouldn't apply to PA-ENC-TSTAMP.

> string-to-key algorithm, as we do now with the "salt type" parameter.

Isn't this specific to the MIT implementation? String2key() being a
local feature of the protocol I don't see why the "blob" needs to be
defined this way. I'd rather define it as a structure. See above.

> per-enctype basis.  In the absence of PADATA_ETYPE_INFO2, the parameter
  ^^^^^^^^^^^^^^^^^

ETYPE-INFO already is per-enctype.

I'd rather have a per PA type ETYPE-INFO and salt list(s).

> set at each device on a per-device basis.

Cool! But it ties a phone to a user... No big deal, probably, in real
life... as long as there are simple cell-phone re-key protocols :)

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 17:05:28 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> The solution is to treat each PA type as having a
    Nicolas> function to produce PA-DATA and whose arguments include
    Nicolas> all the relevant information, from configuration and from
    Nicolas> KRB-ERRORs. The string2key() functions are really
    Nicolas> specific to a PA type (PA-ENC-TSTAMP) - they too should
    Nicolas> get all the info they need.

I'm used to solutions that improve things in some way.  Your claim is
that the code only considers the first pa-etype-info.  That's clearly
a bug in the code.  However we have two solutions.  The first solution
is to consider the first pa-etype-info for an enctype we support and
are willing to use.  The second solution is to consider string2key and
associated parameters to be a function of the preauth mechanism in
use as you propose.

As far as I can tell the first solution completely solves the problem
you described.

Your proposed solution  doesn't seem to address the problem at hand
and has the following other disadvantages:

* Preauth mechanisms need to know about the string2key algorithm in
  use.  Since we've already established that string2key algorithms are
  dependent on crypto systems, we now have preauth data that needs to
  know both abouth the string2key algorithm and about the crypto
  systems.  So if I wish to define a new crypto system I need to go
  back and modify all the preauth types that might wish to use the
  crypto system so they can know how to do string2key for that crypto
  system.

* It is a departure from the way things currently work.  We have
  several proposed preauth types including all the enc-timestamp
  variants and the SAM preauth that are all independent of string2key
  algorithm.  The SAM stuff does things to combine two keys, but  it
  uses  whatever string2key algorithm is used by the crypto system.

*  We have cases where we need a string2key algorithm and don't have
   preauth mechanisms at all.  This is needed for the set-password
   draft , for an admin protocol 
, and for non-Kerberos uses of Kerberos enctypes.

If you want us to consider string2key algorithms preauth specific, you
should justify why this is a good idea and explain why it is better
than Ken's proposal.

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 17:08:31 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    >> > - a new method will be added for providing the default
    >> parameters when > they're not provided some other way
    >> 

    Jeffrey> No; he means that the definition of a crypto system will
    Jeffrey> be extended such that each crypto system has a function
    Jeffrey> which returns the parameter blob that corresponds to the
    Jeffrey> (universal) defaults.  The setting of site-wide defaults
    Jeffrey> or client-side limits, while important, is IMHO out of
    Jeffrey> scope.

I think this method should be constrained to return a constant value
specified by the spec for each crypto system if it takes no
parameters.  If it does take parameters then the algorithm used to
compute the value should be in the enctype-specific spec.

I certainly don't want situations where two implementations return
different default blobs.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 17:38:03 -0500

> and has the following other disadvantages:

My proposed solution has little impact on the protocol, and is to do
with how the client implements things.

You could take this to mean, for example, that a pa_function is to be
called for each salt/etype pair until it succeeds or you run out of
salt/etype pairs.

Or you could take it to mean that each pa_function should get a list of
all the salts and all the etype-info available as arguments, and,
internally each pa_function would have to decide somehow (perhaps by
looping over all possible salt/etype pairs) how to proceed.

I do wonder if some pa types wouldn't benefit from having pa-type
specific etype-info and salts associated with principals. But that's
probably not needed now.

So mostly I'm arguing about client implementation architecture.

>   crypto system so they can know how to do string2key for that crypto

No, not really. A given string2key() can be used with multiple crypto
systems, and that's pretty much a configuration issue, assuming you can
dynamically load new crypto system code.

And string2key() can be used with more than one PA type too. That too is
a configuration issue, again, assuming you can dynamically load new
string2key functions...

>   uses  whatever string2key algorithm is used by the crypto system.

See above. The proposal that each PA datum carry its own etype-info and
salt info can be dropped; its the client architecture that I'm really
gunning for, the "blob" which I'm trying to define.

I spent sometime thinking about how best to address the MIT bug I
mentioned and I settled for the approach of sorting the etype-info at
the KDC according to the client's requested etypes, in part because it
was the smallest and simplest change, but also because I had legacy
deployments I could not fix.

> , and for non-Kerberos uses of Kerberos enctypes.

Again, see above.

> should justify why this is a good idea and explain why it is better

I'm not saying that string2key algorithms should be specific to certain
preauths. I'm saying that they are (i.e., not all preauth types use
string2key() :)

But primarily I'm arguing that the "blob" argument to string2key() is
really best thought of as a better interface not only to string2key()
but also to the PA functions.

Cheers,

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Dec 2001 17:57:13 -0500 (EST)

> preauths. I'm saying that they are (i.e., not all preauth types use

Argh.  No, they're not.  string_to_key functions have nothing to do with
preauth; they have to do with converting passwords to keys, which in turn
are specific to enctypes.  Some preauths use keys; others don't. 
Similarly, there are many contexts other than preauth in which keys are
used; for example, to encrypt the contents of an AS-REP.  In any of these
contexts, preauth or otherwise, the key in question may or may not have
been derived from a string (not all principals' keys are derived from
strings.  Not even all "users" have keys derived from strings).  If it was
not, then no string_to_key function is used.

> but also to the PA functions.

You're confused.  When Ken described a change to the string_to_key
function, he was talking about the abstract function which is part of the
protocol definition of a crypto system.  He wasn't talking about an API;
the Kerberos spec doesn't and shouldn't define an API.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 18:07:07 -0500

> not, then no string_to_key function is used.

 - if you're not using pre-auth, you might as well be using
   PA-ENC-TIMESTAMP

 - if your using something like PKINIT or smartcards then the AS-REP
   might not be encrypted in any key made with string2key()

 - ergo, conceptually, string2key() is related to specific PA types

Q.E.D?

Beyond that, I'm pointing out that the PA code in the clients has to
take into account all of the available and relevant information when
generating padata, specifically that means all the salts and etype info
provided by the KDC or defaults taken from the clietn's configuration.

> the Kerberos spec doesn't and shouldn't define an API.

And I'm speaking of an abstract function not described as such in the
RFC or draft, that's the per-pre-auth padata generation function
(pa_function, interms of the MIT implementation). Perhaps pa_function
should be described in the RFC.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 18:22:44 -0500

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

    Nicolas> On Thu, Dec 20, 2001 at 05:57:13PM -0500, Jeffrey
    Nicolas> Hutzelman wrote:
    >> > I'm not saying that string2key algorithms should be specific
    >> to certain > preauths. I'm saying that they are (i.e., not all
    >> preauth types use > string2key() :)
    >> 
    >> Argh.  No, they're not.  string_to_key functions have nothing
    >> to do with preauth; they have to do with converting passwords
    >> to keys, which in turn are specific to enctypes.  Some preauths
    >> use keys; others don't.  Similarly, there are many contexts
    >> other than preauth in which keys are used; for example, to
    >> encrypt the contents of an AS-REP.  In any of these contexts,
    >> preauth or otherwise, the key in question may or may not have
    >> been derived from a string (not all principals' keys are
    >> derived from strings.  Not even all "users" have keys derived
    >> from strings).  If it was not, then no string_to_key function
    >> is used.

    Nicolas>  - if you're not using pre-auth, you might as well be
    Nicolas> using PA-ENC-TIMESTAMP

    Nicolas>  - if your using something like PKINIT or smartcards then
    Nicolas> the AS-REP might not be encrypted in any key made with
    Nicolas> string2key()

    Nicolas>  - ergo, conceptually, string2key() is related to
    Nicolas> specific PA types

    Nicolas> Q.E.D?

No, all you have proven is that some PA use s2k and some don't.  You
have not proven (what I believe to be a false claim) that a PA type
should concern itself with which s2k algorithm is used, or should have
any non-generic knowledge of the s2k algorithm.

In OO methodology, a well defined s2k interface can be provided to all
preauth mechanisms.  Whether the mechanism uses that interface is up
to the definition of the mechanism.  However preauth mechanisms do
*not* need to know how that interface is implemented.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 18:18:21 -0500

On Thu, Dec 20, 2001 at 06:14:21PM -0500, Sam Hartman wrote:
> OK, I see what's going on here I think.  To me, it looked like you
> were proposing a conceptual model that is more general than that
> proposed by section 6.  This is dangerous because your model requires
> crypto-system consumers to specify more information and thus to have
> that additional information.  You've traded flexibility in
> crypto-system specification for restrictions on what a generic user of
> the interface can do; I don't think you've justified this tradeoff.
> 
> What you're saying is that a pa-type needs to be able to find out what
> enctypes the server recommends using for the client's long-term key as
> well as to be able to run string2key for one of those enctypes and
> have something reasonable happen.  I agree with this.

Good.

>     Nicolas> No, not really. A given string2key() can be used with
>     Nicolas> multiple crypto systems, and that's pretty much a
>     Nicolas> configuration issue, assuming you can dynamically load
>     Nicolas> new crypto system code.
> 
> This is false.  Yes you can use the same string2key for all the DES
> enctypes but that's the only case I know of.

Who's to say it a given string2key() function can't have other crypto
systems plugged into it in the future? Wasn't that mentioned wrt twofish
et. al.?

So, that statement is true for some string2key/enctype combinations,
though not generally true.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 18:14:21 -0500

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

    Nicolas> My proposed solution has little impact on the protocol,
    Nicolas> and is to do with how the client implements things.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 18:30:38 -0500

> *not* need to know how that interface is implemented.

Ah, but it is the pa_function that calls string2key() so, to pass the
salt/etype info to string2key() the pa_function needs to have access to
the same.

And since some pa_functions don't use string2key() but might need access
to the etype-info anyways the salt/etype info should not be an opaque
blob to the pa_functions.

Nico

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 18:48:35 -0500

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

    Nicolas> On Thu, Dec 20, 2001 at 06:22:44PM -0500, Sam Hartman
    Nicolas> wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <[email-masked]>
    >> writes: No, all you have proven is that some PA use s2k and
    >> some don't.  You have not proven (what I believe to be a false
    >> claim) that a PA type should concern itself with which s2k
    >> algorithm is used, or should have any non-generic knowledge of
    >> the s2k algorithm.
    >> 
    >> In OO methodology, a well defined s2k interface can be provided
    >> to all preauth mechanisms.  Whether the mechanism uses that
    >> interface is up to the definition of the mechanism.  However
    >> preauth mechanisms do *not* need to know how that interface is
    >> implemented.

    Nicolas> Ah, but it is the pa_function that calls string2key() so,
    Nicolas> to pass the salt/etype info to string2key() the
    Nicolas> pa_function needs to have access to the same.

Yes, that's a valid way to think about it.

    Nicolas> And since some pa_functions don't use string2key() but
    Nicolas> might need access to the etype-info anyways the
    Nicolas> salt/etype info should not be an opaque blob to the
    Nicolas> pa_functions.

First, I don't believe that pa types should use etype info for
anything other than string2key.  Can you give me an example of a valid
non-s2k use of etype info?

Second, no one is proposing making etype info a blob; we propose to
make it a mapping from etype to salt, blob tuples.

---

From: Sam Hartman <[email-masked]>
Date: 20 Dec 2001 19:01:04 -0500

>> Second, no one is proposing making etype info a blob; we
    >> propose to make it a mapping from etype to salt, blob tuples.

    Nicolas> Now I think I'm lost... :(

    Nicolas> Ok, I'll get off this thread and re-think. Or not, the
    Nicolas> holydays are here :)

So,  you can think of etype info as a 
SEQUENCE OF SEQUENCE {
	Etype UINT32,
	Salt KerberosString,
	s2k-params OctetString
}

Or something like that.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 18:56:43 -0500

> non-s2k use of etype info?

Hmmmm... I guess not. Hmmmm, thinking more about it, the ETYPE-INFO
relate to the keys known to the KDC for the client principal, and those
are keys made with string2key()... Non-string2key-related PA types need
other hints (TypedData?) than ETYPE-INFO...

Ok. Never mind then. I just made that realization.

> make it a mapping from etype to salt, blob tuples.

Now I think I'm lost... :(

Ok, I'll get off this thread and re-think. Or not, the holydays are
here :)

Cheers!

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Dec 2001 19:12:21 -0500

> So,  you can think of etype info as a 

Yes, yes, that's it. That was one of my initial thoughts, that the
individual pa data info in KRB-ERROR would include etype/salt/whatever
info. But there's no need to change the protocol as it stands. The
client can simply put the above blob together and pass it to the
pa_functions which, if they use string2key() can pass it to it.

Ok. Never mind then :)

I took us on an unnecessary detour.

Happy holydays,

Nico