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

2007-02-06 Thread g . w 
On Feb 5, 10:04am, Sam Hartman wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Good evening to everyone.

> >>>>> "g" == g w <[EMAIL PROTECTED]> writes:
> 
> g> On Feb 1, 6:47pm, Sam Hartman wrote: } Subject: Re: One Time
> g> Identification, a request for comments/testing.
> 
> g> Good morning to everyone, hope your weekend is going well.
> 
> >> 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?
> 
> g> Just a point of clarification.
> 
> g> Are we discussing requirements for general soft token support
> g> or what OTI attempts to bring to the table?
> 
> g> If the latter is the case I would offer
> 
> g>- Authentication attempt unique keying.
> 
> What is this?

OTI generates a unique symmetric key for each authentication attempt,
within a granularity of one second.  If people are convinced the
scheme has strong replay attack avoidance it could be used
bi-directionally, ie, for the AP_REP as well.

I like to think of it as OTP designed specifically for the direct
Kerberos authentication model.

> g>- Token invariance across password changes.  That may actually
> g> be a subset of #2 above.

> Why do we want this as a requirement?

Practical logistics for centralized password management.

If the user changes their password you want to avoid having to
distribute a new token to them.

}-- End of excerpt from Sam Hartman

As always,
Greg

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

"There's nothing in the middle of the road 'cept yellow lines and
squashed armadillos."
-- Mike Hightower

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

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

2007-02-05 Thread Sam Hartman 
> "g" == g w <[EMAIL PROTECTED]> writes:

g> On Feb 1, 6:47pm, Sam Hartman wrote: } Subject: Re: One Time
g> Identification, a request for comments/testing.

g> Good morning to everyone, hope your weekend is going well.

>> 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?

g> Just a point of clarification.

g> Are we discussing requirements for general soft token support
g> or what OTI attempts to bring to the table?

g> If the latter is the case I would offer

g>  - Authentication attempt unique keying.

What is this?

g>  - Token invariance across password changes.  That may actually
g> be a subset of #2 above.


Why do we want this as a requirement?


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

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

2007-02-04 Thread Frank Cusack 
On February 2, 2007 5:46:55 PM -0500 Peter Iannarelli 
<[EMAIL PROTECTED]> wrote:
> I don't believe I've seen anyone with a token strapped to their
> notebook and their PIN etched on the case.

I know a few thousand such users.  Not with the PIN etched :-) but with
a credit card form factor token strapped to the laptop lid in a clear
plastic envelope.  Pretty convenient.

> The reality is different. Software tokena require a M2M or
> machine to machine interface (software). Deploying this software
> on 100 workstations is problematic. Multiply that by 1000, within
> a heterogeneous environment, and its an administrative nightmare.

I tend to disagree.  Yes at the few dozen or maybe even 100 machine level
it can be a chore to maintain (but installation itself should be trivial),
but once you hit multi-hundreds if you can't maintain the software you
really should worry about that first before worrying about tokens of any
sort.  Keeping user's workstation software up to date automatically is an
absolute must in any large environment, and a sunk cost as far as
administrative overhead goes.

> Hardware tokens are the most portable and most secure.

I agree with that, except for the case of smartcards and portability.

These days, I'm surprised java tokens for phones and blackberrys aren't
more popular.  The phone has the advantage that the user is very unlikely
to forget it somewhere.

-frank

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

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

2007-02-03 Thread g . w 
On Feb 1,  6:47pm, Sam Hartman wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Good morning to everyone, hope your weekend is going well.

> 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?

Just a point of clarification.

Are we discussing requirements for general soft token support or what
OTI attempts to bring to the table?

If the latter is the case I would offer

- Authentication attempt unique keying.

- Token invariance across password changes.  That may actually
  be a subset of #2 above.

Have a good weekend.

}-- End of excerpt from Sam Hartman

As always,
Greg

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


"We trained hard..but every time we were beginning to form up into
teams, we would be reorganised. I was to learn later in life that we
tend to meet any new situations by reorganising...  and a
wonderful process it can be for creating the illusion of progress,
while producing inefficiency and demoralisation."
-- Petronius (6 AD)

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

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

2007-02-02 Thread g . w 
On Feb 2, 10:05am, Jim Rees wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Hi Jim, hope the weekend is going well for you.

