[SPKM] Comments on draft-adamson-rfc2847-bis-01

[Eric Rescorla <[e-mail]>]

$Id: draft-adamson-rfc2487-bis-01-rev.txt,v 1.2 2006/10/30 22:47:13 ekr Exp $

BACKGROUND
This document describes two new GSS mechanisms:

- SPKM-3 -- an asymmetric key-based handshake and token protection
            scheme.
- LIPKEY -- a client-side password based authentication scheme with
	    server authentication via certificates. LIPKEY is 
	    a wrapper around SPKM-3.


GENERAL COMMENTS
1. Algorithms
Many of the algorithms described in this document should be
replaced with more modern algorithms.

For message integrity, this document specifies: 

    HMAC-MD5
    MD5/RSA
    SHA1/RSA
    DSA/SHA1
    DES-MAC
    MD5-DES-CBC
    SUM64-DES-CBC

The only ones of these algorithms that are appropriate for new
standards are SHA1/RSA and DSA/SHA-1. Wang et al.'s results clearly
imply that MD5 should be deprecated in all signature contexts and Kim
et al's results [0] suggest that HMAC-MD5 at least shouldn't be put
into new systems. HMAC-SHA1 is the appropriate replacement.

For confidentiality, this document specifies:
     
     AES256-CBC
     AES128-CBC
     DES-EDE3-CBC
     cast5CBC

These are probably all fine, but there's really no longer any
reason to include CAST. It also appears that somehow DES-CBC is
allowed. That's really not OK.

The OWF specified here is simply SHA-1 with the inputs concatenated.
Modern KDF designs almost always have the key being a separate input
value. E.g., HMAC-SHA1(key, seed....). I suggest copying the TLS
PRF, the IPsec KDF, or the NIST 800-56A KDF.

2. Incomplete specification
In a number of cases, the only documentation for fields is cursory
comments in the ASN.1. Every field should be explained in the
main body of the text.

3. MAC/signature overloading
In this document, symmetric MAC algorithms and asymmetric signature
algorithms are used semi-interchangeably. That's a dangerous
practice which tends to lead to confusion and brittle designs.
AFAICT, the signature algorithm is used to authenticate the
peers and the MAC algorithm is used to authenticate data packets.
Is there really any need to *sign* data packets? If there is, it
should be provided with a separate facility, esp. since the current
design provides no way for one side to ask for a signature on
specific packets and indeed discourages negotiating it (see S 2.3.1).

4. Multiple Negotiated algorithms
This mechanism seems to result in negotiating the intersection
of the acceptable algorithm sets. Why not just choose one algorithm
and stick with it like IPsec and TLS do? This seems like it has
obvious downgrade problems.


DETAILED COMMENTS
S 2.1.
A ladder diagram of the protocol flows would really help here.

S 2.3.2.
   A GSS  mechanism need not support confidentiality.  Making a
   confidentiality algorithm mandatory may preclude exportability of the
   mechanism implementation; this document therefore specifies certain

Exportability hasn't been a major concern for quite some time.

S 2.3.3.
I don't understand how you upgrade to stronger groups, since the
initiator sends its DH share before it talks to the server. How
would you upgrade to ECC, for instance?

S 2.4.1.1.
      Conf-Algs ::= CHOICE {
         algs [0]        SEQUENCE OF AlgorithmIdentifier,
         null [1]        NULL,
            -- used when conf. is not available over context
         ...
      }

Why not just allow an empty sequence instead of NULL?


   If the SPKM-3 implementation supports an algorithm weaker than
   cast5CBC, cast5CBC MUST be listed before the weaker algorithm to
   encourage the target to negotiate the stronger algorithm.

You shouldn't be specifying any algorithms weaker than cast5CBC.


S 2.4.1.2.
      REP-TI-TOKEN ::= SEQUENCE {
         rep-ti-contents Rep-ti-contents,
         algId           AlgorithmIdentifier,
            -- should be one of the digital signature algorithms
         rep-ti-integ    Integrity,  -- "token" is Rep-ti-contents
         ...
      }

Is there some way for the peer to express which digital signature
algorithms he wants? I don't see it.

         key-estb-id      AlgorithmIdentifier OPTIONAL,
            -- used if target is changing key estb. algorithm (MUST be
            -- a member of initiators key-estb-set)

I don't understand how this could happen.

S 2.4.2.2.
   md5WithRsaEncryption is currently stipulated for the signing of
   context establishment tokens.  Discrepancies involving modulus
   bitlength can be resolved through judicious use of the SPKM-GSS-ERROR
   token.  The context initiator signs REQ-TOKEN using the strongest RSA
   it supports (e.g., 1024 bits).  If the target is unable to verify
   signatures of this length, it sends SPKM-GSS- ERROR signed with the
   strongest RSA that it supports (e.g. 512).  Furthermore, the target
   can include an appropriate minor_status value
   (GSS_SPKM_S_SG_WEAK_KEY).

How does this work if the target has a key too big for the initiator
and you're in anonymous mode?


S 2.4.3.1.
     SPKM-MIC ::= SEQUENCE {
         mic-header       Mic-Header,
         int-cksum        BIT STRING,
            -- Checksum over header and data, calculated according to
            -- algorithm specified in int-alg field.
         ...
      }

The word "checksum" really isn't appropriate here. As noted 
previously, I think it's a mistake to treat MACs and signatures
as the same thing, but if you must, the right term here 
is "Message Integrity Check" (MIC).


      Mic-Header ::= SEQUENCE {
         tok-id           INTEGER (257),   -- shall contain 0101 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
            -- Integrity algorithm indicator (MUST be one of the agreed
            -- integrity algorithms for this context).
            -- field not present = default id.
         snd-seq [1]      SeqNum OPTIONAL,  -- sequence number field.
         ...
      }

Allowing switch-hitting of integrity algorithms seems problematic,
since it basically forces one side to receive packets with the lowest
jointly acceptable algorithm. Better to let the negotiation pick
the single best one.


S 2.8.
I don't understand the bit about the algorithm numbers being specified
by the mechanism specification. Is that this document? This may be
obvious to people steeped in GSS, but a little more explanation
might help.

The weak/medium/strong values here are quite out of date. 40 bits
is laughably weak. We should be deprecating these algorithms entirely.


   For the Confidentiality MA field:

      0001 (1) = DES-CBC
      0010 (2) = cast5CBC
      0011 (3) = aes256-CBC

I don't understand what happened to e.g., AES-128....


S 3.
Slightly more introductory text here might help. E.g.,

LIPKEY provides a mechanism for having target authentication via
certificates and client authentication via passwords. LIPKEY
is a wrapper around SPKM-3.


[0] http://eprint.iacr.org/2006/187	

-Ekr

_______________________________________________
SPKM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/spkm