Re: One Time Identification, a request for comments/testing.

[g . w]

On Feb 1, 11:11am, "Douglas E. Engert" wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Good evening, I hope the day has gone well for everyone.

A follow up to the mail I sent earlier today.

Nicolas Williams wrote:
> > That doesn't stop a softtoken from being useful though.

> I was trying to get the authors of the note to say this, as it
> appears that their approach is equivalent to soft tokens but may
> have some advantages with regard to password policies.

> > Compare softtokens to passphrase-protected ssh private key files in
> > users' home directories :)

> These suffer form policy control of the passphase used to encrypt
> the key. The user can change the passphrase, or remove it all
> together!  This is a problem for oraganizations that need to enforce
> password quality rules. It all so allows for offline guessing
> attacks.  (A smart card at least enforces some rules on the pin, and
> defeats the guessing attack buy turring off the card after some
> small number of guesses.)

> It sounded like the identity token approach required the use of a
> password as well, so it might get around some of the password policy
> issues, as the KDC gets to enforce the policies. I would like the
> authors to comment more on this.

The central tenant which has consistently shaped our thinking in all
this goes something like this:

'The dirty little secret about information security is that
 there is always a dirty little secret which needs to be kept
 secret.'

Ultimately the only way an organization guarantees security is by
guaranteeing the quality of the secret.  As Doug noted the only way an
organization can exert control over this is by centralized management
of the secrets.

We wanted to preserve and extend that model in OTI which is why we
focused on a model which preserved what Kerberos does very well,
centralized management and control of secrets.  That being said we
also wanted to address a central problem with this which, paraphrasing
Hutzelman, goes something like this:

'Oh damn, I hate typing in long stupid passwords, I'll just
 use my dog's name Rover.
and
'Damnit, they won't let me use Rover.  I'll just type in some
 junk and write it down so I can remember it'.

The logical solution to this problem is one of the central tenants of
OTI's design and is something we refer to as 'password amplification'
or the concept of using the identity token to increase the complexity
of the key selection process.  The identity token does this by
providing a reasonably large secret (the hash of the encrypted
identity) and a perturbation factor, the authentication/identity epoch
time offset.

So in OTI two positive things happen.  The complexity of the secret
is increased.  In addition a different expresion of the secret is
needed for each authentication.

Ultimately the only effective keys are dependent on the user's
password (key) which is centrally controlled in the OTI model.  So the
organization still exerts control over the quality of passwords and
can enforce their use.

The SSH soft-token model provides an interesting contrast and
underscores the difference in philosophy.  The actual authentication
secret is the private RSA key.  Anyone who posesses the private key
can implement the user's identity.  The user's password only serves to
protect implementation of the identity.

In OTI posession of the identity token is insufficient to implement
the identity.  Actual implementation is dependent on the user
expressing his secret in combination with the contents of the identity
token.

>   Douglas E. Engert  <[EMAIL PROTECTED]>
>   Argonne National Laboratory

Best wishes for a pleasant weekend.

}-- End of excerpt from "Douglas E. Engert"

As always,
Greg

--
 The Hurderos Project
 Open Identity, Service and Authorization Management
   http://www.hurderos.org

"I had far rather walk, as I do, in daily terror of eternity, than feel
that this was only a children's game in which all of the contestants
would get equally worthless prizes in the end."
-- T. S. Elliot

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Nicolas Williams]

On Thu, Feb 01, 2007 at 06:47:43PM -0500, Sam Hartman wrote:
> OK, so the requirements you are trying to meet are:
> 
> 1) soft token support for flash drives.
> 
> 2) Support for central password management.
> 
> 3) Allow minimal or no identifying information on the token.
> 
> Any more?

4) Interoperability (meaning that you can use the softtoken on any OS).

   Which to me means a standard, de facto or otherwise, for the
   softtoken format.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Sam Hartman]

OK, so the requirements you are trying to meet are:

1) soft token support for flash drives.

2) Support for central password management.

3) Allow minimal or no identifying information on the token.

Any more?


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Marcus Watts]

Jeffrey Hutzelman <[EMAIL PROTECTED]> had replied:
> Of course, I should note that it's your OTI proposal that I'm suggesting 
> you bring to the working group.  The bit about public flogging should be 
> written up separately and sent directly to rfc-editor@rfc-editor.org, 
> without prior publication as an I-D, per item 19 in the FAQ at 
> 