> So would it be fair say this is sort of like using a smartcard in that you
> need both possession of the token and knowledge of a PIN?

Jeff already did a nice job of differentiating a smart card/PIN from
what is being suggested with OTI.

> And that the KDC guards the PIN against brute force guessing,
> because each guess requires a transaction against the KDC?  So
> stealing the token gets the attacker nothing?

Correct, the KDC is the only entity which is in a position to verify
that the expression of the identity is valid.

This is the reason why the decision was made to not encrypt the
identity token.  It actually increases the security liability if the
token is lost.  If the token is encrypted there is an opportunity for
an off-line guessing attack to yield not only the token but validation
of the password as well.

Have a good weekend.

}-- End of excerpt from Jim Rees

As always,
Greg Wettstein

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

"Human beings, who are almost unique in having the ability to learn
 from the experience of others, are also remarkable for their apparent
 disinclination to do so."
-- Douglas Adams

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

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

2007-02-02 Thread g . w 
On Feb 2,  9:48am, Ken Renard wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Hi Ken, thanks for the note, hope the week went well for you.

> > The identity token is included in an identification payload which  
> > is symmetrically encrypted and included in the AS_REQ authorization  
> > field.

> Any reason why this couldn't be implemented as a preauthentication
> type (especially with the PAL in 1.6)?  Might give you more
> flexibility with respect to multiple exchanges or when a principal
> requires this type of authentication.  This might even fit into the
> SAM(2) preauth type.

A well taken and valid observation, certainly something we've been
thking about.  Just a couple of comments.

First, to be perfectly honest, the reason it went into the AS_REQ
authorization field in the prototype implementation was that most of
our work is focused on authorization theory and I knew the code path
well :-)

In a larger, and perhaps more philosophical context, we view OTI as
authorization rather than pre-authentication.  It is of course one of
those hundreds of semantic differences one can argue about in
technology.

All of the thinking in OTI was driven by our work in identity linked
authorization.  In the IDfusion authorization model the auth_data
payload fields of Kerberos tickets get loaded with identities which
consist of 160 bit numbers.  The identity token in OTI contains just
one of the 160 bit identities which can be assigned to a user.

If the OTI identity payload is successfully processed the TGT gets
loaded with the two-factor/OTI identity from the token sent in the
AS_REQ.  When a service ticket is granted against the user credentials
the service and service instance identities get generated for the
service ticket while the user identity propagates from the TGT.

The end result of all this is that the application has the ability to
determine the quality of authentication based on the user identity in
the service ticket.  So an organization can require two-factor for
access to sensitive resources such as HR/finances etc. while
implementing a more relaxed policy for something like e-mail.

So if Jeff uses OTI and forgets his token he can still read e-mail
while he's in Europe, but he can't run PeopleSoft. :-)

> Operationally, users might just stick their USB key in and leave it
> there (same as copying to filesystem).  From there, it's just
> filesystem privileges that separate an attacker from the real user.

Certainly another threat scenario for USB flash dongle based
two-factor.

As we've been discussing OTI is not only about two factor but also
about an alternate paradigm for Kerberos centric multi-factor.  The
identity token only implements the user's identity when it operates in
concert with the user's password.

> -Ken Renard

Thanks for the observations and comments.

Have a good weekend.

}-- End of excerpt from Ken Renard

As always,
Greg

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

"True.  When your hammer is C++, everything begins to look like a thumb."
-- Steve Haflich

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

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

2007-02-02 Thread Peter Iannarelli 
Good day everyone:

I am throughly enjoying this thread.

Mr. Wettstein, your reference to the manner in which people ensure
they do not forget their tokens is, to say the least appropriate
but please keep in mind that our tokens come in many form factors.

- Calculator style (RB)
- Dongle style (KT)
- Class 8 mass storage device (iPod, thumbdrive, mp3 player, etc...)
- USB (UB)
- SmartCard (SC)
- Hard Disk (ST)
- BlackBerry (BB)
- CellPhone (MT)
- SMS (WT)

I don't believe I've seen anyone with a token strapped to their
notebook and their PIN etched on the case. Still though I like
the manner in which you justify software token use.

