draft-ietf-hokey-emsk-hierarchy-06.txt | draft-ietf-hokey-emsk-hierarchy-07.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 14 | skipping to change at page 1, line 14 | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Updates: eap-keying (RFC Ed to L. Dondeti | Updates: eap-keying (RFC Ed to L. Dondeti | |||
replace this with RFC number) V. Narayanan | replace this with RFC number) V. Narayanan | |||
(if approved) Qualcomm, Inc | (if approved) Qualcomm, Inc | |||
Intended status: Standards Track M. Nakhjiri | Intended status: Standards Track M. Nakhjiri | |||
Expires: December 25, 2008 Motorola | Expires: December 25, 2008 Motorola | |||
June 23, 2008 | June 23, 2008 | |||
Specification for the Derivation of Root Keys from an Extended Master | Specification for the Derivation of Root Keys from an Extended Master | |||
Session Key (EMSK) | Session Key (EMSK) | |||
draft-ietf-hokey-emsk-hierarchy-06 | draft-ietf-hokey-emsk-hierarchy-07 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 17, line 8 | skipping to change at page 17, line 8 | |||
of different domains to employ their own experiments. Cross-domain | of different domains to employ their own experiments. Cross-domain | |||
usage is NOT RECOMMENDED. | usage is NOT RECOMMENDED. | |||
Similarly, labels "private1" and "private2" have been reserved for | Similarly, labels "private1" and "private2" have been reserved for | |||
Private Use within an organization. Again, cross-domain usage of | Private Use within an organization. Again, cross-domain usage of | |||
these labels is NOT RECOMMENDED. | these labels is NOT RECOMMENDED. | |||
Labels starting with a string and followed by the "@" and a valid, | Labels starting with a string and followed by the "@" and a valid, | |||
fully qualified Internet domain name [RFC1034] can be requested by by | fully qualified Internet domain name [RFC1034] can be requested by by | |||
the person or organization who are in control of the domain name. | the person or organization who are in control of the domain name. | |||
Such labels can be allocated based on Specification Required. It is | Such labels can be allocated based on Expert Review with | |||
RECOMMENDED that the specification contain the following information: | Specification Required. Besides the review needed for Specification | |||
Required (see Section 4.1 of [RFC5226]), the expert needs to review | ||||
the proposed usage for conformance to this specification, including | ||||
the suitability of the usage according to the applicability statement | ||||
outlined in Section 1.1. It is RECOMMENDED that the specification | ||||
contain the following information: | ||||
o A description of the usage | o A description of the usage | |||
o The key label to be used | o The key label to be used | |||
o Length of the Root Key | o Length of the Root Key | |||
o If optional data is used, what it is and how it is maintained | o If optional data is used, what it is and how it is maintained | |||
o How child keys will be derived from the Root Key and how they will | o How child keys will be derived from the Root Key and how they will | |||
be used | be used | |||
o How lifetime of the Root Key and its child keys will be managed | o How lifetime of the Root Key and its child keys will be managed | |||
o Where the Root Keys or child keys will be used and how they are | o Where the Root Keys or child keys will be used and how they are | |||
communicated if necessary | communicated if necessary | |||
End of changes. 2 change blocks. | ||||
3 lines changed or deleted | 8 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |