|
Response #2
|
Subject: Re:
[oasis-charter-discuss] EKMI
Phillip,
I have reviewed these Internet-Drafts (I-D) that have been
published so far:
http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-key-container-02.txt
http://www.ietf.org/internet-drafts/draft-pei-dynamic-symkey-prov-protocol-01.txt
and believe the goals of the KEYPROV IETF WG and the EKMI-TC are
quite different.
KEYPROV is targeting a protocol for provisioning credentials that,
amongst other meta-data, consist of "shared secrets". These
*credential-secrets* (referred to as symmetric keys in the I-D's)
are used for primarily authenticating resources against validating
systems.
The EKMI-TC is targeting a protocol - Symmetric Key Services
Markup Language (SKSML) - for the life-cycle management (provisioning,
escrow, recovery, caching, destruction, etc.) of *symmetric encryption
keys* (such as 3DES, AES, etc.). These keys are used for encryption
of business data and not for authentication.
The confusion between the WG and TC charters arises because of
the industry's (sometimes misguided) notion for referring to the
"shared secrets" of authentication credentials as "symmetric
keys" - which is similar to the term used by cryptographers when
referring to encryption/decryption keys used with symmetric
ciphers.
In addition, the use of such algorithms (3DES, AES) and symmetric-
encryption keys by the KEYPROV protocols to protect the "shared
credential secret" during provisioning, adds to the confusion.
Some might be misled into thinking that 3DES/AES keys are being
provisioned by the Provisioning System for general use by business
applications, as opposed to the use of those symmetric encryption
keys by the Provisioning System and the Credential Container for
securely transporting the credential-secret between the two.
(Think of SKSML as the protocol that *might* be used by the
implementers of a KEYPROV-based Provisioning System, to acquire
symmetric encryption keys from a centralized Symmetric Key Sevices
server, rather than generating one itself. The implementers might
do this if there is a need for long-lived symmetric-encryption key
management rather than just for the transient need during the
credential-provisioning process).
Given the goals and the details in the I-D's, what is misleading,
consequently, are the terms in use for the WG and the I-D's. More
appropriate terms might have been "CREDPROV", "Portable Credential
Container" and "Dynamic Credential Provisioning Protocol" for the
WG and the I-D's respectively.
If the WG is wedded to the name and terms in the I-D, I would
encourage a paragraph or two in the charter and the Drafts, that
articulates the difference between the "credential-secrets"
provisioned through the protocols in the I-D's, and symmetric
encryption keys such as DES, 3DES and AES used for encryption
of data like social-security numbers, credit-card numbers, etc.
If we are agreed on my understanding of the KEYPROV goals, it is
almost certain that the documentation produced by the EKMI-TC
will highlight this difference.
While XKMS is more closer to the focus of the SKSML, given that
XKMS was architected on the premise of provisioning asymmetric
keys, trying to extend XKMS to accommodate symmetric-encryption
keys would be akin to hammering a round peg into a square
hole - while it can be done, it may not look pretty and might
become cumbersome to implementers who wish to focus on only one
or the other form of key-management. There is nothing to
prevent an implementer from implementing both protocols in a
single application if two distinct libraries took care of the
mechanics; most applications do this today rather than try to
shoe-horn every need into a single protocol.
SAML, once again, is focused more on authentication rather than
on a life-cycle management protocol for symmetric-encryption keys;
as such, I see no overlap.
I trust this addresses the questions raised. If I have mis-
understood the I-D's, and it was indeed, the KEYPROV WG's intention
to provision and manage symmetric encryption keys, please point me
to the relevant sections of the I-D that focuses on that. I will
re-read those sections more carefully and respond again.
Thanks.
Arshad Noor
StrongAuth, Inc.
|
Responded to Phillip Hallam-Baker
|
|
#4
|
Subject:
Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference
After
reading the charter, and reading the related information the
charter pointed (StongAuth SKML description from here:
http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html
)
to I have the following general comments:
This thing looks
to me like it is addressing only a VERY SMALL subset of what is
needed. It looks to me like what is there right now covers ONLY
the case of requesting retrieval (i.e. "List"/"read"
operation) of a symmetric key. This one seems like the relatively
EASY one to solve. The others ( add/modify/delete/query ) will
require much more work and don't seemed to covered in the related
material or in the charter
It is good to see that
StrongAuth has shown examples of using "SOAP bindings"
but stopped short, as protocols like WS-Trust already handle
symmetric and asymmetric keys and provide for a better transport.
For Key management/administration though, I think there is quite
a bit more that needs to be defined that is not covered in the
related material or in the charter. There is no real in/out of
scope items for this TC which makes me think that the will be far
too much uncertainty.
There is other standards work in
this space and there is no clear relationship called out in the
charter.
Specific Charter comments marked <ajn>:
PROPOSED
CHARTER
FOR REVIEW AND COMMENT
OASIS ENTERPRISE KEY
MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE
Name
OASIS
Enterprise Key Management Infrastructure (EKMI) TC
Statement
of Purpose
Public Key Infrastructure (PKI) technology has
been around for more
than a decade, and many companies have
adopted it to solve specific
problems in the area of
public-key cryptography. Public-key
cryptography has
been embedded in some of the most popular tools --
web clients
and servers, VPN clients and servers, mail user agents,
office
productivity tools and many industry-specific applications --
and
underlies many mission-critical environments today.
Additionally,
there are many commercial and open-source
implementations of
PKI software products available in the market
today.
However, many companies across the world have
recognized
that PKI by itself, is not a solution.
<ajn> Also, it seems
that the use of PKI for SSL/TLS communications link protection is
the most
common usage (to
protect various protocols - HTTP, LDAP - and to implement VPN
with
SSL-based VPN
solutions). </ajn>
There
is also the perception that most standards in PKI have
already
been established by ISO and the PKIX (IETF), and most
companies are
in operations-mode with their PKIs -- just
using it, and adopting it
to other business uses within their
organizations. Consequently,
there is not much left to
architect and design in the PKI community.
<ajn>
While companies are "using PKI", they are not, in wide
usage, deploying their own PKI - rather
they
are procuring certificates from that subset of CAs (PKIs) that
are held within browser
default
trusted signers lists. Other usages are "hidden"/"buried"
inside products. The current
situation,
IMO, with public/private keys is that companies don't know how
fragmented
their usage really
is. </ajn>
Simultaneously,
there is a new interest on the part of many
companies in the
management of symmetric keys used for encrypting
sensitive
data in their computing infrastructure. While symmetric
keys
have been traditionally managed by applications doing their
own
encryption and decryption, there is no architecture or
protocol that
provides for symmetric key management services
across applications,
operating systems, databases, etc. While
there are many industry
standards around protocols for the
life-cycle management of
asymmetric (or public/private) keys
-- PKCS10, PKCS7, CRMF, CMS,
<ajn> XKMS?
</ajn>etc.
<ajn>
(also, the protocols/formats listed here seem tied to CA/RA <->
Entity communication - not the
management
of keys/certs distributed across a variety of key storage media
within an organization.
This
latter problem still requires attention.) </ajn>
--
however, there is no standard that describes how applications
may
request similar life-cycle services for symmetric keys,
from a
server and how public-key cryptography may be used to
provide such
services.
<ajn>
similar problems exist for both symmetric and asymmetric key
management. </ajn>
Key
management needs to be addressed by enterprises in its
entirety
-- for both symmetric and asymmetric keys. While each
type
of technology will require specific protocols, controls
and
management disciplines, there is sufficient common ground
in the
discipline justifying the approach to look at
key-management as a
whole, rather than in parts. Therefore,
this TC will address the
following:
Scope
<ajn>
0) TC will publish a Note defining the "space" for
these protocols, as distinct from existing work
in
areas of CA/RA <-> Entity communications </ajn>
A)
The TC will define the request/response protocols for:
1.
Requesting a new or existing symmetric key <ajn>
(why just symmetric?) </ajn>
from a server;
2. Requesting policy information from a server
related to caching of
keys on the client;
3. Sending a
symmetric key <ajn>
(why just symmetric?) </ajn> to
a requestor, based on a request;
4. Sending policy
information to a requestor, based on a request;
5. Other
protocol pairs as deemed necessary.
<ajn>
What about sending keys TO the server?
Query
of keys (and/or information about such keys) in a
server?
Add/Generate/Modify/Delete/List/Query
of key(s) </ajn>
B)
To ensure cross-implementation interoperability, the TC
will
create a test suite (as described under 'Deliverables'
below) that
will allow different implementations of this
protocol to be
certified against the OASIS standard (when
ratified);
</ajn>
Is this a compliance suite ? </ajn>
C)
The TC will provide guidance on how a symmetric
(and asymmetric) key-management
(key
management as distinct from CA/RA <-> Entity
communications).
infrastructure
may be secured using asymmetric keys, using secure
and
generally accepted practices;
D) Where appropriate, and if
possible in conjunction with other
standards organizations
that focus on disciplines
outside the purview of OASIS, the TC
will provide input on how such
enterprise key-management
infrastructures may be managed, operated
and audited;
</ajn>
You have lost me here </ajn>
E)
The TC may conduct other activities that educate users about,
and
promote, securing sensitive data with appropriate cryptography,
and the use of proper key-management techniques and
disciplines to
ensure appropriate protection of the
infrastructure.
List of Deliverables
1. XSchema
Definitions (XSD) of the request and response protocols
(by
April 2007)
2. A Test Suite of conformance clauses and sample
transmitted keys
and content that allows for clients and
servers to be tested for
conformance to the defined protocol
(by September 2007)
3. Documentation that explains the
communication protocol (by
April 2007)
4. Documentation
that provides guidelines for how an EKMI may be
built,
operated, secured and audited (by June 2007)
5. Resources that
promote enterprise-level key-management: white
papers,
seminars, samples, and information for developer and public
use.
(beginning January 2007, continuing at least through
2008)
</ajn>
Based upon what I have seen in the related material this is a far
too aggressive
schedule
</ajn>
Anticipated
Audiences:
Any company or organization that has a need for
managing
cryptographic keys <ajn>
which are used </ajn> across
applications, databases, operating systems
and devices, yet
desires centralized policy-driven management of all
cryptographic
keys <ajn> (and multiple
copies of such keys) </ajn> in
the enterprise. Retail, health-care,
government, education,
finance - every industry has a need to
protect the
confidentiality of sensitive data. The TC's
deliverables will
provide an industry standard for protecting
sensitive
information across these, and other, industries.
Security
services vendors and integrators should be able to fulfill
their
use cases with the TC's key management methodologies.
Members
of the OASIS PKI TC should be very interested in this new
TC,
since the goals of this TC potentially may fulfill some of
the
goals in the charter of the PKI TC.
<ajn> Also coordinate with WS-SX TC. </ajn>
<ajn>
Coordination with other standards bodies' efforts - known work
underway or existing:
- TCG ESSG
subgroup of Storage WG
- IETF
Keyprov BOF
- W3C existing XKMS
work </ajn>
Language:
English
IPR
Policy:
Royalty Free on Limited Terms under the OASIS IPR
Policy
----
Additional Non-normative information
regarding the start-up of the TC:
a. Identification of
similar or applicable work:
The proposers are unaware of
any similar work being carried on in
this exact area.
<ajn> (See above - there is other work underway) </ajn>
However,
this TC
intends to leverage the
products of, and seek liaison with, a
number of other existing
projects that may interoperate with
or provide functionality to the
EKMI TC's planned outputs,
including:
OASIS Web Services Security TC
W3C
XMLSignature and XMLEncryption protocols and working group
OASIS
Digital Signature Services TC
OASIS Public Key Infrastructure
TC
OASIS XACML TC (and other methods for providing granular
access-control permissions that may be consumed or enforced
by
symmetic key management)
b. Anticipated
contributions:
StrongAuth, Inc. anticipates providing a
draft proposal for the EKMI
protocol, at the inception of the
TC. The current draft can be
viewed
at:
http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html
and
a working implementation of this protocol is available at:
http://sourceforge.net/projects/strongkey for
interested parties.
c. Proposed working title and acronym
for specification:
Symmetric Key Services Markup Language
(SKSML), subject to TC's
approval or change.
d. Date,
time, and location of the first meeting:
First meeting
will be by teleconference, with an optional face-to-
face
gathering as one conference call node, at:
Date: [December
____, 2006]
Time: [____ UTC]
Call in details'; to be
posted to TC list
F2F Location: San Francisco Bay Area.
StrongAuth has agreed to
host this meeting.
e.
Projected meeting schedule:
Subject to TC's approval, we
anticipate monthly telephone meetings
for the first year.
First version of the protocol to be voted on by
Summer 2007.
StrongAuth is willing to assist by arranging for
the
teleconferences; we anticipate using readily available
free
teleconference services.
f. Names, electronic
mail addresses, of supporters:
Ken Adler, individual
member, ken@adler.net
June Leung, FundSERV,
June.Leung@FundServ.com
John Messing, American Bar
Association, jmessing@law-on-line.com
Arshad Noor, individual
member, arshad.noor@strongauth.com
Davi Ottenheimer,
individual member, davi@poetry.org
Ann Terwilliger, Visa
International, aterwil@visa.com
g. TC Convener:
Arshad
Noor, arshad.noor@strongauth.com
END DRAFT
Anthony
Nadalin | Work 512.838.0085 | Cell 512.289.4122
|
Received comment from Anthony Nadalin
|
|
Response #4
|
Subject: Re: Fw:
[oasis-charter-discuss] EKMI Pre-Launch Teleconference
Thank you for your comments, Anthony. I apologize for the delay
in responding but I had been traveling last week and am just now
getting caught up. However, your comments were discussed in the
OASIS con-call and we are incorporating some of your suggestions
in the charter document.
For the record, I do want to respond to your comments on the forum,
so that you are aware of how we're addressing them.
It appears that I may not have explained the premise on which the
EKMI architecture and the SKSML protocol is based, and that would
explain the conclusion to which you have arrived. I will attempt
to correct that error.
The architecture and protocol are based on the premise that a
company:
1) wants to define encryption policy centrally;
2) wants to manage symmetric keys centrally and uniformly; and
3) wants to optimize the TCO of such an infrastructure;
While there are many models that can meet these requirements, we
based the architecture of SKMS on that of Domain Name Service (DNS).
DNS, as I'm sure you're familiar with, requires that the namespace
and IP addresses be defined on centrally-managed DNS servers, and
that clients only query the nameservers for information. DNS
clients do not add/update/delete nameservice information on the
servers (except within the limited scope of DHCP, which is but a
variation of the centralized policy definition and name-IP address
management principle); so their protocol is mostly limited to
querying the DNS server for name-service information.
The implementation requirements that we heard from customers were
that:
a) the server must do all the heavy-lifting of key-generation, key-
management, access-control, etc.;
b) client applications must require minimal modifications to
participate in this architecture and process;
Given these, while it is possible to have a client generate symmetric
keys and send it to a server for addition/update/deletion, it would
require far more of the client-application and of the security
infrastructure to trust such add/update/deletes from client devices.
Secondly, ensuring that all clients conform to policy would require
that all clients be continually updated to know of such policies and
when such policies are updated.
By having the server perform ALL the work wrt key-generation, policy
conformance and key-management, it simplifies client-requirements to
using just one call - that of requesting a symmetric key (new or
existing) and using that key within the policy-constraints embedded
inside each key (the SKSML protocol embeds a KeyUsePolicy inside each
symmetric key). The server handles the rest.
Consequently, client applications in a Symmetric Key Management System
(SKMS) need only know how to request a key and where to request it from.
The Symmetric Key Client Library (SKCL) handles the rest - just like the
nameservice library in DNS handles all name-resolution activties for all
applications on a machine.
WRT to your comments in the scope section:
1) The "space" in which the SKSML protocol will be used is between
any client and server that needs symmetric key-management services
in any domain. The need for asymmetric key-management services are
currently addressed by IETF-PKIX protocols and are not within scope
of the EKMI charter;
2) Sending of keys TO the server is not within the initial scope of
this TC, given the premise described earlier. However, as the TC
addresses the initial problem and evolves, business requirements
from constituents may expand the scope to address sending keys to
the server;
3) Yes, the interoperability test suite is a compliance suite;
4) WRT scope item D, this TC has heard business requirements from
customers that would like to see implementation, operational and
audit guidelines for building, operating and auditing EKMI
infrastructures for compliance to specific regulations such as
PCI-DSS (as an example). This TC intends to create papers that
provide such guidelines for implementing and operating EKMI's.
WRT the audit requirements, it is the intention of this TC to
work cooperatively with organizations such as ISACA to create
audit guidelines that would be used by auditors to audit EKMI
infrastructures.
WRT timelines, the original draft of this charter was written up in
August; the timelines are being revised to recognize the passage of
time to create this TC.
The EKMI-TC will have a liaison relationship with the WS-Trust TC.
I have already addressed the XKMS question in response to Phillip
Hallam-Baker's comments on this forum.
I trust the above helps clarify some of the confusion that may have
been caused by the charter. We anticipate writing up use-cases as
part of the documentation produced by the TC to further clarify how
and where the SKSML protocol may be used.
Regards,
Arshad Noor
StrongAuth, Inc.
|
Responded to Anthony Nadalin (although the
comment period was closed at this point).
|