Re: [dss] JPMorgan/RSA message

[Glenn.Benson@chase.com]

Topic:
Initial brainstorming of "Signature Gateway Profile" and "Embedded Client
Authentication Profile"

New DSS Profiles:
We require at least one, and possibly two new DSS profiles.  The first
profile is the "Signature Gateway Profile".  This profile specifies a
server that accepts a signed message from a client.  After validating the
request, the server re-signs a message using the server's key.  We call the
profile a gateway because the signing technology used in the request does
not necessarily match the signing technology employed in the response.  The
following use case provides motivation.

Example Use Case:
Most businesses use a DMZ to separate an internal "safe zone" from an
external network.  Sophisticated firewalls or bastion hosts located in the
DMZ validate traffic received from the external network, and forward the
traffic into the "safe zone".  In some cases, end-user signs data; and the
DMZ's traffic validation process performs the requisite signature
validation.  Servers located in the "safe zone" do not need to re-validate
the end-user's signature because the "safe zone" server trusts the DMZ's
validation.

The DMZ server forwards all transmissions that it receives from the
end-user regardless of the status of the signature validation.  However,
the DMZ server injects a token into the transmission which indicates the
signature validation status.  Presumably, the server located in the "safe
zone" merely validates the token, and does not need to validate the entire
end-user's signature.

The overall security architecture mandates two distinct authentication
infrastructures.  The first infrastructure provides an underlying platform
through which the end-user authenticates to the DMZ server via signature
technology.  The second authentication infrastructure permits the DMZ
server to authenticate to the server located in the "safe zone".  The
business requires the flexibility to handle the technologies, logistics,
and governance of the disparate authentication infrastructures
independently.  For example, the business may deploy one-time passwords or
PKI credentials to external end-users; and deploy fixed shared keys to the
DMZ servers and "safe zone" servers.  In this example, the DMZ server
handles the relatively complex management task of validating signatures
that originate from a multitude of external clients.  The DMZ server may
potentially employ hardware acceleration in an effort to enhance
throughput.  The "safe zone" servers; however, merely validate an HMAC
produced by the central server.  The relative speed and simplicity of the
HMAC alleviates the "safe zone" servers from any requirement that would
dictate cryptographic acceleration.

New technologies such as XML firewalls, deep packet inspection firewalls,
and network cryptographic acceleration appliances would be ideal platforms
for hosting a Signature Gateway.

Signature Gateway Profile:
We may establish a Signature Gateway Profile under the auspices of DSS.
The Signature Gateway Profile transforms the end-user's signature, into a
token produced by the Gateway Server.  We may specify the token in the form
of an XMLDSIG-compliant signature.  We should explicitly note that XMLDSIG
permits HMAC.  The profile should allow a configuration in which the token
is a signature computed over the original, end-user's signature.  This
configuration would free the "safe zone" server from the requirement to
validate message digests of the original data payload.