idnits 2.17.1 draft-ietf-krb-wg-cammac-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 9, 2012) is 4457 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X680' is mentioned on line 121, but not defined -- Looks like a reference, but probably isn't: '0' on line 135 -- Looks like a reference, but probably isn't: '1' on line 136 -- Looks like a reference, but probably isn't: '2' on line 129 -- Looks like a reference, but probably isn't: '3' on line 130 -- Looks like a reference, but probably isn't: '4' on line 131 == Unused Reference: 'RFC3961' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'RFC3962' is defined on line 200, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 221, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Sorce, Ed. 3 Internet-Draft Red Hat 4 Intended status: Standards Track T. Yu, Ed. 5 Expires: August 12, 2012 T. Hardjono, Ed. 6 MIT Kerberos Consortium 7 Feb 9, 2012 9 Container Authenticated by Multiple MACs 10 draft-ietf-krb-wg-cammac-01 12 Abstract 14 Abstract: This document proposes a Kerberos Authorization Data 15 container similar to AD-KDC-ISSUED, but that allows for multiple MACs 16 or signatures on the contained Authorization Data elements. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 12, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 54 3. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. AD-CAMMAC . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Assigned numbers . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 This draft proposes a Authorization Data container for Kerberos that 70 identifies a base set of MAC and other elements necessary to 71 authenticate the authorization data being carried in such a way that 72 not only the KDC but also services can independently verify that the 73 data has been authenticated by the KDC and has not been tampered 74 with. 76 2. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 3. Validation 84 Authorization data is highly sensitive and must be validated to 85 insure no tampering has occured. 87 In order to validate any information the receiving client need to be 88 able to cryptographically verify the data. This is done by 89 introducing a new AuthorizationData element called AD-CAMMAC that 90 contains enough information to bind the contents to a principal in a 91 way that a receiving client can verify autonomusly without further 92 contact with the KDC. 94 The following information is needed: 96 o The KDC signature. 98 o The Service Signature. 100 o Optional Trusted Service Key Signature. 102 o Optional PUBKEY KDC Signature. 104 The KDC signature is required to allow the KDC to validate the data 105 withouth requiring to recompute the contents at every TGS request. 107 The SVC signature is required so that the Service can verify that the 108 authorization data has been validated by the KDC. 110 Both the Trusted Service Checksum and the asymmetric KDC Signature 111 are useful to verify the authenticity of the contents on the same 112 host, when the data is received by a less trusted service and passed 113 to a more trusted service on the same host without the need for 114 additional roundtrips to the KDC. 116 The ad-type for AD-CAMMAC is (TBD). 118 4. Encoding 120 The Kerberos protocol is defined in [RFC4120] using Abstract Syntax 121 Notation One (ASN.1) [X680]. As such, this specification also uses 122 the ASN.1 syntax for specifying both the abstract layout of the AD- 123 CAMMAC attributes, as well as its encoding. 125 4.1. AD-CAMMAC 126 AD-CAMMAC ::= SEQUENCE { 127 kdc-signature [0] Checksum, 128 svc-signature [1] Checksum, 129 trusted-svc-signature [2] OPT-Checksum OPTIONAL, 130 pubkey-signature [3] TBD OPTIONAL, 131 elements [4] AuthorizationData 132 } 134 OPT-Checksum ::= SEQUENCE { 135 identifier [0] PrincipalName, 136 signature [1] Checksum 137 } 139 kdc-signature 140 A cryptographic checksum computed over the encoding of the 141 elements field, keyed with the krbtgt key. 142 Checksum type TBD. 144 svc-signature 145 A cryptographic checksum computed over the encoding of the 146 elements field, keyed with the service long term key. 147 Checksum type TBD. 149 trusted-svc-signature 150 A principal name and a cryptographic checksum computed over the 151 encoding of the elements field, keyed with the long term key of 152 the principal name specified in the Name field. Unless otherwise 153 explicitly administratively configured, the key SHOULD be found 154 by substituting the service name component of the principal name 155 of the service with 'host'. 156 If the service is 'host' this checksum is redundant and can be 157 omitted. 158 If the resulting host/@REALM or the administratively 159 configured service is not found in the KDC database this 160 cheksum can be omitted. 161 Checksum type TBD. 163 pubkey-signature 164 A name identifying the asymmetric key-pair used. 165 A checksum computed over the encoding of the elements field using 166 the Private Key identified in the Name field. 167 If an asymmetric key is not available this checksum MUST be 168 omitted. 169 Signature type TBD. 171 elements 172 A sequence of authorization data elements issued by the KDC. 174 5. Assigned numbers 176 TBD 178 6. IANA Considerations 180 TBD. 182 7. Security Considerations 184 Although generally authorization data are conveyed within a ticket 185 and are thereby protected using the existing encryption methods on 186 the ticket, some authorization data requires the additional 187 protection provided by the CAMMAC. 189 8. Acknowledgements 191 TBD. 193 9. References 195 9.1. Normative References 197 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 198 Kerberos 5", RFC 3961, February 2005. 200 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 201 Encryption for Kerberos 5", RFC 3962, February 2005. 203 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 204 Kerberos Network Authentication Service (V5)", RFC 4120, 205 July 2005. 207 9.2. Informative References 209 [MIT-Athena] 210 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 211 Authentication Service for Open Network Systems. In 212 Proceedings of the Winter 1988 Usenix Conference. 213 February.", 1988. 215 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 216 Authentication Service (V5)", RFC 1510, September 1993. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 222 Text on Security Considerations", BCP 72, RFC 3552, 223 July 2003. 225 [X.690] ISO, "ASN.1 encoding rules: Specification of Basic 226 Encoding Rules (BER), Canonical Encoding Rules (CER) and 227 Distinguished Encoding Rules (DER) - ITU-T Recommendation 228 X.690 (ISO/IEC International Standard 8825-1:1998)", 1997. 230 Appendix A. Additional Stuff 232 This becomes an Appendix. 234 Authors' Addresses 236 Simo Sorce (editor) 237 Red Hat 239 Email: ssorce@redhat.com 241 Tom Yu (editor) 242 MIT Kerberos Consortium 244 Email: tlyu@mit.edu 246 Thomas Hardjono (editor) 247 MIT Kerberos Consortium 249 Email: hardjono@mit.edu