Your deadline of 2007-04-01 is coming up.  You should probably hurry
if you want this to be accepted.

;-)

-Marcus Watts

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Thursday, February 01, 2007 05:15:56 PM -0500 Jeffrey Hutzelman 
<[EMAIL PROTECTED]> wrote:

>
>
> On Thursday, February 01, 2007 03:06:21 PM -0600 [EMAIL PROTECTED] wrote:
>
>>> What keeps a user from copying the identity token from the USB
>>> device to a local or shared file system to avoid having to insert
>>> the USB device all the time?
>>
>> We were considering public flogging but were unsure if we could get it
>> into an IETF draft.
>
> 
>
> Anyone can submit an internet-draft; just write up your proposal
> according  to  and send it
> off to  [EMAIL PROTECTED]
>
> You should then bring up your proposal on the Kerberos Working Group
> mailing list, [EMAIL PROTECTED]  We're beginning to move into the area
> of preauthentication and improving the initial authentication exchange,
> and  while I can't guarantee that your proposal will be well-received, it
> will  certainly receive the same consideration as a number of others that
> have  recently been raised.
>
> 

Of course, I should note that it's your OTI proposal that I'm suggesting 
you bring to the working group.  The bit about public flogging should be 
written up separately and sent directly to rfc-editor@rfc-editor.org, 
without prior publication as an I-D, per item 19 in the FAQ at 


-- Jeff

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Jeffrey Hutzelman]

On Thursday, February 01, 2007 03:06:21 PM -0600 [EMAIL PROTECTED] wrote:

>> What keeps a user from copying the identity token from the USB
>> device to a local or shared file system to avoid having to insert
>> the USB device all the time?
>
> We were considering public flogging but were unsure if we could get it
> into an IETF draft.



Anyone can submit an internet-draft; just write up your proposal according 
to  and send it off to 
[EMAIL PROTECTED]

You should then bring up your proposal on the Kerberos Working Group 
mailing list, [EMAIL PROTECTED]  We're beginning to move into the area 
of preauthentication and improving the initial authentication exchange, and 
while I can't guarantee that your proposal will be well-received, it will 
certainly receive the same consideration as a number of others that have 
recently been raised.




> Security starts with user training and making it unnecessary for them
> to want to do things like that.

In this case, I think that is unrealistic.  The thing users want to avoid 
is "Oh, damn, I have to dig out this stupid USB thing and plug it in before 
I can use my computer, what a pain."  They'll do that by copying the file 
off, especially after the first few instances of "Oh, damn, I have to dig 
out this stupid USB thing and plug it in to use my laptop, and I can't 
because I'm in Europe and the USB thingy is in Pittsburgh".


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


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[g . w]

On Jan 31,  8:42am, "Douglas E. Engert" wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Good afternoon to everyone, apologies for not being more prompt.
Trying to position myself to be in the mountains for a few days of
skiing starting this weekend.

> What keeps a user from copying the identity token from the USB
> device to a local or shared file system to avoid having to insert
> the USB device all the time?

We were considering public flogging but were unsure if we could get it
into an IETF draft.

Security starts with user training and making it unnecessary for them
to want to do things like that.  Hence our focus on a seamless
integration with Kerberos.

> What are the security implications if the identity token is
> stolen?

A concern certainly relevant to the point above.

The identity token itself contains no identifying information and is
useless without the Kerberos password/key even if the owner of the
token is known.

An additional valid concern is the possibility for a stolen token to
be used as known material for an attack against the encrypted OTI
payload of a captured AS_REQ.  However, the payload contains the IP
address of the KDC along with the authentication time so there is a
known element to look for if someone wants to start trying random keys
on the payload to see what pops out.  We have tossed around the idea
of payload location shifting to help combat things like that.

Given proper failure throttling on the KDC the idea of grabbing a
token and trying passwords is hopefully a non-starter.

> How does this compare to using cert and key on the USB device with
> PKINIT rather then your identity token?
>
> How does this compare to using a smart card or USB equivelent of a
> smartcard with PKINIT? To the user they still have to insert the
> card or USB device, and have to enter a pin or password?

In your subsequent e-mail reply you were completely correct in your
analysis.  One of the objectives in all this is to provide centralized
password management and control in a soft token environment.

