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

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

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.
>>>>
>