Subject: Setting to KRB-WG agenda for IETF 53

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 05 Mar 2002 16:03:28 -0600

Agenda items for the KRB-WG meeting 3/19/2 is coming up 
in two weeks. We have two 1 hour sessions, Tuesday 1415-1515
and 1545-1645. 

We made a lot of progress at the interim meeting last month in 
breaking up the revisions into the clarifications and extensions.

I would like to ask Jeffrey Hutzelman, who lead most of the discussion
at the interim meeting, to report on the breakup of the revisions, 
especially listing what features are in clarifications, what are in
should be in extensions and what other features have been postponed. 

Cliff Neuman's web site:

 http://www.isi.edu/people/bcn/krb-revisions 

has most of these listed and I would then like to ask Cliff Neuman
to lead the discussion of getting the changes into the documents. 

I am then looking for suggestions as to what else should be on the agenda
and who would like to speak. 

-- 

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

---

From: Sam Hartman <[email-masked]>
Date: 06 Mar 2002 18:07:50 -0500

Both because of discussion on comp.protocols.kerberos and discussion
at the interim meeting, it might be good to have someone discussing
the weak user password problem if we have something to say.

It seems like Jeff Altman should probably present his UTF8 draft if
he's going to be there as this is a new document.

Just my thoughts on things it would be nice to cover.

Ideally, I'd like to come away from the next meeting with a clear set
of who'se doing what to get extensions and clarifications moving to
last call.

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Wed, 6 Mar 2002 18:05:39 -0600

> the weak user password problem if we have something to say.

I have done a bit of work in this area and have some material I could
present on this issue.  Also, I would like to touch on the area of SRP
and/or PDM for the AS exchange.  I think at least Ken Raeburn, John
Brezak, and Jonathan Trostle have also expressed interest in such.

