Subject: [AAA-WG]: End-to-End Security Proposal

From: Don Zick <[email-masked]>
Date: Tue, 16 Oct 2001 17:50:45 -0400

Help!  I'm finding it difficult to use my S/MIME toolkit to implement
the
proposed CMS Security Application.  I think the CMS Security Application

provides more sophistication and complexity than is necessary.  Am I
alone
here?  Part of it may simply be that I am a newcomer to CMS and S/MIME
and
part of it may be that my S/MIME toolkit does not implement the latest
CMS
standard.

Could we consider an End-to-End security scheme that does not require
CMS?
I think it may be possible to achieve the desired security goals without

using CMS or S/MIME and to simplify Diameter End-to-End security at the
same time.

I propose changing the Diameter End-to-End security scheme as follows:

- Eliminate the Local-CA-info and CA-Chain AVPs.  Certificate Authority
  databases must be maintained at Diameter nodes.  (A Certificate
Authority
  database must already be maintained by Diameter Servers to support
TLS,
  and the database must now also include all CAs required for End-to-End

  security.)
- Replace AAA-Server-Certs and CMS-Cert AVPs with the Origin-Certificate

  AVP.  The Origin-Certificate subjectAltName field contains a dNSName
that
  is set to either the FQDN or the realm of a Diameter host.  Setting
the dNSName
  to a realm name allows a set of Diameter Servers to use the same
certificate.
- Eliminate OCSP-Request-Flags, OCSP-Nonce, and OCSP-Responses AVPs.
  It is up to the diameter peers to validate certificates during the
establishment
  of the security association as is done during a TLS handshake.
Endpoints
  share each other's certificates and may terminate security
associations if
  notified outside of the Diameter protocol that a certificate has been
revoked.
- Eliminate DSA-TTL AVP.  The proposed scheme requires endpoints to
exchange
  certificates.  The certificate expiration time may be used to
determine when a DSA
  must expire.
- Eliminate Expected-Signed-AVP and Expected-Encrypted-AVP AVPs.  The
  proposed scheme requires that Diameter protocol specifications must
indicate
  which AVPs must be signed and encrypted when a DSA has been
established.
  The proposal also allows optional AVPs to be signed and/or encrypted
if
  desired.
- Replace CMS-Encrypted-Data AVP with Encrypted-Data AVP
- Replace CMS-Signed-Data AVP with Signed-Data AVP.

This proposal requires that each Diameter host participating in a
security
association have a certificate and an associated private key.  A
certificate
and private key may be installed on and used by a particular host, or it
may
be installed on and used by all Diameter Servers in a realm.

Proposed Diameter-Security-Association-Request

Message Format
   <DSAR> :: < Diameter-Header: 304, REQ, PXY >
             { Origin-Host }
             { Origin-Realm }
             { Destination-Realm }
             { Auth-Application-Id }
             { Origin-Certificate }
             [ Destination-Host ]
             [ Origin-State-Id ]
           * [ AVP ]
           * [ Proxy-Info ]
           * [ Route-Record ]

Proposed Diameter-Security-Association-Answer

Message Format
   <DSAR> :: < Diameter-Header: 304, PXY >
             { Result-Code }
             { Origin-Host }
             { Auth-Application-Id }
             { Origin-Realm }
             { Destination-Realm }
             [ Origin-Certificate ]
             [ Destination-Host ]
           * [ AVP ]
           * [ Proxy-Info ]
           * [ Route-Record ]

Definitions of New AVPs
-----------------------

Origin-Certificate AVP
Origin-Certificate AVP is of type OctetString, and contains the
certificate for the origin realm or origin host.  The certificate is
encoded
using DER.  The certificate subjectAltName field contains a dNSName that
is
set to either the FQDN or the realm of the origin host.  Setting the
dNSName
to a realm name allows a set of Diameter Servers to use the same
certificate.

Encrypted-Data AVP
Encrypted-Data AVP is of type Group.  It has the following message
format:

   Encrypted-Data ::= < AVP Header: ??? >
                      { Destination Realm }
                      { ED-Origin-Session-Key-Number }
                      { ED-Origin-Session-Key }
                      { Encrypted-Data-Value }
                      [ Destination Host ]

The ED-Origin-Session-Key-Number is of type Unsigned32.  It
identifies the origin session key that is used to encrypt
data for the Encrypted-Data-Value AVP.  The same origin session
key may be used for a number of messages.  Each
time a new origin session key is created the origin session
key number is incremented.  A receiving host can decrypt
the ED-Origin-Session-Key using the receiving hosts private key; this
asymmetric decryption is slow and to be avoided when possible.
A receiving host can remember the decrypted origin session key
and the ED-Origin-Session-Key-Number so that if another
Encrypted-Data AVP is later received with the same
ED-Origin-Session-Key-Number
the ED-Origin-Session-Key does not have to be decrypted again.
It is helpful to always include the ED-Origin-Session-Key-Number
and ED-Origin-Session-Key because it allows the Encrypted-Data-Value
AVP to be decrypted by any Diameter Server in a realm that has
the required private key.  It also allows for a new origin session
key to be generated by the origin host whenever it deems it appropriate
to do so.

