CAT WG LAST CALL: draft-ietf-cat-spkmgss-03.txt

[John Linn <[e-mail]>]

CAT fanciers:

Carlisle's draft, reflecting revisions per discussion in this message,
has emerged as draft-ietf-cat-spkmgss-03.txt.  I hereby declare a
one-week WG last call period, to end on Wednesday, 24 May, for review
and comment on the changes made relative to draft-ietf-cat-spkmgss-02;
if no such issues are raised on the list during this period, I will
(per discussion at the Danvers meeting) then request on behalf of
the WG that draft-ietf-cat-spkmgss-03 be considered by the IESG for
advancement to Proposed Standard.

--jl

------- Forwarded Message

Received: from bnr.ca by pad-thai.cam.ov.com (8.6.12/) with SMTP
	id <[e-mail]>; Tue, 9 May 1995 14:26:48 -0400
X400-Received:  
 by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 May 1995 14:24:35 -0400 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 May 1995 14:24:12 -0400 
X400-Received:  
 by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 9 May 1995 11:48:00 -0400 
Date:  Tue, 9 May 1995 11:48:00 -0400 
X400-Originator:  /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca 
X400-MTS-Identifier:  
 [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.350:09.04.95.18.24.12] 
X400-Content-Type:  P2-1984 (2) 
Content-Identifier:  SPKM-03... 
From: "carlisle (c.m.) adams" <[e-mail]>
Sender: "carlisle (c.m.) adams" <[e-mail]>
Message-ID:  <"5356 Tue May  9 14:24:14 1995"@bnr.ca> 
To: [e-mail]
Cc: [e-mail]
Subject:  SPKM-03... 

Hello,

Well, it seems like a long time since the Danvers meeting, but I believe that
SPKM is now ready.  

As you may recall, the main outstanding issue was one which Piers McMahon raised
regarding the possibility of a replay attack under some restricted conditions.
In particular, using SPKM-2 (the timestamp-based authentication) in unilateral
mode, an attacker could initiate a new context and replay messages from another
context on the new context (but only messages which had not been integrity 
protected with a true digital signature).  The question which I was to investigate 
was whether or not the key establishment protocol X9.44 has built-in facilities 
which can be used to avoid this attack.

I was (finally!) able to track down a current copy of X9.44 and ascertain that,
indeed, those facilities are there and this attack cannot therefore be mounted.
However, partially because X9.44 is not yet completely stable, and partially for
the sake of generality, I have decided to use an alternate solution.  The K-ALG
which must be supported is now specified to be RSAEncryption (i.e., a symmetric 
key encrypted with the RSA public key of the recipient) and an optional field
has been added ("key_src_bind") which is a binding between the offered symmetric
key and the source (i.e., initiator's) name -- the binding used is an md5 hash
(that is, the field content is the md5 hash of the src_name concatenated with
the key).  It is specified that this field must be present for SPKM-2 unilateral, 
but is optional for all other cases.  Note that I could have made the binding a MAC, 
as Piers had suggested, but this currently requires the presence of a symmetric 
algorithm which, for export-type reasons, I'm reluctant to mandate for conformance
to the spec.

I have also taken this opportunity to make a few other (minor) changes:

  - there were a couple of spots where behaviour description needed to be 
    tightened up (in the CertificationPath field, for example), so this has been
    done;

  - it was pointed out to me that the ASN.1 as written would not pass cleanly
    through an ASN.1 compiler, so this has been fixed up to make IMPORTed 
    definitions more precise and all SPKM definitions more syntactically correct;

  - anonymity, which was (sort of) implicitly supported in SPKM-1, is now explicitly
    supported (the initiator can choose to remain anonymous and simply authenticate
    the target).  [Note that the way that an application requests anonymity is a
    GSS issue, we've only made explicit how SPKM can actually implement it.]
    Anonymity is achieved as follows:  the requestToken inside the first context
    establishment token (SPKM_REQ) is no longer a SIGNED SEQUENCE, but is now a
    SEQUENCE followed by a CHOICE of either a SIGNATURE or a MAC on requestToken.  
    When the initiator wishes to remain anonymous, the MAC is used (and the
    offered context key is used as the MAC key) -- this allows anonymity while
    still providing the integrity necessary for that token.  If, instead, the
    SIGNATURE is chosen, the token is equivalent to what was in the previous
    SPKM draft.
    Anonymity is not available in SPKM-2 (the timestamp-based authentication)
    because either the initiator is authenticated (unilateral) or both are
    (mutual) -- there is no sensible way to allow an anonymous initiator.


Carlisle.


------- End of Forwarded Message