The reality is different. Software tokena require a M2M or
machine to machine interface (software). Deploying this software
on 100 workstations is problematic. Multiply that by 1000, within
a heterogeneous environment, and its an administrative nightmare.
Hardware tokens are the most portable and most secure. Hardware
token out sell software tokens by a factor of approx. 100 to 1.
Additionally, one can't use a public station because the software
to access or drive that token on the device in question isn't available.

If I can be of any assistance in getting 2FA into Kerberos, simply
ask. If I remember currently I submitted a proposal to kerbdev,
Sam Hartman and Ken Hornstein some years back. Perhaps that document
is still around some place in the archives. It presented an open
framework for any type of 2FA.

Again, if anyone would like input or assistance from CRYPTOCard,
just let me know.


-- 
Peter Iannarelli
Vice President, Research & Development
CRYPTOCard Incorporated

http://www.cryptocard.com


[EMAIL PROTECTED] wrote:
> On Feb 1,  5:15pm, Jeffrey Hutzelman wrote:
> } Subject: Re: One Time Identification, a request for comments/testing.
> 
> Good day to everyone.
> 
>> 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 <http://www.ietf.org/ietf/1id-guidelines.html> 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.
> 
> I do appreciate the offer and will review the proposal guidelines.
> 
> That being said I'm certainly no IETF politician.  I also don't have
> any agenda, corporate or otherwise with any of this.  I believe there
> needs to be people doing interesting stuff in this field and I enjoy
> the challenge of innovation.  Its not sexy, nor fun, like building a
> new desktop environment so there is a paucity of Open-Source interest
> in the arena.
> 
> OTI ultimately comes from our work and interest in how to define
> identity.  As such its a paradigm shift which is always a difficult
> sell.
> 
> But we would certainly entertain a discussion if anyone was interested
> in any type of collaboration on this.
> 
>>> 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".
> 
> Luckily there is a sure and certain solution to the problem.  Spend
> money implementing CryptoCard or any one of a number of other
> solutions which people will gladly sell you.
> 
> The only organizational challenge is dealing with the user who forgot
> their CryptoCard the last time they flew to Europe and now have it
> securely duct taped to the back of their laptop, with the pin number
> written in magic marker on the duct tape so they don't forget it.
> 
> Jeff, you and I have been doing this stuff for a long time.  I think
> we both

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

2007-02-02 Thread Jeffrey Hutzelman 
On Fri, 2 Feb 2007 [EMAIL PROTECTED] wrote:

> That being said I'm certainly no IETF politician.

Good.  Neither are the rest of us, for the most part.  What we are is
engineers trying to produce quality network protocol standards, preferably
in non-infinite amounts of time.  If you have something to contribute,
please do.


> Its not sexy, nor fun, like building a
> new desktop environment so there is a paucity of Open-Source interest
> in the arena.

On the contrary, I think you'll find there are plenty of people who
consider work at this level fun.  I, for one, consider things like a good
desktop environment important but have absolutely no desire to actually
work on them.  It really does take all kinds, or at least more than one
kind.

> The only organizational challenge is dealing with the user who forgot
> their CryptoCard the last time they flew to Europe and now have it
> securely duct taped to the back of their laptop, with the pin number
> written in magic marker on the duct tape so they don't forget it.

Yes; hardware tokens have some of the same challenges as softtokens; they
just manifest themselves in slightly different ways.  The comment someone
made earlier about using a thumbprint scanner in place of a PIN(*)
intrigues me, though I'm not yet convinced it's actually feasible, and of
course it doesn't apply in the situations where you want a softtoken to
avoid special hardware.


Just to be clear, I'm not suggesting that there is no place for soft
tokens, either of the traditional type which stores a private key or of
the sort you propose.  I was simply pointing out that these don't work in
the same way as hardware tokens or smartcards, or each other for that
matter.  Each technology has different features, and it's precisely
_because_ your proposal doesn't work like a smartcard that makes it
interesting in the first place.


(*) Note that what he actually proposed was using a thumbprint scanner to
produce keying material, but that's not actually workable, because the
output from such a scanner does not have enough deterministic bits to
produce a strong key.

-- Jeff


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

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

2007-02-02 Thread Douglas E. Engert 