A bit more on that later this evening.

}-- End of excerpt from "Douglas E. Engert"

As always,
Greg Wettstein

--
 The Hurderos Project
 Open Identity, Service and Authorization Management
   http://www.hurderos.org

"More people are killed every year by pigs than by sharks, which shows
 you how good we are at evaluating risk."
- Bruce Schneier
  Beyond Fear

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KfW 3.1: kinit.exe, krb5.ini and ticket_lifetime

[Jay Stamps]

Hi Sam:

> Jay> Is this a bug?
>
>It is a bug that  kinit.exe in KFW treats default_lifetime as minutes.
>
>I think it's also a bug that absent everything else NIM doesn't fall
>back to default_lifetime in krb5.conf.

In my experience, absent everything else the default is ten hours. I 
agree that for NIM, krb5.ini should at least stand betw the Windows 
registry and the ultimate fall-back position of 10 hrs.

Is this on anyone's to-fix list?

(Also glad to learn I'm not hallucinating.)

-J


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KfW 3.1: kinit.exe, krb5.ini and ticket_lifetime

[Sam Hartman]

So, I filed the bug by sending it to [EMAIL PROTECTED]  As you
probably know, we recently hired a new KFW engineer; he's coming up to
speed and until that happens it is hard for me to give useful project
plans for what MIT plans to do with KFW.

--Sam


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: One Time Identification, a request for comments/testing.

[Douglas E. Engert]

I was trying to get the authors of the note to say this, as
it appears that their approach is equivalent to soft tokens
but may have some advantages with regard to password policies.


Nicolas Williams wrote:
> On Wed, Jan 31, 2007 at 08:42:43AM -0600, Douglas E. Engert wrote:
>> What keeps a user from copying the identity token from the USB
>> device to a local or shared file system to avoid having to insert
>> the USB device all the time?
>>
>> What are the security implications if the identity token is
>> stolen?
>>
>> How does this compare to using cert and key on the USB
>> device with PKINIT rather then your identity token?
>>
>> How does this compare to using a smart card or USB equivelent
>> of a smartcard with PKINIT? To the user they still have to insert
>> the card or USB device, and have to enter a pin or password?
> 
> You're correct -- softtokens aren't a replacement for real smartcards.
> 
> That doesn't stop a softtoken from being useful though.
> 
> Compare softtokens to passphrase-protected ssh private key files in
> users' home directories :)

These suffer form policy control of the passphase used to encrypt the
key. The user can change the passphrase, or remove it all together!
This is a problem for oraganizations that need to enforce password
quality rules. It all so allows for offline guessing attacks.
(A smart card at least enforces some rules on the pin, and
defeats the guessing attack buy turring off the card after some small
number of guesses.)

It sounded like the identity token approach required the use of a
password as well, so it might get around some of the password policy
issues, as the KDC gets to enforce the policies. I would like the authors
to comment more on this.

> 
> Nico

-- 

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

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos environment under windows

[Christopher D. Clausen]

I don't know to do this from C code, but I generally kinit -kt 
\path\to\keytab principal/[EMAIL PROTECTED] and then run the app as needed. 
No need to additionaly code in keytab support into the app.

< wrote:
> Hi,
>
> actually I'm trying to write a C app (similar to the sample gss-client
> and gss-server) that should use the test realm instead of the real
> Windows Domain based realm. Where do I have to put the krb5.ini? I
> copied it to %SystemRoot% but it doesn't seem to be recognized...
>
> Hitherto my code looks like:
>
> srv_name = "[EMAIL PROTECTED]";
>
> srv_name_buff.value = srv_name;
> srv_name_buff.length = strlen(srv_name);
>
> maj_stat = gss_import_name(&min_stat, &srv_name_buff,
> (gss_OID) gss_nt_service_name,
> &srv_gss_name);
>
> maj_stat = gss_display_name(&min_stat, srv_gss_name,
> &srv_name_buff,
>   (gss_OID *) NULL);
>
> printf("srv_name = %s\n", (char*) srv_name_buff.value);
>
> And the output of this snippet is:
>
> srv_name = test-service/[EMAIL PROTECTED]
>
> But in %SystemRoot%\krb5.ini I set the default realm to
> MY.KRBTEST.REALM...
>
> Additionally I need a way to specify the keytab file used to lookup
> the
> pass for test-service. Is there another way than specifying
> default_keytab_file in the krb5.ini? And how do I tell my programm to
> use the keytab to acquire the service credentials? 



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: putty/winscp with gssapi/krb5 ticket forwarding

