Subject: [AAA-WG]: draft-ietf-aaa-diameter-cms-sec-04 (fwd)

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 May 2002 07:39:18 -0700 (PDT)

---------- Forwarded message ----------
Date: Wed, 15 May 2002 08:49:10 -0400
From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: draft-ietf-aaa-diameter-cms-sec-04

Dear Authors:

I have just finished going through draft-ietf-aaa-diameter-cms-sec-04, and 
I have a few questions and comments.

1.  On page 4, the terms MUST, SHOULD, and MAY are used before the 
requirements language explanation.  I suggest that section 1.1 be moved up 
two paragraphs, and that those two paragraphs become section 1.2.  Of 
course, you then need to renumber the subsequent subsections.

2.  On page 6, in the paragraph right after figure 2, you say:

    This document defines the Diameter commands that are used to
    establish a DSA through Diameter agents, and specifies how
    encapsulating CMS objects [CMS] in Diameter AVPs can provide
    authentication, integrity, confidentiality and data origin
    authentication. CMS objects MAY also be used to transport X.509
    certificates and revocation lists.

What is the difference between "authentication" and "data origin 
authentication?"  Should I interpret "authentication" as peer entity 
authentication?

3. On page 7, you say:

    ...  In the latter case, the proxy agent acts as
    an access device of sorts and the rules in section 1.2 should be used
    instead.

Instead of what?  Can we drop the word?

4.  On page 12, in the 3rd paragraph of section 3.1, you say:

    Revalidations SHOULD also occur before the DSA expires according to
    PKI policies. During the process of certificate path validation some
    implementations will calculate a duration for which the certificate
    path may be considered "safe". For example, ...

Please change "certificate path" to "certification path."  This is the term 
used in RFC 2459 and RFC 3280.  Please ensure that the correct term is used 
throughout the document.

5.  On page 13, in the 3rd bullet in the middle of the page, you say:

        - the list of direct trust CA's that the originating Diameter
          node has configured into it for certificate validation.  A
          "direct trust" CA is one that the node is willing to use as the
          "top" of a certificate chain, sometimes confusingly known as a
          "root CA."

Please use the term "trust anchor" instead of "direct trust CA."  Trust 
anchor is defined in RFC 3280.

6.  On page 15, in the 5th paragraph from the top of the page, please add 
"checking" after "If certificate revocation."

7. On page 17, at the end of section 3.3, please add:

    Implementations MAY support other algorithms.

8.  On page 22, in the 1st paragraph of section 6.0, you say:

    This section contains AVPs that are used to establish a Diameter
    Security Association, and to transport CMS objects. Except as
    specifically constrained, the profile of CMS algorithm and structure
    usage is as specified in the S/MIME v3 message specification [MSG].

I have two comments.  First, CMS is not an "algorithm."  I suggest "... of 
the CMS is specified ..."  Second, I am confused about the reference to 
[MSG].  You use very little that is defined there.  You use different 
algorithms.  You do not use the MIME encoding.  Why reference it at 
all?  The only place that it seems relevant is in the discussion of 
certs-only messages.

9. On page 23, after the table, there is another use of "CMS algorithm." 
Please fix it too.

10.  On page 23, after the table, there is further discussion of 
[MSG].  Basically, the two paragraphs after the table are saying that [MSG] 
is irrelevant.

11.  On page 24, in the 1st full paragraph on the page, please change 
"sequentially" to either "subsequently" or "serially."

12.  On page 24, 2nd to last paragraph in section  6.1, please add (at the 
end):

    The ciphertext is signed.

13.  On page 24, last paragraph on the page, you say:

         The contentType of the EncryptedContentInfo value MUST be id-
         data [MSG].

Please do not do this!  The IESG complained about id-data, and the 
following text was added to the update to RFC 2630 (rfc2630bis) to address 
the complaint:

    S/MIME uses id-data to identify MIME encoded content.  The use of
    this content identifier is specified in RFC 2311 for S/MIME v2
    [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].

Since you are not MIME encoding your content, please do not use id-data.  I 
will be glad to assign you a new OID for Diameter AVPs.

14.  On page 26, section 6.4.2, you define an AVP that is the SHA-1 hash of 
the public key.  I similar construct is defined in 
draft-ietf-pkix-okid-01.txt.  Can we harmonize these specifications?

15. On page 27, in the 1st paragraph of section 6.8, the discussion of the 
certs-only message should reference [MSG].  Best I can tell, this is the 
only aspect of [MSG] that is being use in the specification, and it is 
being used without the MIME wrapper (I think).  You should be explicit 
about whether the MIME wrapper is being used.

16.  On page 32, in the last paragraph of section 10.0, please change "SA" 
to "DSA."

17.  On page 32, section 10.0, should discuss replay detection.

18.  Please reference rfc2630bis and cmsalg documents instead of 
[CMS].  These two documents from the S/MIME working group have finished 
IETF Last Call, and I think that the last IESG DISCUSS vote was cleared 
yesterday.

19.  Please change [CERTPROF] to reference RFC 3279 and RFC 3280.  Note 
that some places [CERTPROF] is used in reference to algorithms, and these 
should reference RFC 3279.  One example is at the top of page 
27.  Other  places, [CERTPROF] is used in reference to certificates, and 
these should reference RFC 3280.