John Rudd wrote:
> 
> 
> Perhaps I'm completely wrong, but ...
> 
>...
> 
> I think a more interesting approach would be a non- "dumb data stick" 
> approach.  It might start to sound like a variation of a smartcard, but 
> why not think about a new USB device that's perhaps about the size of a 
> USB data stick.  It might present itself to the host computer as 2 devices:
> 
> 1) a small storage area which contains a java application (not an 
> applet: it shouldn't run in a protect environment that keeps it from 
> reading and storing files on the host, etc.). (it doesn't have to be 
> java, it could be a selection of java, perl, python, native-windows, 
> native-mac, native-linux, native-freebsd, and native-solaris apps if you 
> want; the point is, it should be some selection that allows the stick to 
> be used pretty much anywhere)
>

That sounds like:
http://www.computerlinks.de/open/datasheet/ActivKey_DS_A4_EN.pdf

There are other devices like this, basically combine the smart card
and the reader into one USB device and support some other
applets too.  With the Java smart cards, one of the applets is the
traditional "smart card" applet. Other applets could also be on the card.

Its the middle ware to use these that is so hard to get straight.
Thats why PKINIT sounds so attractive, Its already in Windows, and
now Heimdal and MIT.


> 2) an embedded computer with a thumb scanner like the ones we're 
> starting to see on lots of laptops.  The embedded computer should never 
> present the actual thumb scanning data to the host computer.
> 

Sounds like the http://www.tri-dsystems.com/
BIOMETRIC 3-FACTOR AUTHENTICATION

Finger print reader, smartcard and OTP in one.
([EMAIL PROTECTED] author of a popular pam_krb5 works for them.)



> 
> 
> When the user plugs in the "smartstick":
> 
> a) The user runs the whichever app in device#1 is appropriate.
> 
> b) The app asks the user for a principle, and tells them to scan their 
> thumb.
> 
> c) The app asks the KDC (indicated in the local host config?) for the 
> encrypted tgt, just like it was kinit.
> 
> d) The app sends the encrypted tgt to the embedded computer.
> 
> e) The embedded computer tries to use the thumb print to decrypt the 
> tgt.  If it is successful, it hands the decrypted tgt back to the app.
> 
> f) The app uses the host's config information to determine how and where 
> to store the tgt, so that it is usable by the host's kerberos applications.
> 
> 
> Upside: The user doesn't need to remember a passphrase, nor a PIN.  The 
> process is no more vulnerable to an adversary than kinit is already 
> (perhaps less, because the adversary can't run something akin to a 
> keyboard-logger to intercept the passphrase/thumb-print).
> 
> Downsides: It may require that a user has both passphrase based 
> principles/keys and thumb print based principles/keys, and some 
> mechanism to pick between them.  And, obviously, it depends upon a 
> device that, as far as I know, does not yet exist.

See above, it may be.

> 
> ___
> krbdev mailing list [EMAIL PROTECTED]
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  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: One Time Identification, a request for comments/testing.

2007-02-02 Thread g . w 
On Feb 1,  5:15pm, Jeffrey Hutzelman wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Good day to everyone.

> 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 <http://www.ietf.org/ietf/1id-guidelines.html> 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.

I do appreciate the offer and will review the proposal guidelines.

That being said I'm certainly no IETF politician.  I also don't have
any agenda, corporate or otherwise with any of this.  I believe there
needs to be people doing interesting stuff in this field and I enjoy
the challenge of innovation.  Its not sexy, nor fun, like building a
new desktop environment so there is a paucity of Open-Source interest
in the arena.

OTI ultimately comes from our work and interest in how to define
identity.  As such its a paradigm shift which is always a difficult
sell.

But we would certainly entertain a discussion if anyone was interested
in any type of collaboration on this.

> > 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".

Luckily there is a sure and certain solution to the problem.  Spend
money implementing CryptoCard or any one of a number of other
solutions which people will gladly sell you.

The only organizational challenge is dealing with the user who forgot
their CryptoCard the last time they flew to Europe and now have it
securely duct taped to the back of their laptop, with the pin number
written in magic marker on the duct tape so they don't forget it.

Jeff, you and I have been doing this stuff for a long time.  I think
we both agree its not possible to technically erradicate stupidity.

There is an understandable fixation about copying off the identity
token.  I think the reason for it is the issue of paradigm shift which
I discussed above.  Physical protection of a two factor token arises
from a paradigm where the token is capable of independently
implementing the user's identity.

