draft-sun-handle-system-protocol-04

[Russ Housley <housley@vigilsec.com>]

I have many comments on draft-sun-handle-system-protocol-04.

1.  One of the other documents in this series discusses non-repudiation, 
but that concept does not appear here.  There seems to be a disconnect.

2.  In section 1, I do not understand the term "service integrity."  I 
understand "data integrity."  It is a security service.  Perhaps that is 
the intent, but I am not sure.  The word "service" could be referring to 
the Handle System Service.

3.  In section 2.2.4, it says:

        <Signer> ::= <HANDLE>
                     <INDEX>
        A reference to a handle value in terms of the <HANDLE> and the
        <INDEX> of the handle value. The handle value may contain the
        public key that can be used to validate the digital signature.

Another document in this series indicates that X.509 certificates are 
supported in addition to raw public keys.  Is the certificate another thing 
that the handle may contain?

4.  In section 2.2.4, it also says:

                <SIGNATURE>
                Contains the digital signature or the MAC over the
                Message Header and Message Body. The syntax and semantics
                of the signature depend on the <Type> field and the
                public key referenced in the <Signer> field. For example,
                if the <Type> field is "HS_SIGNED" and the public key
                referred to by the <Signer> field is a DSA [6] public
                key, the signature will be the X.509 [7] (using ASN.1
                encoding) representation of the parameter R and S used by
                DSA.

X.509 does not describe the encoding of R and S into a signature 
value.  Rather, X.509 treats all signature values as ASN.1 BIT 
STRINGs.  You should reference RFC 3279 for the ASN.1 handling of DSA 
signature values in certificates.  RFC 3370 is a better reference for the 
handling of R and S encoding for a signature value.  One fewer layers of 
wrapper are used in CMS signatures, and that makes more sense in this 
context.  I would prefer a reference to RFC 3280 for the handling of 
certificates.

Further, it would be better to have a signature algorithm identifier at 
this level.  Consider the case where an RSA public key is provided.  The 
recipient cannot determine whether the signature was generated using PKCS 
#1 version 1.5 or PSS from the public key type.

6.  In section 3.5.1, guidance is needed on the size of the nonce.  Twenty 
octets is a reasonable value.

7.  In section 3.5.2, it says: "MD5_Hash(<SecretKey> + <ServerChallenge> + 
<SecretKey>)."  HMAC is a well-studied integrity mechanism.  Why isn't it 
being used here?

8.  In section 3.5.2, it also says:

             If the <AuthenticationType> is "HS_PUBKEY", the
             <ChallengeResponse> contains the digital signature over the
             Message Body portion of the server's challenge. The
             signature consists of a UTF8-String that specifies the
             digest algorithm used for the signature, followed by the
             signature over the server's challenge. The <KeyHandle> and
             <KeyIndex> refers to the administrator's public key that can
             be used to verify the signature.

This construction is better than I expected from the high-level description 
in one of the other documents in the series.  However, the signer should 
include a locally-generated random value in the response.  Otherwise, the 
challenge generator could construct the challenge (perhaps with great 
effort, employing lots of precomputation) that matches the hash value of a 
contract.  In this way, the admin is tricked into signing a contract 
thinking that simple authentication was being performed.  The 
locally-generated random value completely thwarts such an attack.

Another question.  Is the server always going to sign the challenge?  What 
happens if that signature does not verify properly?

A recommendation.  Describe the signature process as two steps.  First, a 
one-way hash (or message digest, if you prefer) value is computed over the 
blob that is to be signed.  Second, the hash value is signed with the 
private key.

9.  In section 3.5.3, the challenge is returned, but the server's signature 
on the challenge is not.  Seems like both should be returned, or 
neither.  The server needs to maintain some state here to confirm that the 
challenge value chose by the server is the one actually returned.

10.  In section 3.8.1, the session key management is quite limited.  It 
seems to only support key transport schemes, omitting key agreement 
schemes.  If this is incorrect, further explanation is needed.  Also, how 
do the client and server agree on the encryption algorithm that will be 
used with this session key.  I do not see a protocol field to transfer an 
encryption algorithm identifier, which is needed to ensure that the key is 
of the correct size.

Russ