Subject: RE: IBM alternative to PKI?

From: [email-masked]
Date: Wed, 15 May 2002 13:50:14 -0600

there have been a number of things done for relying party operations. for
various of the relying-party-only certification authority pilots done in
europe and other countries .... it was possible to show that the public key
could be registered ... and it wasn't even necessary to send the
certificate back to the key owner .... just put it in the relying partie's
account record (i.e. they were sending the certificate back to the key
owner ... because there was some COTS software that could be used ... but
other than that it served no useful business function).

is this in anyway related to the previous work on relying-party-only pilots
that have been done in europe?

                                      "Liaquat khan"                                               
                    <Liaquat.Khan@TheGlobalTrustAuth     To:      <[email-masked]>              
                                          ority.org>     cc:                                       
                                            Sent by:     Subject:      RE: IBM alternative to PKI? 
                        [email-masked]                                               

                                 05/15/2002 01:10 PM                                               
                      Please respond to Liaquat.Khan                                               

This model came out of the work down by IBM and others as a part of the TIE
(Trust Infrastructure for Europe) project.  It is based on public key
cryptography, but looking at things from a slight different angle, i.e.
from
the viewpoint of the RP. I need to be careful on how much I can say.
Although there maybe publicly available information out there somewhere.

Regards,
Liaquat Khan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dean Adams
Sent: Tuesday, May 14, 2002 8:32 AM
To: Peter Gutmann; [email-masked]; [email-masked]
Subject: RE: IBM alternative to PKI?

Thanks Peter,
           It was this sort of question that I really intended. Apologies
for being so
vague.

Your theories may be correct on how this has been invented and put forward
to the UK government.  My understanding is that a UK IBM'er (Peter Dare)
may
have proposed this new PKI alternative.
Any IBM'ers out there who can comment - provide further detail on this
model?

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: 14 May 2002 08:41
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: IBM alternative to PKI?
>
>
> "Anders Rundgren" <[email-masked]> writes:
>
> >I do not know anything of e-Envoy but I do know a few things
> concerning PKI
> >and smart cards.  There are indeed commercial problems
> associated with smart
> >cards.  But does it get better by introducing yet another type
> of card and
> >credentials?
>
> Does anyone know exactly what this new solution is?  With the
> size of IBM, the
> news story could quite easily translate into "Some random corner
> of IBM, under
> the impression that another far-flung corner of said company had
> something cool
> to offer, have tried to sell said something to the UK government,
> and are now
> frantically trying to find out what it is they've sold them".
>
> (I've seen some research papers on an XML-based PKI-avoiding
> system which might
> fit the bill, but who knows what the story is really talking about).
>
> Peter.
>
>
____________________________________________________________
Dean Adams               mobile:         +44 (0)7989 385914
Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
49 Whitehall             Office Tel:     +44 (0)20 7451 1490
London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
email: [email-masked]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution
or
any action taken or omitted to be taken in reliance on it, is prohibited
and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

---

From: [email-masked]
Date: Thu, 16 May 2002 08:48:51 -0600

my impression is that server-side signings are typically the desire for
putting in a "real" PKI infrastructure .... but single, large roll-out of
all the technology is an issue ... so the backends implement real PKI, and
there is a middle-man which interacts with the clients in a more
traditional (password) paradigm and the middle-man  acts as a proxy doing
the PKI stuff on behalf of the client. At any point, individual clients
might be able to deploy their own PKI operation and eliminate using the
proxy (theory is that it facilitates the transition from password-based
paradigm to PKI-based paradigm by not requiring all backends and all
clients to make the paradigm transition in a single, syncronous event).

Many of the EU and other relying-party-only PKI deployments were addressing
a different issue. They came to realize that the traditional PKI identity
certificates didn't address any of their business needs ... the client was
doing digital signature operations and appending things that bore a little
resemblence to identity certificates ... enuf so that traditional PKI
sottware might work. However, other than the facilitating of traditional
PKI software ... the certificates weren't not serving any actual business
function.