Thats why RSA private keys get stuffed inside a self-destructing card
or device, to force direct physical possession of the identity
implementation.  There is still a secret which ties implementation of
the identity to a user, only we call it a PIN number rather than a
password.

In OTI the paradigm shifts, the implementation of the identity
involves a direct interaction between the token and the user's secret
(key).  Obviously one prefers not to have tokens go wandering about,
that is a standard security predicate of attacker knowledge
deprivation.  But, and its an important but, the token is not
independently capable of implementing the user's identity.

So Jeff, your IDtoken is free to go to Europe inside your laptop.
Interestingly, it avoids a Denial of Service (DOS) attack from the
person whose draft you frowned on, who decided to punch 0-0-0-0 into
your CryptoCard four times to make your life miserable in Europe.

I'm assuming, of course, standard security policy which requires a
trip to the HelpDesk with a picture ID in the event of a need to
re-establish authentication for someone... :-)

> -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>

--..., ...--

Best wishes for a pleasant weekend.

}-- End of excerpt from Jeffrey Hutzelman

As always,
Greg Wettstein

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

"Everything should be made as simple as possible, but not simpler."
-- Albert Einstein

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

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

2007-02-02 Thread Nicolas Williams 
On Fri, Feb 02, 2007 at 10:16:28AM -0800, John Rudd wrote:
> It seems to me that if you're talking about a simple dumb USB thumb 
> drive/data stick, that you're not going to be able to do anything to 
> prevent an adversary from copying that data to a local host, and then 
> brute-forcing the data over time.  So, essentially, the only advantage 
> over "just putting a non-protected keytab on a USB drive" and any other 
> dumb-data-stick process is some amount of time it takes to overcome 
> whatever encryption you've done on the keytab.

The advantage of softtokens over hardtokens is that they are
software-based, and when you don't have a smartcard around they can be
useful in debugging, testing, or even as a cheap alternative to
smartcards.  And yes, softtokens are susceptible to offline dictionary
and brute-force attacks by any attacker that can get their hands on
them.  But have you ever used passphrase-protected ssh private key
files?  I bet you have.  It's darn useful because there's no need to buy
a new piece of hardware -- you just have to be more careful than you
might have to be with a smartcard.

There's not much new here.  This thread is starting to repeat itself.

The only new questions here are:

 - should MIT krb5 have softtoken support?

   (And note that if it has PKCS#11 support for PKINIT and/or PA-ENC-
   TIMESTAMP long-term symmetric keys then it will have softtoken
   support wherever PKCS#11 softtoken providers are available.)

 - should there be a standard for softtoken formats?

   Since there are at least two PKCS#11 softtoken providers this is an
   interesting question.  Where should such thing be standardized, if at
   all?  Perhaps informally would be best.

> I think a more interesting approach would be a non- "dumb data stick" 
> approach.  It might start to sound like a variation of a smartcard, but 
> why not think about a new USB device that's perhaps about the size of a 
> USB data stick.  It might present itself to the host computer as 2 devices:

This stuff exists.  Google it.  And it is just a smartcard.  Using
bimetrics instead of PINs is interesting and a subject for another
thread, probably on a different forum.

Nico
-- 

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

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

2007-02-02 Thread Ken Renard 
> The identity token is included in an identification payload which  
> is symmetrically encrypted and included in the AS_REQ authorization  
> field.

Any reason why this couldn't be implemented as a preauthentication  
type (especially with the PAL in 1.6)?  Might give you more  
flexibility with respect to multiple exchanges or when a principal  
requires this type of authentication.  This might even fit into the  
SAM(2) preauth type.

Operationally, users might just stick their USB key in and leave it  
there (same as copying to filesystem).  From there, it's just  
filesystem privileges that separate an attacker from the real user.


-Ken Renard



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

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

2007-02-02 Thread Jim Rees 
So would it be fair say this is sort of like using a smartcard in that you
need both possession of the token and knowledge of a PIN?  And that the KDC
guards the PIN against brute force guessing, because each guess requires a
transaction against the KDC?  So stealing the token gets the attacker
nothing?

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

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

2007-02-02 Thread John Rudd 



Perhaps I'm completely wrong, but ...

It seems to me that if you're talking about a simple dumb USB thumb 
drive/data stick, that you're not going to be able to do anything to 
prevent an adversary from copying that data to a local host, and then 
brute-forcing the data over time.  So, essentially, the only advantage 
over "just putting a non-protected keytab on a USB drive" and any other 
dumb-data-stick process is some amount of time it takes to overcome 
whatever encryption you've done on the keytab.



I think a more interesting approach would be a non- "dumb data stick" 
approach.  It might start to sound like a variation of a smartcard, but 
why not think about a new USB device that's perhaps about the size of a 
USB data stick.  It might present itself to the host computer as 2 devices:

1) a small storage area which contains a java application (not an 
applet: it shouldn't run in a protect environment that keeps it from 
reading and storing files on the host, etc.). (it doesn't have to be 
java, it could be a selection of java, perl, python, native-windows, 
native-mac, native-linux, native-freebsd, and native-solaris apps if you 
want; the point is, it should be some selection that allows the stick to 
be used pretty much anywhere)