The ED-Origin-Session-Key is of type OctetString and contains a
session key randomly generated by the message originator.  The
session key is encrypted using the public key of the Destination
so that only the Destination can decrypt it.  The origin session
key is used to encrypt data for the Encrypted-Data-Value AVP.

The Encrypted-Data-Value AVP is formed by concatenating all
AVPs in a message that require encryption and encrypting them
with 3DES using the origin session key.  (The origin session
key is used to decrypt this AVP.)

Signed-Data AVP
Signed-Data AVP is of type Group.  It has the following message format:

   Signed-Data ::= < AVP Header: ??? >
                1* { AVP }
                   { Signature }
                   [ Origin-Host ]

Any AVP requiring a signature must be included in this group; if any
encrypted AVP must be signed, the Encrypted-Data AVP must be put into
this group.

The Signature AVP contains an RSA digital signature for the list of
AVPs requiring a signature.

Countersigning is not supported.  If a proxy wishes to add a signature
to AVP data, it must create a new Signed-Data AVP that includes the
AVPs requiring its signature.

I'm very interested in hearing if any others would like to see similar
changes.

Thanks for taking the time to read this.

With kind regards,
Don Zick
Interlink Networks, Inc.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Oct 2001 12:04:07 +0100

Hi Don,

It would be a *bad* idea for this group to start inventing key 
management schemes - using CMS means we use the work already
done over the last 5 or so years by a large bunch of cryptographers 
and security protocol folks. Throwing that away doesn't sound
at all sensible to me.

I think that's the main issue, but have responded to in 
more detail below.

Stephen.

Don Zick wrote:
> the proposed CMS Security Application.  I think the CMS Security Application
> alone here?  Part of it may simply be that I am a newcomer to CMS and S/MIME
> and part of it may be that my S/MIME toolkit does not implement the latest
> CMS standard.

I'd be surprised if the latter was the case, since our use of CMS should
allow an S/MIME v2 toolkit to be used. What difficulties have you 
actually found? 

> Could we consider an End-to-End security scheme that does not require