The first case of server-side PKI isn't so much a PKI alternative issue ...
it is a traditional PKI roll-out/transition facilitor.  I believe the
second case of experience from relying-party-only certificates ... could be
considered more of a PKI alternative issue (i.e. discovery that
certificates weren't serving any valid business  function).

[email-masked] on 5/16/2002 6:53 am wrote:

Liaquat

from
>the viewpoint of the RP. I need to be careful on how much I can say.

You just triggered my curiosity!

Is it fundamentally different to 3D Secure and SAML?  I.e. schemes
where the client authenticates to a server-based PKI-thing that does
the actual work (signs resp. creates auth*).

Anders

---

From: [email-masked]
Date: Thu, 16 May 2002 14:17:09 -0600

but purely monitor/audit isn't usually a transition scenario also.

if you are looking at the financial "middle-man" given in the example by
anders ... the financial end-point already contains extensive audit and
dynamic risk management (i think there was an article in NYTimes this week
or last week about the neural net stuff that looks for complex fraud
patterns). Given end-to-end integrity and no intermediate stand-in .... I
would contend that the end-point risk management can do a much better job
of deciding whether or not to approve a transaction ... based on more
comprehensive understanding of the situation ... that wouldn't be available
to middleman processing.

the issue is if you have a no-security infrastructure ... then adding a
monitor for auditing purposes can be a risk management benefit. we defined
a bunch of that stuff back in the '80s for something we were calling
"middle-layer" ... sort of the precursor to 3-layer architecture.

Note however, this doesn't have to be a middle-man in the transaction
processing sense ... in the current internet ... a packet can flow thru a
large number of nodes ... all of which can be doing monitoring and auditing
(do a traceroute sometime) ... but wouldn't be considered a transaction
processing middle-man ... in the sense that it takes in a transation ...
processes the semantics of that transaction and then generates a different
transaction.

The scenario example is that a client does a password transaction with a
middle-man ... the middle-man processes the password transaction and then
generates a totally different digitally signed transaction ... possibly
even emulating that the transaction originated directly from the client.

A purely intermediate monitor/audit environment with no "middle-man"
processing and end-to-end security would have the client directly
generating the digitally signed transaction and sending it all the way thru
to the processing end-point.  It isn't the monitoring/audit that descreases
security, it is any middle-man processing interferring with end-to-end
integrity.

Another scenario was "SET". SET had relying-party-only certificates with
digitally signed transaction. A "SET" gateway .... accepted incoming SET
financial transactions, verified the certificate, verified the signature,
stripped everything out ... and generated a standard ISO 8583 transactions
.... with an additional flag indicating whether or not the "SET" gateway
believe the certificate and signature to be correct. Then a consumer's
financial institution was dependent on the "flag" in deciding whether or
not it was a valid transaction (aka there wasn't any end-to-end integrity).
Furthmore, I don't know if any of the "SET" gateways that had any financial
liability associated with fraudulent transaction (i.e. what happens if they
were to lie). At one point one of the associations gave a talk at an ISO
meeting giving the number of 8583 transactions that had the "SET" valid
signature flag set .... and they could proove that there was no
cryptographic capability involved at all (i.e. it wasn't even a SET gateway
that might not be telling the truth ... but there were financial reasons
why others might want the flag set also).

now, I would claim that an end-point business operation might
compartmentilize some of its functions ... so that any compromize in any
single component doesn't compromise all components. i would contend that a
compartmentilzed end-point security solution is different than several
different business operations all implementing various kinds of
intermediate processing (middle-man) preventing any kind of end-to-end
integrity.

random old middleware/middle layer refs:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week
of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33
Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come
from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come
from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha
(no surprise)exit
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just
missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light
(spotlight, that is)
http://www.garlic.com/~lynn/2002e.html#2 IBM's "old" boss speaks (was
"new")

[email-masked] on 5/16/2002 1:33 pm wrote:

Hi Lynn (and greetings to PKIX, 1st-time poster here),

A counter-argument: while adding a middleman adds a vulnerability, it also
adds auditing: the middleman can monitor all password attempts, so as to:
 - lockout guessers
 - detect anomalous patterns of use which may indicate a compromised
password is being exploited
 - allow users to review audit trails to detect compromises themselves
 - allow users to review audit trails to determine the extent of a
compromise

Without this auditing, it may be much more difficult to detect a compromise
of a private key, and to determine precisely what has been compromised.

So there are security benefits as well as disadvantages to middlemen, I
suppose a comparison depends on the exact situation and how you weight the
factors..

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 10:00 AM
To: Anders Rundgren
Cc: Dean Adams; [email-masked];
[email-masked]
Subject: Re: IBM alternative to PKI?

i.e. middle-man tends to represent transition/roll-out solutions .... not
security infrastructure solutions.

from traditional security

* end-to-end

middle-man approaches tend to always negate any end-to-end attribute

* additional steps represent additional vulnerabilities

middle-man approaches increase the number of steps/processes .... each of
which represent an additional vulnerability, each additional vulnerability
represents additional points of failure/fraud

* only as strong as the weakest link

shared-secret password paradigm in series with digital signature isn't
additive.

* 2-factor authentication

secret password (as opposed to shared-secret password) in conjunction with
hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password has
to be compromised). a shared-secret password process in series with a
digital signature process can fail with just the shared-secret password.

---

From: [email-masked]
Date: Thu, 16 May 2002 15:15:21 -0600

so lets do the counter argument in the business process sense ... a
middle-man that is a different company than the end-points (as opposed to
possibly middle-man implementation which is actually a business entity's
compartmentalized operation ... which has various security/vulnerability
trade-offs).

so in the business middle-man scenario ... the middle-man is your strongest
competitor/advisary. they process incoming transactions and then generate
something from scratch that is forwarded to you. you have no way of
prooving that the incoming transactions are fraudulent or not. furthermore
the business middle-man has no financial penalty/liability with regard to
fraudulent transactions.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 16 May 2002 14:25:50 -0700

Good point: auditing can be provided without needing middlemen who rewrite
the client's transactions, and these should be avoided when possible for
end-to-end integrity.

When these middlemen can't be avoided, though, (i.e. the client only has a
password, so needs a middleman to speak for him), then these middlemen seem
a good point for auditing.  Particularly in cases where these middlemen are
the only online server involved in everything the client does.

For example, the clients might not only use middlemen to sign transactions
which their bank could audit, but sign documents, authenticate themselves to
different services, etc..  All of these could potentially be mediated
through a middleman who authenticates clients with a password and then signs
things on their behalf, and since this middleman is helping the client talk
to a variety of other people, no-one but the middleman appears able to audit
the full spectrum of the client's activity..

But that may be getting a little out of scope..  

Thanks,
Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 1:17 PM
To: Trevor Perrin
Cc: Anders Rundgren; Dean Adams; [email-masked];

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 16, 2002 10:00 AM
To: Anders Rundgren
Cc: Dean Adams; [email-masked];

* end-to-end

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 16 May 2002 14:42:09 -0700

Yeah, that wouldn't be good.  If a middleman is going to "speak for" you
then it is definitely inside your security perimeter, and shouldn't be in
the hands of an adversary.  I'm imagining middlemen that are owned by an
organization so that its members, who only have passwords or authentication
devices, can perform private-key functions like signing or decrypting, for a
sort of PKI-on-the-cheap solution.  In the case where users have their own
private keys, and the other PKI issues are dealt with, I agree that
end-to-end security is preferrable.

Trevor