[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek]
Forwarding to the EKMI list to ensure everyone on the list sees
Matt's message. Sorry if the HTML formatting gets mangled in
the process.
Arshad
-------- Original Message --------
Subject: Re: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek
Date: Wed, 2 Jul 2008 16:11:08 -0600
From: Matt Ball <matt.ball@ieee.org>
To: Arshad Noor <arshad.noor@strongauth.com>, P1619-3
<P1619-3@listserv.ieee.org>
CC: Bruce, Timothy R <Timothy.Bruce@ca.com>, ekmi
<ekmi@lists.oasis-open.org>, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net>, Hallam-Baker, Phillip <pbaker@verisign.com>
References:
<041F951ADD49CD4B81C29371621E66100447B5D1@atlex01.numethods.com>
<B870629719727B4BA82A6C06A31C291203148ED8AA@hqmailsvr01.voltage.com>
<486ADAE1.3010005@strongauth.com>
<4090CC433D85994DA9A5A0FAD9A9EF5B05343B41@USILMS12.ca.com>
<486BC3B1.2090908@strongauth.com>
This has truly become a large thread, across both the P1619.3 and EKMI
e-mail reflectors!
The fundamental issue is that we don't currently know how to
differentiate P1619.3 and EKMI (and to a limited extent IETF's KEYPROV).
Answering this question is why I started the Key Management Summit
<http://www.keymanagementsummit.com/2008/>. By Sept 26th, I think we'll
have the answer... :)
We currently have the necessary information at our disposal to answer
this question. P1619.3, EKMI, and KEYPROV have publicly viewable drafts:
* IEEE P1619.3/D3:
https://siswg.net/index.php?option=com_docman&task=doc_download&gid=96&Itemid=41
<https://siswg.net/index.php?option=com_docman&task=doc_download&gid=96&Itemid=41>
* OASIS SKSML D6:
http://www.oasis-open.org/committees/download.php/28653/SKSML-DRAFT-6.0.zip
* IETF KEYPROV:http://www.ietf.org/html.charters/keyprov-charter.html
o Dynamic Symmetric Key Provisioning Protocol (DSKPP)
<http://www.ietf.org/internet-drafts/draft-ietf-keyprov-dskpp-04.txt>
o Portable Symmetric Key Container
<http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-04.txt>
o Symmetric Key Package Content Type
<http://www.ietf.org/internet-drafts/draft-ietf-keyprov-symmetrickeyformat-02.txt>
I've heard rumors that ANS X9 is also starting a key management effort,
though I haven't seen any public information on this.
The P1619.3 Task Group has the following goals and priorities (see
P1619.3 homepage
<https://siswg.net/index.php?option=com_content&task=view&id=35&Itemid=76>):
1. Create a standard that allows secure interchange of encryption
keys between devices that encrypt stored data and devices that
manage keys
2. Understand existing standards and use where possible to expedite
the creation of this standard
3. Raise public awareness of P1619.3 and encourage adoption
4. Facilitate interchange by providing open source reference
implementations
My question is this: Can P1619.3 use standards from EKMI and/or KEYPROV
to meet these goals?
If the answer is yes, then an approach is to normatively include the
appropriate EKMI or KEYPROV standards into P1619.3, as needed, to
achieve our goals.
If the answer is no, then we continue on our current path. In this
case, we have shown that these standards serve different segments of the
security industry and that we do not need to be concerned with overlap.
In either case, the analysis is very important. We need to have this
question answered by Sept 22nd, if for no other reason than to avoid
looking like fools on the panel discussion of these standards.
We should get together a small group of members who participate on 2 or
3 of these standards groups and critically analyze the overlap. If you
are interested in this effort, please let me know!
Cheers,
-Matt
On Wed, Jul 2, 2008 at 12:06 PM, Arshad Noor <arshad.noor@strongauth.com
<mailto:arshad.noor@strongauth.com>> wrote:
Tim,
The P1619.3 mission and documents can be found at:
https://siswg.net/index.php?option=com_content&task=view&id=35&Itemid=76
<https://siswg.net/index.php?option=com_content&task=view&id=35&Itemid=76>
No, I was not implying that the 1619.3 protocol was limited, but that
the focus of the storage vendors (who make up the majority of the
WG) is
primarily on encrypting data on the storage device directly, rather
than
the data used within applications.
You are right. A key-management protocol - be it SKSML or the IEEE
protocol - can technically be used at any layer of the stack I showed.
The choices then are based on factors such as ease-of-use, support for
a particular platform, security, cost, etc.
My understanding of the 1619.3 focus is they want to create a compact,
binary protocol that can be used by firmware on the embedded
controllers
of the storage devices. While it is technically possible for XML to be
used by such firmware, I was given the impression from some discussions
that it was infeasible to assume that such firmware can use XML, SOAP,
XML Signature and XML Encryption - all of which are required for
transport security in SKSML - in the near term.
While there is nothing to prevent an OASIS TC from working on a binary
protocol, OASIS TC's tend to focus primarily on XML-based protocols. I
may be generalizing here, but I guess people come to OASIS or the
W3C to
work on XML-based protocols, while they gravitate towards the IETF/IEEE
to work on binary ones.
However, given that IT infrastructure is made up of application
software
running on large servers and small/micro-devices with embedded
firmware,
there is a clearly a need for both types of protocols. And it is that
belief that led me to participate in the IEEE WG too, because I see the
need for co-existence. It is also my impression that software that
controlled storage devices (Management Consoles, Backup SW, etc.) would
be the bridge between the two protocols, since they can talk XML with
SOAP, XMLSig, XMLEnc to an SKMS and 1619.3 to the embedded firmware on
storage devices, thus using the best of both standards for an
end-to-end
solution within an IT infrastructure.
Recently, it appears that the WG is also working on an XML-based
protocol for KM. It is this part that I find confusing, since I was
under the impression that SKSML could address the needs of the storage
vendors. This is where the potential for confusion exists. I haven't
heard from the IEEE WG why it doesn't address the needs of the storage
vendors. (Note: I have copied Matt Ball, Chair of the 1619 WG on the
e-mail; if he responds to this with his views, I will forward it to the
TC.)
In the end, I agree with you, we must channelize our energies towards
finding a way to work together because customers will demand that
sooner
or later. If we can make rational decisions early and address the
issue
before it grows, all the better. To that end, the Key Management
Summit
in Baltimore in September will be a good place to have that discussion
since many OASIS and IEEE members will be in attendance.
In the meantime, since you do have an interest for both sides of the
fence - application software and embedded controllers of storage
devices - your perspective after reading the 1619.3 documents will
definitely help us Tim.
Arshad Noor
StrongAuth, Inc.
Bruce, Timothy R wrote:
Arshad,
I have not seen the IEEE 1619.3 specification and so I cannot
comment on
how it would compare to EKMI. You seem to imply that it is
limited and
not a standard that could be elevated above the storage device
architecture to a more generic architecture (does the EKMI have
access
to the 1619.3 specification or other documentation on the
mission and
direction of this WG?).
It would seem to me that ultimately one standard could be
applied and
service the enterprise at whatever level any particular software or
hardware vendor chooses, be that at the application level or
down at the
device level. In terms of creating an industry standard for
symmetric
key management I feel we should not be bias towards any one
vision of
where the cryptographic engine would architecturally reside, and is
there a reason would we assume that the EKMI protocol could not be
implemented at the hardware level or the 1619.3 protocol at the
application level?
Ultimately, it is my opinion that the industry will standardize
on a
single protocol, and the candidates would seem to be either the
EKMI or
the 1619.3 (or some extension to one or the other). Again,
having not
seen anything specific on the 1619.3 specification it was my
hope that
EKMI would ultimately envelope both the PKI and 1619.3 protocols
into a
single architectural standard for truly end-to-end enterprise key
management.
Also I believe you are missing one of the key market factors
that has
been driving the industry towards providing cryptographic
solutions, and
that is the news press's recent focus on identity theft and on how
businesses and governments are apt to loose very private and
confidential information. Certainly these losses can occur in a
variety
of ways, but the most publicized losses have been either in lost or
stolen backup tapes, lost or stolen lap tops or hackers accessing
e-commerce information through web sites or other public access
points.
All of these issues can be addressed by encrypting at either the
application or the hardware level, but it would seem to me that the
issue of hacker attacks is very problematic because at some
point in any
e-commerce application the data has to be in the clear and if it
is in
the clear in real time then there will always be a possible
exposure
that cryptography can not address by itself.
The other issues of lost tapes and other storage devices such
as lap
tops can be very securely addressed with cryptography,
especially in the
area of lost tapes but also with the loss of other storage
devices that
use tamper sensitive technologies to zero key information if
necessary.
Here again, cryptography could be done at any level from the
application
to the device but as you and I discussed most storage devices today
store data in compressed format to save space and cipher text
does not
compress very well. This is an argument for encrypting at the
device
level rather than the application level. Then there are also
the issue
of the impact cryptography has on a server's valuable processor
cycles.
The bottom line is I would not count on winning a standards war
based
upon the argument that encryption at the storage device level is a
flawed and short lived vision. Rather than fighting to win that
battle,
I would rather us be fighting to marry our visions and our
efforts over
the next few years to merge EKMI, PKI and 1619.3 if at all
possible.
The DNS-like aspects of the EKMI vision are very attractive and
could
enhance 1619.3, and there may be aspects of 1619.3 that could
benefit
the EKMI.
Tim Bruce Principal Software Architect, Development 5465 Legacy
Drive Plano, Tx. 75024 tel: 214-473-1917 fax: 214-473-1069
-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com
<mailto:arshad.noor@strongauth.com>] Sent: Tuesday, July 01,
2008 8:33 PM
To: Luther Martin
Cc: P1619-3@LISTSERV.IEEE.ORG
<mailto:P1619-3@LISTSERV.IEEE.ORG>; ekmi; Ramon Krikken; Trent
Henry; Eric
Maiwald; jon.oltsik@enterprisestrategygroup.com
<mailto:jon.oltsik@enterprisestrategygroup.com>
Subject: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek
[Note: The protocol used within a Symmetric Key Management System
(SKMS) - one of two major components of an EKMI (the other being a
PKI) - is the Symmetric Key Services Markup Language (SKSML).]
To date, there is only one implementation of the DRAFT 1 version of
the SKSML protocol (an open-source implementation called StrongKey,
produced by our company and available at www.strongkey.org
<http://www.strongkey.org>).
The protocol, after much discussion within the OASIS TC over the
last 18 months, is at DRAFT 6 and is scheduled to be released
to the
general internet for review and comments within the next 10-14 days
(it is under ballot within the committee as we speak).
While confidentiality agreements with our customers preclude us
from
mentioning where it is being used, I will point you to some
publicly
available statistics on the number of downloads of StrongKey at
SourceForge.net:
http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&w
<http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&w>
ords=strongkey
If we assume that a mere 2-3% of the downloads are in use, that
makes
30-45 EKMI's using the DRAFT 1 protocol. Not much, I agree,
when you
compare it to the millions of downloads of software like the JDK,
Apache, JBoss, etc.; but we're talking about a paradigm-shift in
cryptographic key management here - a highly specialized niche - so
it will take time to register.
I will also point you to the OASIS EKMI TC home-page, where you can
see the publicly-visible supporters of the protocol, which
includes:
- CA
- FundServ (a Canadian company)
- MISMO (the Mortgage Industry Association in the US)
- PrimeKey (a Swedish company)
- Red Hat
- the US Department of Defense
- Wave Systems and
- Wells Fargo.
What is not visible - unless you are an OASIS member - is that two
of the three largest software companies in the world, two of the
three
largest security software companies in the world, and two very
large
consulting firms, are all Observers on the Technical Committee.
While the number of EKMI TC members certainly is smaller than the
1619.3 WG, there is a broader acceptance across business
sectors for
the vision of EKMI.
Given this, I would like to make a suggestion to the storage
vendors
in the P1619.3 WG. (Please don't shoot the messenger because
of the
unpopularity of this message I'm about to give) :-).
It is my personal belief that the market for storage-device based
encryption will dry up within 3-5 years. Why? Because of the
following:
An application stack on a running server resembles something
like the
following diagram (I've simplified it for brevity - real
applications
typically have more layers in the stack):
+-----------------------+
| Application Layer | <-- Focus of OASIS EKMI TC efforts
+-----------------------+
| Network Layer |
+-----------------------+
| Web-server Layer |
+-----------------------+
| Application Server |
+-----------------------+
| Database Layer |
+-----------------------+
| Operating System |
+-----------------------+
| Storage Device | <-- Focus of IEEE P1619.3 WG efforts
+-----------------------+
While transparently encrypting/decrypting data as it goes in
and out
of the storage device makes it easy for enterprises in the
short-term,
it does not protect them from attacks on plaintext in any of the
layers
above the storage device. The only threat that encrypted storage
devices protect against is, theft.
For an always-on, operational system in a data-center, this is an
insufficient counter-measure against data-breaches, since an
attacker
may be reading plaintext at ANY of the layers above the storage
device
and land the company on the front-pages of the Wall Street
Journal and
CNN in spite of the encrypted storage device.
This is not to say that the OASIS effort eliminates the problem
- it
does not. However, it minimizes the attack-surface to the minimum
possible target, and allows the enterprise to not have to duplicate
protecting data in any of the layers below the application layer.
Given that many application developers already have to protect
their
applications from X-site scripting, SQL Injection, and a host
of new
application-specific vulnerabilities, adding encryption to the list
of things to do is going to become a formality.
The OASIS effort is also planning on educating IT Auditors through
ISACA about potential vulnerabilities in the stack (as shown
above),
so ignorance on the part of developers/managers will not be an
excuse
for too long if they want to comply with SOX, GLBA, PCI-DSS, HIPAA,
FISMA, PIPEDA, EU Directive, etc.
It is my belief that once ISVs and customers recognize this
problem,
they will start modifying their applications to encrypt data at the
application layer. Once we're past the tipping-point on that,
there
will be little need for duplicating encryption on storage-devices.
Notwithstanding this, I believe there is a place for the P1619.3
protocol in the short-medium term - it is to take the keys and
polices
supplied by an EKMI and push it down to the storage devices for
storage-based encryption in the intervening years before
applications
encrypt data directly. Towards that end, what is needed is a
compact
binary protocol that can be used between the Management Console
of the
Storage environment and the storage device itself, while the MC
itself
becomes an EKMI client and uses the SKSML protocol to get the keys
and policies.
It is my belief that the WS-MAN based XML protocol being worked
on by
the P1619.3 WG will create confusion in the marketplace. While
this
will serve the key-management vendors in the WG (who are not
members
of the OASIS effort), it neither serves the industry nor the
storage
vendors.
Since the market for encrypted storage-devices is not a
long-lived one,
how much effort do storage vendors want to put into building
XML-based
protocols, libraries, tools and MC applications, when another
effort has
reasonable acceptance and traction, and can be easily used to
meet the
goals of the storage industry? If storage-industry budgets
allow for
duplicating the OASIS work and dealing with the mixed-marketing
messages
that customers receive, that's a different issue. However, if
you want
to optimize your investments while making the most of the
opportunity
that presents itself over the next 3-5 years, then it makes
sense to do
the minimum necessary work on the binary protocol and use the OASIS
XML-based protocol where it makes sense.
Arshad Noor
StrongAuth,Inc.
Luther Martin wrote:
How many vendors have implemented EKMI? Are there any users
of it?
Knowing how it has succeeded or failed might provide some
particularly
useful insights for P1619.3.
________________________________
From: Gary Palgon [gpalgon@NUBRIDGES.COM
<mailto:gpalgon@NUBRIDGES.COM>]
Sent: Tuesday, July 01, 2008 7:22 AM
To: P1619-3@LISTSERV.IEEE.ORG
<mailto:P1619-3@LISTSERV.IEEE.ORG>
Subject: [P1619-3] OASIS EKMI Article in InformationWeek
Oasis' open Enterprise Key Management Infrastructure initiative
promises less-complex encryption. But will vendors get on board?
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=2
08800937
Gary Palgon
VP Product Management
gpalgon@nubridges.com
<mailto:gpalgon@nubridges.com><UrlBlockedError.aspx>
nuBridges, Inc. | 1000 Abernathy Road | Suite 250 |
Atlanta GA
USA 30328
Tel: +1 770 730 3592 | Fax: +1 770 730 3784
www.nubridges.com
<http://www.nubridges.com><http://www.nubridges.com>
The Secure eBusiness Authority
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. You may a link to this group and all your
TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]