Diameter Attribute-Value Pairs for Cryptographic Key Transport
draft-ietf-dime-local-keytran-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
2011-09-07
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-09-07
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-09-07
|
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-09-06
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-09-01
|
14 | (System) | IANA Action state changed to In Progress |
2011-08-31
|
14 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-08-30
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-08-30
|
14 | Cindy Morgan | IESG has approved the document |
2011-08-30
|
14 | Cindy Morgan | Closed "Approve" ballot |
2011-08-30
|
14 | Cindy Morgan | Approval announcement text regenerated |
2011-08-30
|
14 | Cindy Morgan | Ballot writeup text changed |
2011-08-19
|
14 | Stephen Farrell | [Ballot comment] |
2011-08-19
|
14 | Stephen Farrell | [Ballot discuss] Last point cleared. Thanks for |
2011-08-19
|
14 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2011-08-18
|
14 | (System) | New version available: draft-ietf-dime-local-keytran-14.txt |
2011-08-16
|
14 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2011-08-16
|
14 | Stephen Farrell | [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 … [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? |
2011-08-16
|
14 | Stephen Farrell | [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 … [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. |
2011-08-14
|
13 | (System) | New version available: draft-ietf-dime-local-keytran-13.txt |
2011-08-14
|
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-08-14
|
12 | (System) | New version available: draft-ietf-dime-local-keytran-12.txt |
2011-08-01
|
14 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Phillip Hallam-Baker. |
2011-07-14
|
14 | Cindy Morgan | Removed from agenda for telechat |
2011-07-14
|
14 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2011-07-14
|
14 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
2011-07-14
|
14 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-13
|
14 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-13
|
14 | Sean Turner | [Ballot comment] I fully support Stephen's discuss positions. |
2011-07-13
|
14 | Sean Turner | [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 - … [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. |
2011-07-13
|
14 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
2011-07-13
|
14 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-13
|
14 | Stephen Farrell | [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 … [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. |
2011-07-13
|
14 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2011-07-12
|
14 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-11
|
14 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-11
|
14 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-11
|
14 | Russ Housley | [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 … [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.) |
2011-07-11
|
14 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-11
|
14 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2011-07-11
|
14 | David Harrington | [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 … [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? |
2011-07-11
|
14 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
2011-07-10
|
14 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-06
|
14 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-06-27
|
14 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2011-06-27
|
14 | Dan Romascanu | Ballot has been issued |
2011-06-27
|
14 | Dan Romascanu | Created "Approve" ballot |
2011-06-27
|
14 | Dan Romascanu | Placed on agenda for telechat - 2011-07-14 |
2011-06-27
|
14 | Dan Romascanu | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
2011-06-17
|
11 | (System) | New version available: draft-ietf-dime-local-keytran-11.txt |
2011-06-15
|
14 | Dan Romascanu | State changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead. Authors need to address Last Call comments |
2011-06-15
|
14 | Jouni Korhonen | Submitted a while ago to IESG. |
2011-06-15
|
14 | Jouni Korhonen | IETF state changed to Submitted to IESG for Publication from WG Document |
2011-06-14
|
14 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-06-09
|
14 | Amanda Baber | 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, … 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. |
2011-05-31
|
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2011-05-31
|
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2011-05-31
|
14 | Amy Vezza | Last call sent |
2011-05-31
|
14 | Amy Vezza | 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: … 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. |
2011-05-30
|
14 | Dan Romascanu | Last Call was requested |
2011-05-30
|
14 | Dan Romascanu | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2011-05-30
|
14 | Dan Romascanu | Last Call text changed |
2011-05-30
|
14 | (System) | Ballot writeup text was added |
2011-05-30
|
14 | (System) | Last call text was added |
2011-05-30
|
14 | (System) | Ballot approval text was added |
2011-05-25
|
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-25
|
10 | (System) | New version available: draft-ietf-dime-local-keytran-10.txt |
2011-05-16
|
14 | Dan Romascanu | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-05-16
|
14 | Dan Romascanu | State changed to AD Evaluation from Publication Requested. |
2011-04-03
|
09 | (System) | New version available: draft-ietf-dime-local-keytran-09.txt |
2011-03-31
|
14 | Cindy Morgan | (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 … (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. |
2011-03-31
|
14 | Cindy Morgan | Draft added in state Publication Requested |
2011-03-31
|
14 | Cindy Morgan | [Note]: 'Lionel Morand (lionel.morand@orange-ftgroup.com) is the document shepherd.' added |
2010-10-17
|
08 | (System) | New version available: draft-ietf-dime-local-keytran-08.txt |
2010-07-01
|
07 | (System) | New version available: draft-ietf-dime-local-keytran-07.txt |
2010-05-26
|
06 | (System) | New version available: draft-ietf-dime-local-keytran-06.txt |
2010-05-25
|
05 | (System) | New version available: draft-ietf-dime-local-keytran-05.txt |
2010-05-25
|
04 | (System) | New version available: draft-ietf-dime-local-keytran-04.txt |
2010-05-01
|
03 | (System) | New version available: draft-ietf-dime-local-keytran-03.txt |
2010-03-04
|
02 | (System) | New version available: draft-ietf-dime-local-keytran-02.txt |
2010-01-28
|
01 | (System) | New version available: draft-ietf-dime-local-keytran-01.txt |
2010-01-08
|
00 | (System) | New version available: draft-ietf-dime-local-keytran-00.txt |