Diameter Attribute-Value Pairs for Cryptographic Key Transport
draft-ietf-dime-local-keytran-14

[Ballot comment]
I've cleared points 1 & 2 since the RSA key type is now gone (a pity,
but I understand why, and hope it comes back in another form soon);
my 2nd point was me getting it wrong, (other specifications use
this and handle MTI rather than this one),

--- original discuss text below ---

(1) I'm not sure that the Key-Type AVP is well enough specified.  At least
for the RSA-KEM variant, I would have expected to see a set of CMS options
(e.g. are certs to be included or not) would be needed in order to get
interop. (I was offine doing the review and am not familiar enough with
the other options to know if the same issue arises.) Have there been any
implementations of these, and if so, what did they put in the key values?
I also don't get why the RFCs defining the details for Key-Type AVPs
are informative and not normative. If this document defines a protocol
that will result in interop, then they need to be normative I'd have
thought.

(2) Which of the Key-Type(s) are implementers of this expected
to support?

[Ballot discuss]
I've cleared points 1 & 2 (see the comment)

Point 3 remains. I suggested some better text on July 15th but didn't
see any response to that. (Sorry if I missed it.)

(3) The security considerations need to say something about transporting
keys that are not otherwise protected. I think you need to say that
Keying-Material AVPs that are not suitable to be sent in clear MUST
only be sent between two Diameter nodes using TLS or IPsec unless
all the Diameter nodes on a path are known to be equally trusted.
I'm sure wordsmithing is needed there but don't have time right now
to offer a suggestion. (Sorry) Neither of the RFCs referenced in the
security considerations section say that. I've no idea how far that might
be from the WG's opinion.

[Ballot discuss]
I gotta ask about the choice of RSA-KEM.  I couldn't find email on the list about it.  Why not straight up RSA - for which almost everybody on the planet who has a certificate has one where few (any?) have RSA-KEM certificates?  If it's just list algs why not also add RSAES-OAEP Key Transport Algorithm [RFC4055]?  Maybe ECDH too? I'm just curious if somebody asked for RSA-KEM or you just picked a second one for agility purposes.

[Ballot discuss]
(1) I'm not sure that the Key-Type AVP is well enough specified.  At least
for the RSA-KEM variant, I would have expected to see a set of CMS options
(e.g. are certs to be included or not) would be needed in order to get
interop. (I was offine doing the review and am not familiar enough with
the other options to know if the same issue arises.) Have there been any
implementations of these, and if so, what did they put in the key values?
I also don't get why the RFCs defining the details for Key-Type AVPs
are informative and not normative. If this document defines a protocol
that will result in interop, then they need to be normative I'd have
thought.

(2) Which of the Key-Type(s) are implementers of this expected
to support?

(3) The security considerations need to say something about transporting
keys that are not otherwise protected. I think you need to say that
Keying-Material AVPs that are not suitable to be sent in clear MUST
only be sent between two Diameter nodes using TLS or IPsec unless
all the Diameter nodes on a path are known to be equally trusted.
I'm sure wordsmithing is needed there but don't have time right now
to offer a suggestion. (Sorry) Neither of the RFCs referenced in the
security considerations section say that. I've no idea how far that might
be from the WG's opinion.

[Ballot comment]
The Gen-ART Review by Joel Halpern on 2-Jun-2011 asks a reasonable
  question.  I would like to see it answered.

  The document carefully and reasonably does not define the contents of
  the keying material AVP.  This reviewer presumes that those closer to
  the activity will know where the contents have been or will be
  defined.  Are they already defined, or will they be defined in future
  documents?  If they are already defined, would it make sense to state
  that, and identify the location?  (My confusion is that it would seem
  difficult for existing RFCs to define the format of a TLV that did not
  exist.  But that may be a failure of my understanding.)

[Ballot discuss]
Despite the fact that this AVP is used to distribute keys, no discussion of securty considerations beyond those of the base diameter protocol are mentioned. Aren't there security considerations related to somehow intercepting key material? If not, why not?

IANA understands that, upon approval of this document, there are two
actions which must be completed.

First, in the AVP Codes registry in the Authentication, Authorization,
and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

Six new AVP Codes are to be registered as follows:

AVP Code: < tbd >
Description: Key
Reference: [ RFC-to-be ]

AVP Code: < tbd >
Description: Key-Type
Reference: [ RFC-to-be ]

AVP Code: < tbd >
Description: Keying-Material
Reference: [ RFC-to-be ]

AVP Code: < tbd >
Description: Key-Lifetime
Reference: [ RFC-to-be ]

AVP Code: < tbd >
Description: Key-SPI
Reference: [ RFC-to-be ]

AVP Code: < tbd >
Description: Key-Name
Reference: [ RFC-to-be ]

Second, a new AVP Specific Value registry will be created for the AVP
Code "Key-Type" above. The new registry is to be maintained using
Specification Required policy from RFC 5226. There are initial values
for the new registry:

AVP Value Attribute Name Reference
--------- ---------------------------------------------- -----------
MSK (0) The EAP Master Session Key [RFC3748]
DSRK (1) A Domain-Specific Root Key [RFC5295]
rRK (2) A reauthentication Root Key [RFC5296]
rMSK (3) A reauthentication Master Session Key [RFC5296]
RSA-KEM (4) A symmetric key encrypted using the RSA public
key of the recipient [RFC5990]

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter Attribute-Value Pairs for Cryptographic Key Transport) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Attribute-Value Pairs for Cryptographic Key Transport'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Some Authentication, Authorization, and Accounting (AAA) applications
  require the transport of cryptographic keying material.  This
  document specifies a set of Attribute-Value Pairs (AVPs) providing
  native Diameter support of cryptographic key delivery.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-local-keytran/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-local-keytran/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the

Document Shepherd personally reviewed this version of the

document and, in particular, does he or she believe this

version is ready for forwarding to the IESG for publication?



--

Lionel Morand (lionel.morand@orange-ftgroup.com)

is the Document Shepherd, Dime co-chair. He has done a review

on the document and believes it is ready to be forwarded to

IESG for publication.



(1.b) Has the document had adequate review both from key WG members

and from key non-WG members? Does the Document Shepherd have

any concerns about the depth or breadth of the reviews that

have been performed?



--

The document has had an extensive review by the DIME WG and

the lastest version is the result of the consensus reached

after discussion.



The shepherd has reviewed the document himself and has no

issue with it. Nor the shepherd has issues with the reviews

done by others.



(1.c) Does the Document Shepherd have concerns that the document

needs more review from a particular or broader perspective,

e.g., security, operational complexity, someone familiar with

AAA, internationalization or XML?



--

No.





(1.d) Does the Document Shepherd have any specific concerns or

issues with this document that the Responsible Area Director

and/or the IESG should be aware of? For example, perhaps he

or she is uncomfortable with certain parts of the document, or

has concerns whether there really is a need for it. In any

event, if the WG has discussed those issues and has indicated

that it still wishes to advance the document, detail those

concerns here. Has an IPR disclosure related to this document

been filed? If so, please include a reference to the

disclosure and summarize the WG discussion and conclusion on

this issue.



--

No.





(1.e) How solid is the WG consensus behind this document? Does it

represent the strong concurrence of a few individuals, with

others being silent, or does the WG as a whole understand and

agree with it?



--

There is Dime WG consensus behind the document.





(1.f) Has anyone threatened an appeal or otherwise indicated extreme

discontent? If so, please summarise the areas of conflict in

separate email messages to the Responsible Area Director. (It

should be in a separate email because this questionnaire is

entered into the ID Tracker.)



--

No.



(1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits? (See the Internet-Drafts
Checklist

and http://tools.ietf.org/tools/idnits/). Boilerplate checks are


not enough; this check needs to be thorough. Has the document

met all formal review criteria it needs to, such as the MIB

Doctor, media type and URI type reviews?



--

The shepherd has checked the document with the idnits tool and

found no issues. The document does not need MIB doctor review.

The document does not contain any media and URI types.



(1.h) Has the document split its references into normative and

informative? Are there normative references to documents that

are not ready for advancement or are otherwise in an unclear

state? If such normative references exist, what is the

strategy for their completion? Are there normative references

that are downward references, as described in [RFC3967]? If

so, list these downward references to support the Area

Director in the Last Call procedure for them [RFC3967].



--

References are split accordingly. There is a normative
reference

to a draft (draft-ietf-dime-rfc3588bis) but this draft should
be

published soon. There are no other references to documents with


unclear status or are in progress.



(1.i) Has the Document Shepherd verified that the document IANA

consideration section exists and is consistent with the body

of the document? If the document specifies protocol

extensions, are reservations requested in appropriate IANA

registries? Are the IANA registries clearly identified? If

the document creates a new registry, does it define the

proposed initial contents of the registry and an allocation

procedure for future registrations? Does it suggest a

reasonable name for the new registry? See [RFC5226]. If the

document describes an Expert Review process has Shepherd

conferred with the Responsible Area Director so that the IESG

can appoint the needed Expert during the IESG Evaluation?



--

This document defines 6 new Diameter AVP codes and requests
IANA for

code value assignment in an existing registry.



This document defines also a new IANA registry for values
assigned

to one of the newly defined AVP (Key-Type AVP). Allocation of
new

values is decided after expert review and the sheperd discussed
this

point with Dan Romascanu, AD of the OPS AREA.





(1.j) Has the Document Shepherd verified that sections of the

document that are written in a formal language, such as XML

code, BNF rules, MIB definitions, etc., validate correctly in

an automated checker?



--

Yes. Note that the ABNF used in this document follows the

modified ABNF syntax defined in RFC3588.





(1.k) The IESG approval announcement includes a Document

Announcement Write-Up. Please provide such a Document

Announcement Write-Up? Recent examples can be found in the

"Action" announcements for approved documents. The approval

announcement contains the following sections:



Technical Summary



--



This document specifies a set of AVPs allowing the transport of


multiple cryptographic keys in a single Diameter message. Such

capability is required by several AAA applications.





Working Group Summary



---

The document was discussed for more than one year in the WG and


the document captures the results of the collaborative WG work.



Document Quality



---

The document is complete, straightforward, simple and
well-written.