2) an embedded computer with a thumb scanner like the ones we're 
starting to see on lots of laptops.  The embedded computer should never 
present the actual thumb scanning data to the host computer.



When the user plugs in the "smartstick":

a) The user runs the whichever app in device#1 is appropriate.

b) The app asks the user for a principle, and tells them to scan their 
thumb.

c) The app asks the KDC (indicated in the local host config?) for the 
encrypted tgt, just like it was kinit.

d) The app sends the encrypted tgt to the embedded computer.

e) The embedded computer tries to use the thumb print to decrypt the 
tgt.  If it is successful, it hands the decrypted tgt back to the app.

f) The app uses the host's config information to determine how and where 
to store the tgt, so that it is usable by the host's kerberos applications.


Upside: The user doesn't need to remember a passphrase, nor a PIN.  The 
process is no more vulnerable to an adversary than kinit is already 
(perhaps less, because the adversary can't run something akin to a 
keyboard-logger to intercept the passphrase/thumb-print).

Downsides: It may require that a user has both passphrase based 
principles/keys and thumb print based principles/keys, and some 
mechanism to pick between them.  And, obviously, it depends upon a 
device that, as far as I know, does not yet exist.


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

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

2007-02-02 Thread Jeffrey Hutzelman 


On Friday, February 02, 2007 10:05:09 AM -0500 Jim Rees <[EMAIL PROTECTED]> 
wrote:

> So would it be fair say this is sort of like using a smartcard in that you
> need both possession of the token and knowledge of a PIN?  And that the
> KDC guards the PIN against brute force guessing, because each guess
> requires a transaction against the KDC?  So stealing the token gets the
> attacker nothing?

No.  Smart cards are not (generally) simple storage devices.  What guards a 
smartcard PIN against brute force guessing is that you only get a limited 
number of tries before the card locks itself and becomes useless.  And what 
protects the private key is the fact that only the card knows the key, so 
if the card is not physically present (or has been locked out due to too 
many wrong PIN's), it is impossible to perform crypto operations with the 
private key.

What we're talking about here is something completely different.  Yes, you 
need both posession of a physical object and a password.  But the 
similarity ends there.

-- Jeff

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

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

2007-02-01 Thread 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.

2007-02-01 Thread 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.

2007-02-01 Thread 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.

2007-02-01 Thread 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.

2007-02-01 Thread 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.

2007-02-01 Thread 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.

2007-02-01 Thread 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: One Time Identification, a request for comments/testing.

2007-02-01 Thread 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: One Time Identification, a request for comments/testing.

2007-01-31 Thread Nicolas Williams 
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 :)

Nico
-- 

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

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

2007-01-31 Thread Andrew Bartlett 
On Wed, 2007-01-31 at 07:02 -0500, Sam Hartman wrote:
> So, the USB flash stores the 160-bit RSA encrypted user identity?
> 
> 
> 
> 
> I think that this approach or something like it could be useful.  I'm
> not sure I'm happy with your key schedule, or some of the crypto
> details.  I'd prefer to think about whether RFC 3961 might provide
> better options.  Similarly, I'm not sure what you get out of RSA
> encryption.
> 
> An alternative proposal that seems like it would do the same thing
> from a security standpoint would be a way to combine a password key
> with pkinit.  You could store a soft certificate on a USB token.