Thanks for you attention.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 May 2002 09:54:49 +0100

Hi Russ,

> I have a few questions and comments.

Thanks for these, you've certainly found some of our legacy text:-)

Bernard - As far as I can tell only Russ' #13 needs to be raised as an open
"issue". (#5,#7 might lead to discussion, but I hope not).

For the rest, if you raise a single new issue for the lot and immediately mark 
it closed, I think that'd be right (maybe wait a day to see if Russ detects 
any problems first).

Cheers,
Stephen.

> course, you then need to renumber the subsequent subsections.

OK.

> authentication?"  Should I interpret "authentication" as peer entity

Yes, so long as you're not too strict in your interpretation!
(This arose because I did an s/N-R/D-A-O/g to avoid the yukkie term:-) 

Best is to tidy this up to:
   [...]
   encapsulating CMS objects [CMS] in Diameter AVPs can provide
   integrity, confidentiality and data origin
   authentication. CMS objects MAY also be used to transport X.509
   [...]

> Instead of what?  Can we drop the word?

OK.

> used in RFC 2459 and RFC 3280.  Please ensure that the correct term is used

OK.

> anchor is defined in RFC 3280.

I personally don't think that these have to be identical settings, but it 
could be simpler if we pretend they are! (They look the same externally.)

The use case where they're not is where a corporate Diameter node has the
corporate CA as its trust anchor, and where the corporate CA has certified
a bunch of other CAs which are known to the outside world (e.g. cybertrust). 
That node would then be better off advertising the fact that if you can chain 
up to one of the other CAs, then you're in business. Advertising only the 
corporate CA would probably result in many outside Diameter nodes not being 
able to form a chain up to the advertised CA.

How about if I use the "trust anchor" term, but also include text like
the above? (Which BTW ought also go into TLS, SMIME capabilities and anywhere 
else network elements advertise their set of favorite CAs?)

> "checking" after "If certificate revocation."

OK.

>     Implementations MAY support other algorithms.

Why? There is no statement that they "MAY NOT" support other algorithms and
since I don't want to run into ECDSA, Camelia, GOST or any of the other raft 
of algorithms that exist, why encourage complication? (The background is that
a number of Diameter folks have already baulked at the apparent complexity of 
CMS and I don't want them to have to think about other algorithms for now.)

Basically I think we're ok to just pick good algorithms here since its not
a framework - if we get demand for other algorithms, then we can write a new
rfc.

> the CMS is specified ..."  

Fine.

> Second, I am confused about the reference to

Yes. This is historical, we started out using the MIME encoding and
then dropped it. Will tidy appropriately, depending on id-data issue (#13).

> 9. On page 23, after the table, there is another use of "CMS algorithm."

OK.

> [MSG].  Basically, the two paragraphs after the table are saying that [MSG]

OK.

> "sequentially" to either "subsequently" or "serially."

OK.

>     The ciphertext is signed.

OK.

> will be glad to assign you a new OID for Diameter AVPs.

Ark! I need to check/think about this - basically, will existing toolkits
barf on a new OID? If they do, then we're not (IMO) doing a very good job.
Is there any generic "non-MIME encoded binary content" OID that's already
supported?

Bernard, you ought to open an "issue" about this, at least 'till I check.

> draft-ietf-pkix-okid-01.txt.  Can we harmonize these specifications?

In principle yes, but practically, probably not. We want this to progress 
quicker than (I think) okid will. The uses also differ - okid is mainly for 
human consumption, isn't it? This AVP isn't for warm bodies.

> about whether the MIME wrapper is being used.

More history. Will change so as to make you happy.

> 16.  On page 32, in the last paragraph of section 10.0, please change "SA"

OK
 
> 17.  On page 32, section 10.0, should discuss replay detection.

Yes.

> IETF Last Call, and I think that the last IESG DISCUSS vote was cleared

OK, assuming 2630-compliant code remains complaint (which I think it does
for the bits we're using), but with the caveat that we'll drop back to 
2630 if this draft gets to the authors 48 hour mark first.

> these should reference RFC 3280.

OK. (I might even re-insert an informative reference to the now-rfc3281, just 
to celebrate its eventual emergence from the pkix/iesg/rfc-editor process:-)

> Thanks for you attention.
And thanks for yours!

-- 
____________________________________________________________
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: "Housley, Russ" <[email-masked]>
Date: Thu, 16 May 2002 09:42:02 -0400

Steve:

Most of these are fine.  Below, I have not included comments that are 
closed.  I have included ones that have open issues or you asked me a question.

OK.

OK.

>Is there any generic "non-MIME encoded binary content" OID that's already

As I understand it, most toolkits just return the OID, leaving 
demultipexing to the calling application.

>Bernard, you ought to open an "issue" about this, at least 'till I check.

Why don't you post a question to [email-masked] to confirm my 
understanding.

OK.

OK.

>to celebrate its eventual emergence from the pkix/iesg/rfc-editor process:-)

Yes, the process is not an infinite loop.  It just feels that way sometimes...

Russ