Re: SKSML Was: Signing and Encrypting with the same key?

[Arshad Noor <arshad.noor@strongauth.com>]

There are two reasons why the encryption certificate is not part of
the SKSML payload, Anders:

1) It is a required part of the configuration of an SKMS Client on
    the SKS server (otherwise the server would be unable to encrypt
    the payload to the client).  Since the client already has its
    own encryption certificate, the server does not need to add to
    the message payload by sending it in every encrypted response.
    The SKCL and the SKS server both agree that the symmetric-key
    is *always* encrypted with the encryption digital certificate
    of the requester.  (This is not very complicated; the open-
    source StrongKey has been doing this for 2 years now on the
    server side).

    (I haven't investigated the SOAP WSS protocol deeply enough to
    determine if the signing certificate can also be dispensed with.
    Since an SKMS requires clients and servers to have certificates,
    and since XMLSignature can specify just the Subject DN, there is
    really no need to send signing certificates back-and-forth; both
    sides have all they need to verify the signature when the
    implementation is setup correctly with each client/server having
    the trusted certificate chain of the PKI that supports the SKMS).

    (BTW, before the question comes up, the Implementation Guidelines
    will recommend that SKMSs use "closed" PKIs for the infrastructure,
    as opposed to having SKMS certificates rooted in a public CA's
    certificate.  While this will require people to setup private
    PKIs for internal use, we believe it is more secure/appropriate
    for SKMS deployments).

2) An SKMS site may choose NOT to encrypt the SOAP Body; if they do
    choose to encrypt, they may choose to use a single SOAP-layer
    encryption certificate for all clients and servers (while using
    unique signing certs per entity) or they may choose to use unique
    SOAP-layer encryption certificates for all clients and servers.

    The problem is, we're now talking about implementation details
    and not protocol details.  I believe the protocol has the best
    chance of adoption if it is focused and simple, while leaving
    sites to implement all other layers outside the protocol.  While
    signing the SKSML does take us outside the "simple" focus, it
    was the best way of layering security without complicating the
    SKSML protocol.  SOAP-layer encryption is just an extension of
    the same principle.

Hope that helps.

Arshad