[Christopher D. Clausen]

Lars Schimmer <[EMAIL PROTECTED]> wrote:
> Christopher D. Clausen wrote:
>> Lars Schimmer <[EMAIL PROTECTED]> wrote:
>>> Christopher D. Clausen wrote:
 So you have an Active Directory domain that the Windows machines
 are on?
>>>
>>> Yes, there is a AD domain in which the PCs are.
>>>
 And a seperate Kerberos Realm for the Linux machines?
>>>
>>> The REALM is the same as the AD domain (both are CGV.TUGRAZ.AT ir in
>>> lower case cgv.tugraz.at)
>>
>> Okay, this sounds bad.  You'll likely need to rename either the
>> domain or the realm.  (I believe there is a Windows tool to rename a
>> domain.)
>
> OK, we are just 20 people here using our REALM and no entry in DNS
> server, I think it is easier to rename the REALM instead of the AD
> domain. We got a /25 subnet and a DNS entry cgv.tugraz.at (yes,
> academic).
> Within this I wanted to setup OpenAFS (I think it should name after
> the dns entry cgv.tugraz.at), krb5 auth (I thought CGV.TUGRAZ.AT is
> best and the only usable one), linux clients (no probs so far) and a
> AD domain with a own AD domain server. And I think for
> DNS/network/... purpose it is far easier to name the AD domain after
> the DNS entry cgv.tugraz.at, e.g. names of clients, IPs via dhcp,...).
> I thought the only possible useable REALM was CGV.TUGRAZ.AT and I set
> it up that way and was happy as it worked for the most needed parts
> (login into AD domain [with own AD password], getting ticket from
> krb5 server for CGV.TUGRAZ.AT REALM and getting token automatic).

If your eventual goal is to setup OpenAFS, I'd suggest ONLY using the AD 
domain if your Kerberos realm only has a few users now anyway.  You can 
do just about anything in AD that could do with MIT Kerberos, although 
the management from the non-Windows side of things is a little annoying, 
but it is possible.  Having everything in one Kerberos realm simplifies 
single-sign-on and cross-platform issues.

>> You cannot have this work just b/c the realms are the same.  There
>> needs to be a trust setup between the realms, or you need to have
>> ALL your non-Windows machines also use the Windows domain as a KDC
>> instead of the MIT one.
>
> Some time ago it was easier to setup the MIT krb5 server instead of
> using AD krb5 auth together with OpenAFS.
>
> And I thought using MIT krb5 software on Windows with a active ticket
> for the correct REALM is the needed part for loging in with putty via
> ticket forwarding.

It is early as easy to have an AFS cell use an AD domain as using MIT or 
Heimdal.  Just generate a keytab for the afs/cell service principal and 
use asetkey to add it to the KeyFile.

Re: putty/winscp with gssapi/krb5 ticket forwarding

[Lars Schimmer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher D. Clausen wrote:
> Lars Schimmer <[EMAIL PROTECTED]> wrote:
>> Christopher D. Clausen wrote:
>>> Lars Schimmer <[EMAIL PROTECTED]> wrote:
 Thanks for the link.
 Maybe I don4t get it right on my thoughts.
 Setup here:
 AD with 1 server and x clients
 krb5 server on debian on extra machine
>>> So you have an Active Directory domain that the Windows machines are
>>> on?
>> Yes, there is a AD domain in which the PCs are.
>>
>>> And a seperate Kerberos Realm for the Linux machines?
>> The REALM is the same as the AD domain (both are CGV.TUGRAZ.AT ir in
>> lower case cgv.tugraz.at)
> 
> Okay, this sounds bad.  You'll likely need to rename either the domain 
> or the realm.  (I believe there is a Windows tool to rename a domain.)

OK, we are just 20 people here using our REALM and no entry in DNS
server, I think it is easier to rename the REALM instead of the AD domain.
We got a /25 subnet and a DNS entry cgv.tugraz.at (yes, academic).
Within this I wanted to setup OpenAFS (I think it should name after the
dns entry cgv.tugraz.at), krb5 auth (I thought CGV.TUGRAZ.AT is best and
the only usable one), linux clients (no probs so far) and a AD domain
with a own AD domain server. And I think for DNS/network/... purpose it
is far easier to name the AD domain after the DNS entry cgv.tugraz.at,
e.g. names of clients, IPs via dhcp,...).
I thought the only possible useable REALM was CGV.TUGRAZ.AT and I set it
up that way and was happy as it worked for the most needed parts (login
into AD domain [with own AD password], getting ticket from krb5 server
for CGV.TUGRAZ.AT REALM and getting token automatic).