I think developing a cross-platform USB 'tumb drive' based soft token
would be an immense benefit.  It could make PKINIT real for many small
sites that do not yet wish to invest in a token stack, and perhaps more
importantly, make PKINIT and smart-card login something that developers
and interested technical users can test with resources to hand.

Andrew Bartlett

-- 
Andrew Bartlett <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

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

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

2007-01-31 Thread Andrew Bartlett 
On Wed, 2007-01-31 at 15:17 -0600, Nicolas Williams wrote:
> On Thu, Feb 01, 2007 at 07:51:47AM +1100, Andrew Bartlett wrote:
> > I think developing a cross-platform USB 'tumb drive' based soft token
> > would be an immense benefit.  It could make PKINIT real for many small
> > sites that do not yet wish to invest in a token stack, and perhaps more
> > importantly, make PKINIT and smart-card login something that developers
> > and interested technical users can test with resources to hand.
> 
> What do you mean by "cross-platform"?

Works with windows desktops too :-)

> OpenSolaris has an OSS (CDDL'ed) PKCS#11 softtoken provider that does
> pretty much what you want.  It stores its files in a filesystem, by
> default in a sub-directory of the user's home directory; filesystem type
> does not matter.  Since you can put filesystems on a USB flash drive
> that should suffice for a "cross-platform" softtoken.
> 
> The specifics of the Solaris softtoken's directory layout and file
> formats are project private interfaces IIRC, but if there's interest I
> imagine that we could document them, make them committed public
> interfaces and help establish a standard for a cross-platform softtoken.

Love also has a PKCS#11 softtoken.  The details that I think might need
work are integration so that the logon systems on various platforms
'know' that the token is there, and the softtoken driver should be used.

Andrew Bartlett

-- 
Andrew Bartlett <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

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

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

2007-01-31 Thread Nicolas Williams 
On Thu, Feb 01, 2007 at 08:21:49AM +1100, Andrew Bartlett wrote:
> > What do you mean by "cross-platform"?
> 
> Works with windows desktops too :-)

But I think this means that you want the format of the softtoken to be
open and implementable by multiple implementors.

> Love also has a PKCS#11 softtoken.  The details that I think might need
> work are integration so that the logon systems on various platforms
> 'know' that the token is there, and the softtoken driver should be used.

Certainly those details should be worked out.  But if my softtoken
should work when plugged into a Solaris sytem, a Linux system or a
Windows system then the format must be agreed by all, or else users will
have to resort to installing one cross-platform implementation on all
those systems.

Nico
-- 

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

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

2007-01-31 Thread Nicolas Williams 
On Thu, Feb 01, 2007 at 07:51:47AM +1100, Andrew Bartlett wrote:
> I think developing a cross-platform USB 'tumb drive' based soft token
> would be an immense benefit.  It could make PKINIT real for many small
> sites that do not yet wish to invest in a token stack, and perhaps more
> importantly, make PKINIT and smart-card login something that developers
> and interested technical users can test with resources to hand.

What do you mean by "cross-platform"?