Anders Rundgren wrote:
> Arshad,
> 
> Thank you for clarifying this.  Unfortunately I still have a problem with this description :-(
> 
> One WSSE:BinarySecurityToken must obviously contain the sender's signature certificate if the 
> message is signed.
> 
> Another WSSE:BinarySecurityToken must obviously contain the recepient's encryption certificate if 
> the message is encrypted.
> 
> However, the encryption certificate I'm talking about should IMO be a payload in SKSML itself since 
> this is used for encrypting the response data, rather than the request.  If you do not have such a 
> facility, you complicate backend processing.  This is a feature of both DSKPP and KeyGen2.
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Arshad Noor" <arshad.noor@strongauth.com>
> To: "Anders Rundgren" <anders.rundgren@telia.com>
> Cc: "Tomas Gustavsson" <tomas@primekey.se>; "ekmi" <ekmi@lists.oasis-open.org>
> Sent: Wednesday, November 05, 2008 19:51
> Subject: Re: SKSML Was: Signing and Encrypting with the same key?
> 
> 
> There is only one <WSSE:Security> element, Anders, but if you
> sign *and* encrypt, there are two <WSSE:BinarySecurityToken>
> elements in the <WSSE:Security> token, one pointing to the
> sender's signing certificate and the other to the recipient's
> encryption certificate.  If you only sign or encrypt, then
> there will be only a single BinarySecurityToken element in the
> header.
> 
> SKSML only mandates signing of the SOAP Body contents; it does
> not mandate encrypting the SOAP Body's contents because the SKS
> server encrypts the symmetric key in the SKSML layer even before
> the SOAP layer sees it.
> 
> So, sites have the choice of choosing to encrypt the symmetric-key
> and encrypting the entire SKSML payload at the SOAP layer, or just
> encrypting the symmetric-key at the SKSML layer.  In either case,
> the symmetric-key is always safe (depending on the security of
> the cryptographic module that protects the private keys of the
> client and server).
> 
> I will update the SKSML specification to clarify that.  Thanks
> for the question.  It wasn't a stupid question; just inadequate
> explanation on my part.
> 
> Arshad
> 
> Anders Rundgren wrote:
>> Arshad,
>> I must be stupid but I still don't [get] it :-(
>>
>> As far as I can see you MUST have TWO WSS elements in a client request,
>> one for the signature, and one for encryption key.
>>
>> Anders
>>
>> ----- Original Message ----- 
>> From: "Arshad Noor" <arshad.noor@strongauth.com>
>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>> Cc: <ietf-pkix@imc.org>; "ekmi" <ekmi@lists.oasis-open.org>
>> Sent: Wednesday, November 05, 2008 18:31
>> Subject: Re: SKSML Was: Signing and Encrypting with the same key?
>>
>>
>> To paraphrase the Public Review 02 specification (which should be
>> available on the OASIS site by the end of this week):
>>
>> "..conforming implementations of the SKSML protocol MUST enclose all
>> SKSML messages between participants in an SKMS, in the SOAP Body of a
>> SOAP Envelope.  Additionally, the contents of the SOAP Body MUST be
>> secured using digital signatures conforming to [XMLSignature] in the
>> SOAP Header.  Specifically, the SOAP Header of the SOAP Envelope MUST
>> enclose a Security element conforming to [WSS] with a ValueType
>> attribute containing the value
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3.";
>>
>> Yes, all SKMS clients and servers are mandated to use a certain security
>> convention in SOAP, but the SKSML message is oblivious of its envelope.
>>   Secondly, how the digital certificates are constructed, how the client
>> and server key-pairs are managed, how the PKI is setup, managed and
>> audited, is not in the SKSML protocol.
>>
>> That is what I meant by "abstracting the security, implementation,
>> operations and audit" of an EKMI out of the protocol.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Anders Rundgren wrote:
>>> Arshad,
>>>
>>> Pardon my ignorance but I do not see how you can "abstract out" security solutions in a concrete
>>> SOAP specification, either it is there or it is not.  That is, with respect to the particular
>>> question and the current draft, you have no real alternative except stating that client and
>>> servers
>>> must be configured to support a common convention.  Which BTW may be exactly what you meant :-)
>>> That KeyGen2 is a 6-pass protocol is for avoiding conventions since the entities involved
>>> typically
>>> do not belong to the same "IT-domain".  E.g. a consumer with a mobile phone and his/her bank.
>>>
>>> Regarding the separate key stuff, the current strategy is to support it in the protocol, but not
>>> in
>>> the Open Source client-implementation since no compelling argument actually has been raised for
>>> having multiple keys, while there is quite a bunch of arguments against such an arrangement.  How
>>> is
>>> an SKSML server supposed to know what to encrypt with if you do not send the key in the request?
>>> It
>>> seems that an SKSML server must keep an encryption key database or be configured to use LDAP etc.
>>> It seems like a more straightforward solution to transfer encryption keys explicitly and validate
>>> them at receival in the same way as you do with signature and authentication keys.
>>>
>>> I'm a bit puzzled regarding how you intend to bootstrap SKSML with PKI, if the figures with a
>>> myriad
>>> of entirely different clients are still valid.  The reason I started the KeyGen2 effort is 
>>> because
>>> this is a veritable nightmare, particularly for mobile devices.  As a comparison I would like to
>>> mention the fact that there are some 100M TPM chips out there in major laptops, but they are
>>> "mostly
>>> of out work" because the bootstrapping issues haven't been fully addressed by the TPM designers.
>>>
>>> Anders
>>>
>>> ----- Original Message ----- 
>>> From: "Arshad Noor" <arshad.noor@strongauth.com>
>>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>>> Cc: "Timothy J. Miller" <tmiller@mitre.org>; "Peter Gutmann" <pgut001@cs.auckland.ac.nz>;
>>> <ietf-pkix@imc.org>
>>> Sent: Tuesday, November 04, 2008 22:24
>>> Subject: Re: Signing and Encrypting with the same key?
>>>
>>>
>>>
>>> Hi Anders,
>>>
>>> The reason we haven't mentioned it yet is because the TC is going
>>> to begin the task of creating Implementation, Operations and Audit
>>> Guidelines for EKMI only in 2009.  It is within these guidelines
>>> where a recommendation for separating signing & encryption key-pairs
>>> would be made.
>>>
>>> The SKSML protocol focuses on the minimum necessary syntax to send
>>> and receive messages related to symmetric-key management.  The
>>> security, implementation, operations and audit of such Enterprise
>>> Key Management Infrastructures must be capable of being abstracted
>>> out of the protocol, layered and managed independently.  Which is
>>> why there is no mention of separated key-pairs yet.  However, you
>>> can expect to see it in the Guidelines next year.
>>>
>>> Arshad Noor
>>> StrongAuth, Inc.
>>>
>>>
>>> Anders Rundgren wrote:
>>>> Hi Arshad,
>>>> I just skimmed through the non-normative spec and example and from that I could not see any
>>>> mentioning of separate keys.
>>>>
>>>> I digged a bit further but could still not find such references in:
>>>> http://www.oasis-open.org/committees/download.php/28725/SKSML-1.0-Specification-Normative-DRAFT6.0.pdf
>>>>
>>>> I don't know what you have planned, but IMO you need additional elements in the protocol (like
>>>> giving the client a place to put its encryption key), as well as a standard for how encryption
>>>> and
>>>> signature keys link together otherwise the server cannot be sure that it is encrypting for the
>>>> client that authenticated.  All this is the reason why I'm not overly enthusiastic of having
>>>> multiple entity-keys in a provisioning protocol, particularly since all attacks I have heard
>>>> about
>>>> to date, have been based on flawed implementations, which is moderately interesting from a
>>>> *protocol-design* point-of-view:
>>>> http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html
>>>>
>>>> But it is possible that SKSML will run in more restricted environments than KeyGen2 and thus can
>>>> build on that the client and servers use "conventions", keeping the protocol smallish.   KeyGen2
>>>> is
>>>> designed to cope with a fragmented world and thus sports a capability/policy negotiation
>>>> facility.
>>>>
>>>> Anders
>>>>
>>>> ----- Original Message ----- 
>>>> From: "Arshad Noor" <arshad.noor@strongauth.com>
>>>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>>>> Cc: "Timothy J. Miller" <tmiller@mitre.org>; "Peter Gutmann" <pgut001@cs.auckland.ac.nz>;
>>>> <ietf-pkix@imc.org>
>>>> Sent: Tuesday, November 04, 2008 21:11
>>>> Subject: Re: Signing and Encrypting with the same key?
>>>>
>>>>
>>>> Anders,
>>>>
>>>> Just to clarify, the SKSML protocol does not mandate how the
>>>> digital certificate of SKMS clients and servers should be
>>>> constructed, or what the keyUsage extension should look like
>>>> within such certificates.  We believe that that is an
>>>> implementation detail of the PKI that supports the SKMS.
>>>>
>>>> The SKMS only requires that every client and server have a
>>>> signing key and an encryption key.  They can be the same
>>>> key-pair or two different key-pairs, depending on the PKI
>>>> certificate policy of the implementation site.
>>>>
>>>> Within the open-source StrongKey software we have, we require
>>>> two digital certificates to be configured for SKMS clients and
>>>> servers, to separate signing and encryption uses.  The test
>>>> certs we bundle with the FOSS, combines signing & encryption
>>>> merely as a convenience for people "kicking the tires".
>>>>
>>>> As a conservative practice, we recommend that PKIs separate
>>>> the signing and encryption capability into different digital
>>>> certificates.
>>>>
>>>> Arshad Noor
>>>> StrongAuth, Inc.
>>>>
>>>> Anders Rundgren wrote:
>>>>> Another reference is OASIS EKMI:
>>>>> http://www.oasis-open.org/committees/download.php/28657/SKSML-1.0-Specification-Non-Normative-DRAFT6.pdf
>>>>> From what I can deduct they indeed authenticate the requesting client through a signature and
>>>>> then
>>>>> return the key by wrapping it by the public signature key.
>>>>>
>