> Maybe someone else has an idea for you?  I don't think you can even 
> setup a realm trust if the realm names are the same b/c the cross-realm 
> TGT (krbtgt) would overwrite the current realms TGT.
> 
>>> Do you have a realm trust between these?  B/c its not likely to work
>>> if you don't.
>> There is no realm trust between both (which are the same).
>> I use cgv.tugraz.at as a AD domain for login and CGV.TUGRAZ.AT for
>> obtaining tickets/tokens.
> 
> You cannot have this work just b/c the realms are the same.  There needs 
> to be a trust setup between the realms, or you need to have ALL your 
> non-Windows machines also use the Windows domain as a KDC instead of the 
> MIT one.

Some time ago it was easier to setup the MIT krb5 server instead of
using AD krb5 auth together with OpenAFS.

And I thought using MIT krb5 software on Windows with a active ticket
for the correct REALM is the needed part for loging in with putty via
ticket forwarding.

> And please reply to the list and not to me directly.

Sorry, it went wrong here. Damned icedove.

> < 
> 


MfG,
Lars Schimmer
- --
- -
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: [EMAIL PROTECTED]
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFFwfoXmWhuE0qbFyMRAm8/AJ9pvmd8hS6M6xovpJEe39BSACcw9ACgkhu3
01yNq4Wx3ILKuC7u2gIAS7E=
=UNBZ
-END PGP SIGNATURE-

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KfW 3.1: kinit.exe, krb5.ini and ticket_lifetime

[Sam Hartman]

> "Jay" == Jay Stamps <[EMAIL PROTECTED]> writes:

Jay> Is this a bug? 

It is a bug that  kinit.exe in KFW treats default_lifetime as minutes.

I think it's also a bug that absent everything else NIM doesn't fall
back to default_lifetime in krb5.conf.


--Sam

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

RE: Kerberos environment under windows

[Peger, Daniel Heinrich]

Hi,

actually I'm trying to write a C app (similar to the sample gss-client
and gss-server) that should use the test realm instead of the real
Windows Domain based realm. Where do I have to put the krb5.ini? I
copied it to %SystemRoot% but it doesn't seem to be recognized...

Hitherto my code looks like:

srv_name = "[EMAIL PROTECTED]";

srv_name_buff.value = srv_name;
srv_name_buff.length = strlen(srv_name);

maj_stat = gss_import_name(&min_stat, &srv_name_buff,
(gss_OID) gss_nt_service_name,
&srv_gss_name);

maj_stat = gss_display_name(&min_stat, srv_gss_name, &srv_name_buff,
  (gss_OID *) NULL);

printf("srv_name = %s\n", (char*) srv_name_buff.value);

And the output of this snippet is:

srv_name = test-service/[EMAIL PROTECTED]

But in %SystemRoot%\krb5.ini I set the default realm to
MY.KRBTEST.REALM...

Additionally I need a way to specify the keytab file used to lookup the
pass for test-service. Is there another way than specifying
default_keytab_file in the krb5.ini? And how do I tell my programm to
use the keytab to acquire the service credentials?

Best Regards,
Daniel.

-Original Message-
From: Christopher D. Clausen [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 01, 2007 3:12 AM
To: Peger, Daniel Heinrich; kerberos@mit.edu
Subject: Re: Kerberos environment under windows

Peger, Daniel Heinrich <[EMAIL PROTECTED]> wrote:
> How do I tell a C/C++ (using GSSAPI) app what my current kerberos
> environment is? For testing purposes I don't want to use the standard
> environment but authenticate against a test kerberos setup, which
> needs to be specified somwhere.

Edit the krb5.ini file and specify your test realm,  Then just kinit to 
a user in that realm before starting putty.  No need to do anything in 
C.