OpenSolaris has an OSS (CDDL'ed) PKCS#11 softtoken provider that does
pretty much what you want.  It stores its files in a filesystem, by
default in a sub-directory of the user's home directory; filesystem type
does not matter.  Since you can put filesystems on a USB flash drive
that should suffice for a "cross-platform" softtoken.

The specifics of the Solaris softtoken's directory layout and file
formats are project private interfaces IIRC, but if there's interest I
imagine that we could document them, make them committed public
interfaces and help establish a standard for a cross-platform softtoken.

Nico
-- 

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

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

2007-01-31 Thread Douglas E. Engert 
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?


[EMAIL PROTECTED] wrote:
> Good evening, I hope this note finds everyone's day going well.
> 
> Its becoming increasingly obvious that the utility of passwords are
> becoming problematic.  If users are forced into passwords with
> sufficient entropy they write them down.  Products such as PRTK are
> making it increasingly difficult to select passwords which can be
> easily remembered and yet are secure.
> 
> Common solutions to this problem include One Time Password systems and
> pre-authentication strategies such as PKINIT.  While effective these
> systems each have their own issues ranging from diminished entropy to
> complexity.
> 
> For the last several months we have been working on an alternative
> strategy for a system which combines two-factor authentication with
> strong single use passwords.  The primary focus of this work was to
> develop a system which integrated naturally with desktop based
> Kerberos authentication and was freely implementable.
> 
> The purpose of this note is to introduce the work and get
> comments/feedback from the community.
> 
> The proposal is referred to as OTI or One Time Identification.  The
> system is based on an identity token which can be carried on a
> standard USB flash disk.  The identity token is included in an
> identification payload which is symmetrically encrypted and included
> in the AS_REQ authorization field.  The KDC decrypts and verifies the
> identity upon receipt of the AS_REQ.  If the OTI identity matches that
> of the principal requesting the service the AS_REP proceeds.
> 
> The identity token consists of a DER encoded structure of the
> following information:
> 
>   1.) 32-bit identity epoch time.
>   2.) RSA encrypted 160-bit user identity.
> 
> The epoch time is randomly chosen when the user's identity token is
> generated.  RSA encryption is done against a private key held by the
> KDC.
> 
> When the AS_REQ is composed a DER encoded data structure of the
> following elements is created:
> 
>   1.) Authentication request time.
>   2.) IP address of target KDC server.
>   3.) RSA encrypted identity.
> 
> A time interval dependent key scheduler is used to derive a symmetric
> encryption key using the following information:
> 
>1.) Epoch time of identity.
>2.) Offset of authentication time from identity epoch time.
>3.) SHA256 hash of the RSA encrypted identity.
>4.) User password key.
> 
> The key scheduler uses the authentication epoch time differential to
> perturb the generation of two separate vectors.  These vectors are
> combined and then fed into an N-round iteration of feedback hashing to
> generate the final encryption key.
> 
> Vector 1 is generated as follows:
> 
>||= Concantenation.
>Ukey  = User's authentication key (des3-hmac-sha1 in reference imp).
>Etime = 32-bit identity epoch time.
>Eoffs = Authentication/epoch time offset (network byte order).
>Ihash = SHA256 hash of RSA encrypted identity.
>Nrnd  = Iteration round count.
> 
>V1 = Hmac256(K, Etime)
> | K = (Ukey || Eoffs)
> 
>The Etime is decomposed into a UNIX time structure with a
>gmtime call.  The day of the month represented by the Etime is
>used as an offset into the V1 vector to obtain an 8-bit round
>count value (Nrnd).
> 
> Vector 2 is generated as follows:
> 
>V2 = Hmac256(K, Ukey)
> | K = (Ihash || Eoffs)
> 
>The first 16 bytes of the V2 vector are retained to serve as
>the IV (Initialization Vector) for AES-256-CBC symmetric
>encryption of the OTI payload.
> 
> Iteration rounds:
> 
> A seed vector for the iteration rounds is formed as follows:
> 
> Seed = (V1 || V2)
> 
> The Seed vector (512 bits) is reduced to a 256 bit vector by
> the first SHA256 hashing round.  The 256 bit output vectors
> are then iteratively fed back for Nrnd-1 iterations.
> 
> 
> The output of the final round is used as an AES-256-CBC encryption key
> with the IV abstracted from the V2 vector.
> 
> Upon receipt of the AS_REQ payload the KDC re-creates the key and IV
> by running the same key scheduler using the authentication start time
> from the AS_REQ.  In the prototype implementation the identity epoch
> time and the SHA256 hash of the RSA encrypted identity token are
> stor

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

2007-01-31 Thread Sam Hartman 
So, the USB flash stores the 160-bit RSA encrypted user identity?




I think that this approach or something like it could be useful.  I'm
not sure I'm happy with your key schedule, or some of the crypto
details.  I'd prefer to think about whether RFC 3961 might provide
better options.  Similarly, I'm not sure what you get out of RSA
encryption.

An alternative proposal that seems like it would do the same thing
from a security standpoint would be a way to combine a password key
with pkinit.  You could store a soft certificate on a USB token.

Ultimately, though, I think that the important thing is the user
experience.  I agree with you that providing stronger authentication
when someone provides a USB flash disk with some secret information is
desirable.  I think the specific details of how to do this should be
worked out in the Kerberos working group of the IETF.  I encourage you
to take your proposal there.

--Sam


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