Re: Adding Kerberos use-case

Hi.
Is there any vulnerabilities by re-produce Ticket?
because normally we can expect the time of client side is not match to
servers.

regards
mountie.

On Tue, Nov 6, 2012 at 7:45 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On Nov 5, 2012 4:58 PM, "Thomas Hardjono" <hardjono@mit.edu> wrote:
> >
> >
> > Thanks Ryan,
>
> >
> > > -----Original Message-----
> > > From: Ryan Sleevi [mailto:sleevi@google.com]
> > > Sent: Monday, November 05, 2012 2:45 PM
> > > To: Thomas Hardjono
> > > Cc: public-webcrypto@w3.org; ddahl@mozilla.com; Arun Ranganathan
> > > Subject: Re: Adding Kerberos use-case
> > >
> > > On Mon, Nov 5, 2012 at 11:32 AM, Thomas Hardjono <hardjono@mit.edu>
> > > wrote:
> > > >
> > > > David, Ryan, Folks,
> > > >
> > > > I was wondering if it is possible to add a use-case to the Web
> > > > Cryptography API draft.
> > > >
> > > > We want to be able to implement the full Kerberos Client in
> > > JavaScript
> > > > and make use of the crypto APIs. In particular, we would love to
> > have
> > > > an additional API to handle Kerberos tickets (eg. fetching/storing
> > > > tickets from the underlying OS).
> > >
> > > We definitely want to capture the use case as a possible user of the
> > > API.
> > > I leave it to Arun (CC'd) to figure out whether the Use Case doc
> > being
> > > prepared is meant to describe what things should be possible with
> > this
> > > API in V1, or what things are meant to be possible (in some yet
> > > undetermined future version with all features).
> >
> > Thanks -- I can provide a paragraph of the use-case if that will help.
>
> > >
> > > Individually, I think an API for handling Kerberos Tickets would be
> > an
> > > entirely different API and document, with its own set of use cases
> > and
> > > supporting work. I think showing how it incorporates with the API
> > > proposed is good, and it probably would belong in this group - after
> > a
> > > re-chartering effort (at least, as I understand our current
> > charter).
> >
> > Sure, this would be one possible avenue.
> > Do you think this "Kerberos API" work should be done
> > in the W3C or elsewhere? (eg. IETF)
>
> If for JS/WebApps, then W3C is the place to be, and I would suggest that
> of WebApps, WebAppSec, and WebCrypto, ours is *probably* where it belongs
> (with some degree of rechartering).
>
> If *totally* high-level API, it *might* sit in WebApps.
>
> >
> >
> > >
> > > I would prefer not to spend too much energy discussing how that
> > should
> > > work until we've got the basic API (the editor/wg draft currently
> > > called for in the charter), and then work on iterating and expanding
> > > that in future versions and future documents.
> >
> > Agree, I understand that it is imperative to get the
> > basic API agreed upon and  implemented by browser
> > vendors (ie. would be a tremendous progress).
> >
> > I would definitely be interested expanding the API once
> > the basic API is done.  I know the current WG charter
> > excludes "crypto providers",  but some form of extensibility or
> > "layering" of a richer set of APIs would be useful
> > (e.g. something akin to a JOSE or CMS level of APIs).
> >
>
> We have been calling those high-level APIs, for which there is known and
> acknowledged interest in.
>
> The overlap between the two arguably exists in the Key object.
>
> >
> > >
> > > >
> > > > Maybe something that looks like the KeyStorage interface would be
> > > > workable.
> > >
> > > I've proposed removing the KeyStorage API.
> >
> > Is the KeyStorage API work to be deferred for later,
> > or is it completely abandoned?  I'm kind of thinking
> > that there is a huge install base of PIV (PIV-I) smartcards
> > that could benefit from a KeyStorage API (or similar).
> > Then there is also several hundred million PCs out there with TPM
> > chips, which (at its dumbest config) becomes a useful place to
> > store keys. TPM-signed key pairs may also be useful
> > for browsers and servers (SPs).
> >
> > I can contribute a TPM use-case if you need one :-)
> >
>
> I can provide a few myself, and did at our Face to Face. Its not at all
> abandoned, but I think whether you are talking kerberos tickets or certs or
> some other container, I think we need a key /discovery/ API. Of which I
> made then withdrew a proposal for, and think we would want to revisit
>
> We need to address key storage as a primary feature, but I am (currently)
> arguing in the group that we do not and *should* not address
> pre-provisioned or preexisting (not created by and stored by the site) keys
> *yet*.
>
> >
> > Thanks.
> >
> > /thomas/
> >
> >
> >
> >
> >
> >
>



-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World