-- 
Jacques A. Vidrine <[email-masked]>                     http://www.nectar.cc/
NTT/Verio SME           .      FreeBSD UNIX      .        Heimdal Kerberos
[email-masked]      .   [email-masked]   .           [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: 06 Mar 2002 19:12:28 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    Jacques> I have done a bit of work in this area and have some
    Jacques> material I could present on this issue.  Also, I would
    Jacques> like to touch on the area of SRP and/or PDM for the AS
    Jacques> exchange.  I think at least Ken Raeburn, John Brezak, and
    Jacques> Jonathan Trostle have also expressed interest in such.

Most of the implementers have indicated that the patent problems with
SRP and PDM would be a consensus-blocker to make this mandatory for
them; Ken has been looking at other solutions.

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Thu, 7 Mar 2002 07:42:40 -0600

> them; Ken has been looking at other solutions.

I didn't have in mind a mandatory mechanism, but I didn't realize that
PDM had patent problems either.
I'd like to see a framework in which both SRP and PDM could fit, and
that would have a high chance of fitting a future
patent-free-thing-like-SRP-and-PDM.

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: 07 Mar 2002 09:16:31 -0500

>>>>> "Jacques" == Jacques A Vidrine <[email-masked]> writes:

    Jacques> I didn't have in mind a mandatory mechanism,o

In order to solve the problem we need some mechanism everyone
implements so you can never collect ciphertext directly encrypted in
long-term keys.  Microsoft indicated at the interim meeting that
solving this problem was very important to then, and John and Ken did
some brainstorming on solutions.  If the host has a key, you can use
that; if not, it becomes more complex.

    Jacques>  but I didn't
    Jacques> realize that PDM had patent problems either.  I'd like to
    Jacques> see a framework in which both SRP and PDM could fit, and
    Jacques> that would have a high chance of fitting a future
    Jacques> patent-free-thing-like-SRP-and-PDM.

I think preauth already gives us that framework.  While I don't think
SRP/PDM are appropriate mandatory-to-implement measures in this space,
I would like to see one or both specified and would be interested in
reviewing a draft that does that.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Mar 2002 09:25:48 -0500

> patent-free-thing-like-SRP-and-PDM.

The framework is already there: it's the pre-auth typed hole.

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: Matt Crawford <[email-masked]>
Date: Thu, 07 Mar 2002 08:34:05 -0600

> the weak user password problem if we have something to say.

Are you referring to having the admin server enforce password
quality, or protecting the AS exchange?  Or both?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Mar 2002 09:53:43 -0500

> reviewing a draft that does that.

I think we can live with PA-ENC-TIMESTAMP being the MUST implement for
interop mechanism and other mechanisms being optional. But it would be
very helpful to have open (not proprietary, not encumbered) mechanisms
not dependent on keys derived from weak passwords.

I guess we have to determine how important such a mechanism would be to
Athena and similar setups because key-less hosts complicate the
solution, forcing the use of SRP et. al. or other public crypto (and
solving attendant public key distribution issues).

Cheers,

Nico

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Thu, 7 Mar 2002 09:05:37 -0600

> The framework is already there: it's the pre-auth typed hole.

This is splitting hairs on the definition of a `framework', but IMHO
that's not enough.  There are a couple of obvious and useful ways
to implement SRP/PDM, but with a differing number of messages and
assurances.  After some useful discussion in Minneapolis, I will come
up with a draft of what I mean.

Cheers,

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 07 Mar 2002 10:41:51 -0500

>that's not enough.

Why not?

--Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 07 Mar 2002 15:41:57 -0600

See draft agenda below. Comments please. 

> the weak user password problem if we have something to say.

Good point. Would you like to talk on this? Or do you have someone in mind?
Jacques A. Vidrine?

> he's going to be there as this is a new document.

Yes, Jeff will you be there?

> of who'se doing what to get extensions and clarifications moving to

Yes, me too. That was why these are the first two items. I would especially like
to make sure Cliff has assignments for any missing pieces of the clarifications. 

-------------------------------------------------------
Kerberos WG  (krb) DRAFT 1.0

TUESDAY, March 19, 2002
1415-1515 Afternoon Sessions II
1545-1645 Afternoon Sessions III
======================================================

CHAIR: Doug Engert <[email-masked]>

AGENDA:

  Introduction  
        Doug Engert - 5 min

 "Report on the Interum WG meeting, Revisions split into Clarifications and Extensions"
	Jeffrey Hutzelman - 30 minutes

	Discussion of what features are in each document, and why. Others are asked
        to review the list, See http://www.isi.edu/people/bcn/krb-revisions  for a start. 
	Specifics of the features in Clarifications will be discused below. 

 "The Kerberos Network Authentication Service (V5)" 
        Cliff Neuman - 45 min

        "The Kerberos Network Authentication Service (V5)"
        http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-00.txt
        Can also be found at http://www.isi.edu/people/bcn/krb-revisions 
        The title is the same, but the reference is now called clarifications. 

        The main objective of the working group is to move this draft forward 
        to last call.       

Break

  "Stringprep Profile for Kerberos UTF-8 Strings"
        Jeff Altman - 15 min
        http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-utf8-profile-00.txt

  "Weak Password and SRP/PDM in preauth" 
	  "Jacques A. Vidrine" - 5 minutes

DESCRIPTION:

The prime goal of the working group is to get Kerberos Clarifications to last call,
as most of the other documents depend on this.  

--

---

From: Ken Raeburn <[email-masked]>
Date: 12 Mar 2002 04:54:44 -0500

John says he's writing up an I-D based on DCE's RFC 26.0 for using a
host key to protect an AS-REQ exchange.

Another interesting approach that's been recommended is LEAF, part of
SPX.  It's part of a multiple-party exchange that eventually delivers
the user's long-term private key to her without exposing it to anyone
else.  It involves sending one password-derived secret and a random
key to the server encrypted using the server's public key, and getting
back something protected by both the random key and another
password-derived secret.

Stripped down to a bare minimum and applied to the Kerberos
AS-REQ exchange, it might look something like this:

    Assume:
      P_leaf		KDC's public key for LEAF
      f(B1,B2)->Kx	some non-reversible key generation function
                        with bitstring inputs B1, B2

    Client generates bitstrings K_c and K_f from user's password with
    two different non-reversible functions, and generates random
    bitstring K_r.

    Client sends KDC:	AS-REQ + {K_r,K_f}P_leaf

    KDC looks up K_c and K_f for the user and verifies K_f

    KDC sends client:	AS-REP encrypted with f(K_c,K_r)

(This version is different enough from the SPX version that I'm not
sure if it would be appropriate to call it LEAF any more.)

An evesdropper will get data encrypted in the KDC's LEAF public key,
and data encrypted using a key derived from a randomly-generated
string produced by the client.

A replay of the client's message will produce more data, similar but
not identical, encrypted using that same presumably-strong second key.
A timestamp added to the preauth data would reduce the amount of data
that could be collected that way.

If the client's notion of P_leaf can be compromised, it can be tricked
into sending K_r and K_f to an attacker.  This allows the attacker to
request the AS-REP from the real KDC.  It's still encrypted, and f can
be made a one-way function, but the attack is basically reduced to
brute-force against the password-derived K_c.

This scheme does assume that the client has been preconfigured to know
the public key for the KDC to be contacted.  This is a bit at odds
with the minimal local configuration some of us have been shooting for
with DNS SRV records.  It's certainly a reasonable thing to do, but
IMNSHO not a desirable thing to require.

If the client does not have the KDC's LEAF public key, we could use an
additional exchange to convey the key to the client system:

    client->KDC: AS-REQ
    KDC->client: KRB-ERROR (PREAUTH-REQUIRED,LEAF,P_leaf)

A "fingerprint" of that key could be displayed for user verification,
similar to what some versions of SSH, and I think some web browsers,
will do.  Or we could look at public-key distribution schemes outside
of Kerberos.  (mutter mutter secure DNS mumble)

I could probably write this up in a very rough I-D without too much
effort.  The interesting bits would involve around trying to fit it to
the crypto framework rather than nailing it down to specific
encryption and hash functions.

If I recall correctly, in its original form, LEAF has the interesting
property that the server does not have access to the user's data (such
as her long-term private key) in any useful form; it stores them
encrypted in one of the keys generated from the password, and the
server never sees that key.  The random key sent by the client is used
for an additional level of encryption, not the sort of combining
operation I describe above.  Even assuming user's principal's keys are
disallowed for services (which may be the case in some configurations
but probably shouldn't be assumed), I'm not sure we can apply that in
any useful way to Kerberos.  But it would be interesting to try.

I haven't read anything about patent issues for LEAF or for a scheme
like I outlined above, but it would be worth checking.

Once we open the door to public-key crypto in preauth systems, and
public keys for KDCs, other possibilities arise too, I'm sure.  A
workstation with no secret of its own, but a copy of the KDC's public
key, might be able to bootstrap to some secure but anonymous access to
local services, say file servers with software updates.

Ken

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 12 Mar 2002 10:30:19 -0500

From: Ken Raeburn <[email-masked]>
   Date: 12 Mar 2002 04:54:44 -0500
[...]
   This scheme does assume that the client has been preconfigured to know
   the public key for the KDC to be contacted.  This is a bit at odds
   with the minimal local configuration some of us have been shooting for
   with DNS SRV records.  It's certainly a reasonable thing to do, but
   IMNSHO not a desirable thing to require.

If we're willing to require clients to have some sort of trusted
public key (and I think this isn't that unreasonable given that we're
assuming the clients have trusted local software) we might as well
just use TLS to protect the initial authentication and take advantage
of the fact that it's already been widely deployed.  Since the WG
seems to be moving towards requiring TCP for more and more of
Kerberos, this appears to be workable.

Larry

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Mar 2002 11:22:59 -0500

> assuming the clients have trusted local software) we might as well

That's the problem: Athena hosts have no host keys because they cannot
be trusted.

> Kerberos, this appears to be workable.

The use of public keys would imply a mechanism for distribution of
realm/kdc public keys. No such mechanism exists currently, and to make
matters worse, in order to securely distribute public keys you must
either bootstrap the process with a well-known public key (think PKI and
CAs) or you must distribute them over sessions encrypted with symmetric
keys, which brings us back to the point that Athena systems have no keys
and that no keys stored on Athena systems could be trusted (which is why
they have no keys).

> Larry

For keyed hosts the best solution is to use the host principals'
tickets for securing the AS exchange and protecting the exchange of
weak-key encrypted data.

For unkeyed hosts things get complicated because we cannot rely on any
kind of key being present on the client, we must prevent dictionary
attacks by sniffers and we must prevent man-in-the-middle attacks (so a
Diffie-Hellman exchange followed by traditional PA-ENC-TIMESTAMP
further encrypted in the DH session key would not do).

So for key-less hosts we need a protocol/algorithm such that:

a) the user's password is proven to the KDC,
b) a secret session key is negotiated,
c) a sniffer cannot perform a dictionary attack against the ciphertext
   he/she may capture,
d) a man in the middle cannot obtain useful data,
e) no public key distribution is necessary

SRP would fit the bill. SRP is not the only algorithm that would fit the
bill.

I'm sure I missed something...

Cheers,

Nico

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 12 Mar 2002 11:45:54 -0500

Date: Tue, 12 Mar 2002 11:22:59 -0500
   From: Nicolas Williams <[email-masked]>
[...]

If you don't trust the host, how do you know your "kinit" program
isn't going to e-mail your password to [email-masked]?

How is trusting the kinit program any different from trusting that the
certificate store doesn't have a bogus root cert in it?

Do I think using something like TLS is the be-all-end-all solution?
No.  Do I think it's better than what we have now?  Yes.  Would SRP
potentially be better?  Probably, but if we're going to have patent
issues with it I'd rather make progress than sit around doing
nothing.

Larry

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Mar 2002 12:04:35 -0500

> certificate store doesn't have a bogus root cert in it?

Actually, this is my problem with Athena, but then, I know next to
nothing about Athena. So I'm with you on that. I'll take the host key
approach.

> issues with it I'd rather make progress than sit around doing

The Athena folks ought to define what they want in this space and just
how badly they want it.

Cheers,

Nico

---

From: Ken Raeburn <[email-masked]>
Date: 12 Mar 2002 14:19:56 -0500

> isn't going to e-mail your password to [email-masked]?

First, consider a kiosk model, where the shop you walk into may have
done a good job of securing their software from modification (maybe
you reboot from a ROM image or write-protected disk and the machines
are physically secure), but they haven't set up a key exchange with
your little company or school in some other country.  The software may
be secure, but no useful keys are there.  That is, unless you're going
to assume PKINIT and global PKI.

Second, with symmetric key systems, the workstation doesn't have to be
modified to be compromised; if the workstation's secret key is
revealed, further communications using it cannot be trusted.  But if
the workstation has a copy of the KDC's public key, and a user has
some means of checking that the workstation software is correct, the
user can still communicate safely with the KDC.

> certificate store doesn't have a bogus root cert in it?

It isn't, if they're both local, which is not a given.

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 12 Mar 2002 14:24:25 -0500

Date: Tue, 12 Mar 2002 12:04:35 -0500
   From: Nicolas Williams <[email-masked]>

The host key approach isn't wonderful for many settings.  We have many
users with notebooks; we distribute the Kerberos software to them via
the web (using TLS!) or via a CD we give all first-years.  Keying all
of these machines is a nightmare if you're trying to avoid the weak
initial authentication.

Similiar problems occur with any loosely affiliated machines.

There's the identical problem when adding a Windows 2000 machine to a
domain; I wonder how they secure the host key.

Larry

---

From: Sam Hartman <[email-masked]>
Date: 12 Mar 2002 14:27:45 -0500

>>>>> "Lawrence" == Lawrence Greenfield <[email-masked]> writes:

    Lawrence>    From: Ken Raeburn <[email-masked]> Date: 12 Mar 2002
    Lawrence> 04:54:44 -0500 [...]  This scheme does assume that the
    Lawrence> client has been preconfigured to know the public key for
    Lawrence> the KDC to be contacted.  This is a bit at odds with the
    Lawrence> minimal local configuration some of us have been
    Lawrence> shooting for with DNS SRV records.  It's certainly a
    Lawrence> reasonable thing to do, but IMNSHO not a desirable thing
    Lawrence> to require.

    Lawrence> If we're willing to require clients to have some sort of
    Lawrence> trusted public key (and I think this isn't that
    Lawrence> unreasonable given that we're assuming the clients have
    Lawrence> trusted local software) we might as well just use TLS to
    Lawrence> protect the initial authentication and take advantage of
    Lawrence> the fact that it's already been widely deployed.  Since
    Lawrence> the WG seems to be moving towards requiring TCP for more
    Lawrence> and more of Kerberos, this appears to be workable.

I agree that if we adopt some sort of public key scheme, we should
support TLS or SSH certs.  

As someone implementing Kerberos, I don't actually want to drag in a
full TLS library into kinit.  I think this would be a show-stopper for
me, more because of licensing issues than anything else, but the
technical issues also argue against it.

I think that using the host key will work in enough cases that we can
make that proposal be the mandatory one and have some sort of
public-key proposal for Athena.  Alternatively we can say that people
in the Athena space should use SRP and find some way to deal with the
IP issues.  I understand John's concerns, agree that SRP cannot be
mandatory, but suspect it could at least be specified.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Mar 2002 14:29:09 -0500

> domain; I wonder how they secure the host key.

There you go. With Win2k, WinXP, Solaris + SEAM and probably Linux +
Secure NFS you see a requirement that the clients have a host key.

With laptops there's no big deal as long as they are re-built when they
change hands. For multi-user systems you have to make sure that they are
reasonably secured.

Cheers,

Nico

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 12 Mar 2002 15:13:56 -0500

Date: Tue, 12 Mar 2002 14:29:09 -0500
   From: Nicolas Williams <[email-masked]>
[...]

You haven't given me any hint of how to securely key these machines
(without any public key infrastructure or secure initial
authentication).

Am I suppose to tell users to "call our help center and type in this
128-bit number?"  But we're thinking of switching to IP telephony...

Larry

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Mar 2002 15:20:22 -0500

> 128-bit number?"  But we're thinking of switching to IP telephony...

Sorry. No, the laptop is keyed when it joins the domain, and that has to
be done by a sysadmin with appropriate domain priviledges.

Think kadmin if you're used to MIT or Heimdal krb5. When you run kadmin
it fetches an initial Kerberos ticket using your admin password, then
you use the ank and ktadd commands to create the host principal and the
keytab entries.

Yes, that means using a weak key. Presumably you'll join your laptops
to the domain right after they are staged and on a fairly secure
network where you won't mind using your weak admin key - and presumably
your admin password won't be soooo weak. The system has to be
bootstrapped.

Cheers,

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Mar 2002 14:27:38 -0600

> Kerberos, this appears to be workable.

If you are interested we have a prototype called sslk5, which uses
OPenSSL and certificates to authenticate. Nit that this is then functionally
equivalent to PKINIT.

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Mar 2002 14:50:11 -0600

Kerberos WG  (krb-wg) 

TUESDAY, March 19, 2002

AGENDA:

  Introduction  
        Doug Engert - 5 min
	Agenda bashing, appointing a scribe

 "Report on the Interim WG meeting, Revisions split into Clarifications and Extensions"
	Jeffrey Hutzelman - 30 minutes

	Discussion of what features are in each document, and why. Others are asked
        to review the list, See http://www.isi.edu/people/bcn/krb-revisions  for a start. 
	Specifics of the features in Clarifications will be discussed below. 

Break

  "Weak Password and SRP/PDM in preauth" 
	Jacques A. Vidrine - 15 minutes
	Discuss other methods such as TLS.

        anyone? - 15 min

"Kerberos KDC LDAP Schema"
	Donna Skibbee - 15 min
	http://www.ietf.org/internet-drafts/draft-skibbie-krb-kdc-ldap-schema-01.txt

"Passwordless Initial Authentication to Kerberos by Hardware Preauthentication"
	Matt Crawford - 5 minutes
	http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-hw-auth-01.txt

(I am listing the following drafts, and can discuss them if needed.)

"Public Key Cryptography for Initial Authentication in Kerberos"
	http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-15.txt

"Public Key Cryptography for Cross-Realm Authentication in Kerberos"
	http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-cross-08.txt

"Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB)"
	http://www.ietf.org/internet-drafts/draft-ietf-cat-iakerb-08.txt
 
"Distributing Kerberos KDC and Realm Information with DNS"
	http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-02.txt

"Kerberos Set/Change Password: Version 2
	http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-06.txt

"Generating KDC Referrals to locate Kerberos realms
	http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-02.txt

"Encryption and Checksum Specifications for Kerberos 5
	http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-crypto-00.txt

DESCRIPTION:

--

---

From: Sam Hartman <[email-masked]>
Date: 12 Mar 2002 16:44:46 -0500

Doug, in your mail you imply that the objective of the working group
is to move clarifications forward.  I think that's actually wrong or
at a minimum we don't have consensus that is our objective.  It's not
clear to me how this interacts with the charter since the documents
weren't split at the time we were chartered.

As I mentioned at the meeting here at MIT, I don't really care much
about clarifications except as it is useful in getting to extensions.
I believe that others in the meeting likely hold a similar opinion.
However it is clear that clarifications matters greatly to some and as such we easily reached the consensus  that we need the document.

But I don't think we reached a consensus that clarifications is a
higher priority.  As a practical matter I'll be shocked if extensions
is ready before clarifications, but I would like to see work go on in parallel on both documents.

I think this distinction is important; coming out of the lunch meeting
at the last Minneapolis IETF, it was not clear what the time line for
the 5.3 protocol would be, or whether we would have sufficient
features to justify that protocol.  Coming out of the MIT meeting, it
seems we have something we'd like to propose to the list as a set of
things to include in that protocol, along with proposing that we work
on the extensions protocol now.

If I'm confused about what we are proposing to the group I'd like to
find out now.

Thanks,

--Sam

---

From: Matt Crawford <[email-masked]>
Date: Tue, 12 Mar 2002 15:57:05 -0600

> 128-bit number?"  But we're thinking of switching to IP telephony...

Let me assume you aren't contemplating the addition of
"host/my-laptop.cmu.edu@REALM" to any ACLs.

How secure does the initial keying really have to be?  All I can see
a need for is to arrive at a good key known only to one host and the
KDC(s).  If the key gets on the wrong host, no problem, as long as it
does NOT also get on the right host.

So the instruction is "call the help center and give your hostnamem
then run this command

  kadmin -p host/my-laptop.cmu.edu -q "ktadd host/my-laptop.cmu.edu"

using the password they give you.

If the assumption above is valid, and if the help center isn't conned
into changing the password for existing host principals, what's the
danger?

---

From: Matt Crawford <[email-masked]>
Date: Tue, 12 Mar 2002 16:02:50 -0600

> 	http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-hw-auth-01.txt

Uh, Doug, I see you've put me on the agenda, but I'm not even
coming to the meeting!  I took the WG at its word when it said
in SLC that there was no attention to be spared for other items
until kerberos-revisions was finished.

I stand ready to discuss my draft by email or telephone if
necessary ...
				Matt

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Mar 2002 22:24:02 -0600

I have no problem with proceeding with extensions in parallel. But when the 
charter was written, the revisions document was all we had, and it was substantially
what we are calling clarifications. The way I see it, the extensions depends on 
the clarifications, so we need to keep after the clarifications and get that 
out of the way. I too would be surprised if extensions was ready before
clarifications. 

> weren't split at the time we were chartered.

Well lets put that on the agenda during the introduction. 

> about clarifications except as it is useful in getting to extensions.

So I think we are saying the same thing. We need clarifications. 

> If I'm confused about what we are proposing to the group I'd like to

No, I think we pretty much agree. 

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Mar 2002 22:26:46 -0600

> >       http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-hw-auth-01.txt

Sorry you are not comming. I added all the drafts to the agenda, so we
could get an update. 

> I stand ready to discuss my draft by email or telephone if

If there is any update, feel fre to send comments to the list.

--