It would be a major piece of work to start defining how to do 
signing/encryption/key exchange etc. without using CMS (and this
just isn't the right venue for such work in any case).

> using CMS or S/MIME and to simplify Diameter End-to-End security at the

You seem to be proposing two types of changes, with different impacts:

- changes to how we're using PKI
- changes to how we do signing/encryption etc.

Overall, I'd argue that the PKI changes would make the Diameter spec
look simpler but just push (actually hide) the complexity back down 
into the generic PKI code and thereby likely reduce interop.

For the second case, I basically think it'd be very unwise for this
group to start defining e.g. key exchange mechanisms. Take a peek at
the smime or tls wg's archives to see how hard some of these things
get!

In any case, responding to the details...

>   databases must be maintained at Diameter nodes.  (A Certificate Authority
>   database must already be maintained by Diameter Servers to support TLS,

Local-CA-info is how one node tells another which CAs it trusts. Without
this, you're basically reduced to there being a few global public CAs
that everyone trusts (as happens now with browsers). I don't think that 
that's what's required. Note also that this is more or less the same
trick as used in TLS handshakes.

The CA-Chain AVP basically makes it easier for nodes by getting rid
of some of the potential flexibility that general handling of 
certificate chains involves (we're insisting that all AAA nodes in a 
given realm use the same CA). Without this, nodes would have to be
able to process more complex certificate chains (e.g. where two AAA
servers in the same realm are certified by different CAs).

Basically, while removing these AVPs might make the Diameter CMS 
specification look simpler, it'd reduce the chances of successfully
establishing a DSA with a node somewhere on the Internet.

>   AVP.  The Origin-Certificate subjectAltName field contains a dNSName that
>   is set to either the FQDN or the realm of a Diameter host.  Setting the dNSName
>   to a realm name allows a set of Diameter Servers to use the same certificate.

I don't follow you here - other than suggesting changing the name of 
the AAA-Server-Certs AVP what's the difference? 

>   It is up to the diameter peers to validate certificates during the establishment
>   of the security association as is done during a TLS handshake. Endpoints
>   share each other's certificates and may terminate security associations if
>   notified outside of the Diameter protocol that a certificate has been revoked.

The OCSP stuff is optional. The reason for including it is that I expect
there'll be cases where nodes cannot reasonably be expected to be able to
get certificate status information except via Diameter. I'd say that experience
(of using PKIs) has shown that this is worthwhile.

> exchange certificates.  The certificate expiration time may be used to
> determine when a DSA must expire.

While this is possible, I don't think its reasonable - do you think a 
DSA expiry averaging 6 months is reasonable? That could be a lot of 
NV storage!

> indicate which AVPs must be signed and encrypted when a DSA has been
> established. The proposal also allows optional AVPs to be signed and/or 
> encrypted if desired.

Without these, how can nodes find out what security other nodes expect
to be applied?

> - Replace CMS-Signed-Data AVP with Signed-Data AVP.

EEK! Really, take a peek at the smime wg archives to see what a 
hornet's nest your suggesting we open up.

[...] 

>                       { ED-Origin-Session-Key }
[...]
>    Signed-Data ::= < AVP Header: ??? >

Ok, questions:

- How can I ever use DSA, ECC or D-H with these? Even if RSA is 
  mandatory, fixing that in the protocol is unwise.
- How to I indicate the algorithm for the session key? Fixing 3-DES
  in the protocol is unwise.
- Where do I put IVs?
- Where do I put algorithm parameters?
- How is the session key wrapped (which key bits are where, say for 
  RC4-export or AES?) [Note: this can be a *hard* problem!!!]
- How do I setup a session key with >1 recipient?
- How is the data transformed before encrypting/signing (padding, use
  of OAEP etc).
- How do I tell someone they can forget a session key?
- If a session key is reused, does repeated encryption expose anything
  about the cleartext? (say where an attacker forces encryption of 
  a known plaintext-block-1 by connecting to a NAS and then watches
  until someone else's connection results in the same ciphertext)
- Given some (key or data) wrapping, how do we know its not vulnerable 
  to some crypto attacks? (E.g. something like the million message 
  attack on pkcs#1?)

Do we really want to go there? I think not. (In fact, I hope you
don't try to answer those questions:-)

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Don Zick <[email-masked]>
Date: Wed, 17 Oct 2001 09:52:52 -0400

Hi Stephen,

Thank you for your reply.  You raise some excellent points and have enlightened me on a
number of issues.  It just seems to this newcomer that CMS may be overkill for what we
need to do.  I would have hoped that based on what has been learned over the years in
the CMS debates that we could have come up with a reasonable set of AVPs to support
End-to-End security without requiring an S/MIME toolkit, which for me is proving to be
painful.  I am continuing to learn and understand about CMS and I appreciate your
explanations.

I have been doing some testing with OpenSSL.  This toolkit has support for PKCS #7 (CMS
Version 1.5).  Will that work for the Diameter CMS Security Application?  If not, do
you recommend any toolkits in particular?

I have some questions about the Diameter CMS Security Application draft 3 alpha 1.

1. The end of section 6 states that all MIME encoded data in this specification MUST
use the "application/pkcs7-mime" MIME type.  OpenSSL supports the
"application/x-pkcs7-mime".  Will the OpenSSL format work?

2. From section 6.1, BER encoding is used.  OpenSSL only supports DER, which is more
restrictive.  Is this a problem?

3. From section 6.3, MIME(x) represents the MIME encoding of x.  Will my mime encoded
buffer look like this?

    MIME-Version:    1.0
    Content-Type:        base64

    {Base 64 encoded AVP List}

4. From section 6.3, EnvelopedData-fnc(x,y) and SignedData(y) routines are described.
I'm still trying to figure out if/how OpenSSL can perform these functions.  Will PKCS
#7 routines be appropriate to use here?

5. OpenSSL does not easily support counter-signatures.  How important are these?

Thanks again for your reply,
Don Zick
Interlink Networks, Inc.

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 17 Oct 2001 20:07:12 +0530 (IST)

don,

   hi! I have been working on GSSAPI for Diameter End-to-End security.
   This is an experimental piece of work which I have been working on 
   some time now. You can find the latest version of the draft 
   draft-kaushik-diameter-strong-sec-03.txt.  I need to update the draft 
   based on some recent changes.

   I am attaching the latest version of the draft along with this email 
   since I have recently updated the IETF drafts directory and I can't 
   see the latest version out there.

 regards,
   kaushik!

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Oct 2001 18:13:58 +0100

Hi Don,

> Version 1.5).  Will that work for the Diameter CMS Security Application?  

That should be fine for everything except the re-use of content encryption keys
(which is a new spec. & is optional for Diameter in any case).

> If not, do

Ahem. Commercials are probably not a good idea:-)

You could look at www.imc.org - I think there's information about
various s/mime implementations there.

> "application/x-pkcs7-mime".  Will the OpenSSL format work?

Hmm. Should be fine for CMS-Encrypted-Data (you can just change it). I need
to check the spec about signed (I'm out of the office now.)

If there are any problems we should allow either (x-pkcs7-mime used to be
pretty widely supported), on receipt probably.

> restrictive.  Is this a problem?

DER is a subset of BER, so emitting DER is fine. If your version of openssl
doesn't support decoding BER (I'd be surprised about that) then that could
be a problem (OTOH, we could maybe get away with ruling out indefinite
length encoding - I originally changed to BER 'cause a colleague who was
coding up an early version found that easier.)

>     {Base 64 encoded AVP List}

Not-in-office excuse again I'm afraid, get back to you tomorrow.

> #7 routines be appropriate to use here?

Yes.

> 5. OpenSSL does not easily support counter-signatures.  How important are these?

Personally, I'm not that sure. I seem to recall some people wanting them
for accounting purposes - I'd be surprised if there were a real "in-line" 
need to counter-signing.

Stephen.