Subject: [AAA-WG]: e2e-sec-02.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 17 May 2001 13:42:45 +0300

I have read and reviewed the end-to-end security draft

  http://www.diameter.org/draft-ietf-aaa-diameter-e2e-sec-02.txt

and have the following comments and questions:

- 1.0: "IPSec" => "IPsec" (elsewhere correct)

- Abstract refers to non-repudiation. I seem to
  remember many discussions on the exact meaning
  of non-repudiation, perhaps it would make sense
  to change the text to be more specific. Like
  this: "..., for making it possible to prove
  the real sender of the data."

- Figure 1, maybe the example should number the
  servers DIA1, DIA2, and DIA3.

- Before Figure 3, you talk about the expensive
  transformations and the need to have a mixed
  security model in some cases. I agree, but
  shouldn't we consider this also in the discussion
  of where e2e extension is mandatory? I.e. not
  make it a must for NASes...

- 1.2: I don't understand why a node that supports
  e2e would not advertise this. Why not?

- 3.1, the ESSR&ESSA scheme: here I think lies
  an issue that we should discuss in-depth and
  make sure we make the right design choice for
  DIAMETER. The way that the spec is written now,
  it basically requires all DIAMETER nodes to
  initiate the ESSR&ESSA handshake for all
  new domains. Nodes that do not support e2e
  will not be able to do this. Nodes that do
  support e2e are forced to an additional roundtrip
  delay even in the case that e2e wasn't really
  necessary for the domain.

  One way to deal with these kinds of situations is to
  use an optimistic mechanisms which naks the use of
  unsecured messages when e2e is required. However,
  the drawback of that is that potentially some data
  has already been revealed. But has it? It is hard
  for me to see exactly what sensitive information
  the first DIAMETER message versus the later ones
  have... this may need further analysis. I also lack
  a proposal how to handle the mixed security case
  with the currently proposed ESSR&ESSA scheme,
  i.e. who is responsible for doing the probing,
  and what support is mandated for which nodes.

- The caching of ESSR&ESSA information isn't
  discussed. Shouldn't it be?

- 3.1: "digial" => "digital"

- 3.1, the rfc822Address scheme: can we clarify the
  reason why the host name must take a special form?
  Is it because the CA might be the CA also for
  other nodes, but we want only a subset of nodes
  to be authorized to do DIAMETER. In other words,
  we are using the name field as a poor man's
  attribute certificate? I'm fine with it, just
  want to know...

- 3.2, I think it would be valuable indeed to
  specify a more limited profile of both the
  PKI and CMS parts! In my opinion this work
  should perhaps take place now, before we
  publish the DIAMETER RFCs... one way to do
  this is to list exactly what is really required
  from CMS for instance... my guess is that
  we actually do need only a small fraction of
  CMS and not all variants of encapsulations.

- 3.4, I would expect that the number of AVP
  encryptions one can do with the same symmetric
  key is fairly high, more like hours of use
  rather than minutes or few sessions. Also,
  perhaps the document would benefit from stating
  that the symmetric key optimization isn't possible
  for the signatures if non-repudiation is desires.
  (Right?)

- 5,0, the flow: what happens if the DRIs from the
  proxy onwards indicated that e2e security is not
  supported? Will the proxy return back a lower
  level DIAMETER error, or a fake ESSA with an error
  code?

- I suppose for the example's sake you're only
  signing NAS->home and only encrypting Home->NAS?
  But still both are possible on both directions,
  right?

- 6.1, the S/MIME profile reuse. Doesn't this limit
  the CMS to a fairly small subset? I lack sufficient
  knowledge of the S/MIME & CMS details to say whether
  something relevant is taken away, but perhaps you
  would care to comment on this? Note that I *do*
  want a small subset, but am just wondering if the
  s/mime subset is the one that we want.

- 6.1 and 6.2, the CMS object ContentInfo. May I
  suggest that we explicitly state here which one
  of the various alternative ContentInfo representations
  should be used? Perhaps we need just a single one,
  which would simplify implementation and analysis.

- In 6.1 you mention the signing of an encrypted
  AVP to be done through the MIME type application/
  pkcs7-mime. Is this really necessary, and doesn't
  it introduce an unnecessary temporary (and large)
  object creation? We couldn't we just state that the
  signature applies to the BER result?

- I'm wondering about the SHOULD NOT in the
  use of the PKI certs before they have been
  verified. I also see the note later in the
  doc. But nowhere you state what such other
  mechanisms might be! I really wonder why
  we need to do PKI schemes and then not use
  them... if these special cases don't need
  strong security, couldn't they live with
  hop-by-hop security?

- The protocol provides support (although as a MAY?)
  for both CRLs and OCSP. Perhaps one would be enough.
  Or maybe we should go even further and state that
  if you want online or crl functionality, you must
  provide these outside DIAMETER...

- 6.5, I think it is better to keep the OCSP-desire
  and the nonce together.

- 6.8, I think we should just drop the top CA
  since that cert must be known by the initiator
  anyway.

- Reference [4]: dash might be in the wrong place.

In conclusion I think the document looks pretty
solid, given some further clarification and profiling
work. Main concerns I have left include the delay
aspects of the ESSR/ESSA scheme for destinations that
do not need e2e, the use of this in mixed environments,
and the mandatory/optional status of the e2e extension.

Jari