draft-ietf-kitten-krb-spake-preauth-08.txt   draft-ietf-kitten-krb-spake-preauth-09.txt 
Internet Engineering Task Force N. McCallum Internet Engineering Task Force N. McCallum
Internet-Draft S. Sorce Internet-Draft S. Sorce
Intended status: Standards Track R. Harwood Intended status: Standards Track R. Harwood
Expires: November 22, 2020 Red Hat, Inc. Expires: December 12, 2020 Red Hat, Inc.
G. Hudson G. Hudson
MIT MIT
May 21, 2020 June 10, 2020
SPAKE Pre-Authentication SPAKE Pre-Authentication
draft-ietf-kitten-krb-spake-preauth-08 draft-ietf-kitten-krb-spake-preauth-09
Abstract Abstract
This document defines a new pre-authentication mechanism for the This document defines a new pre-authentication mechanism for the
Kerberos protocol that uses a password authenticated key exchange. Kerberos protocol that uses a password authenticated key exchange.
This document has three goals. First, increase the security of This document has three goals. First, increase the security of
Kerberos pre-authentication exchanges by making offline brute-force Kerberos pre-authentication exchanges by making offline brute-force
attacks infeasible. Second, enable the use of second factor attacks infeasible. Second, enable the use of second factor
authentication without relying on FAST. This is achieved using the authentication without the need for a separately-established secure
existing trust relationship established by the shared first factor. channel. This is achieved using the existing trust relationship
Third, make Kerberos pre-authentication more resilient against time established by the shared first factor. Third, make Kerberos pre-
synchronization errors by removing the need to transfer an encrypted authentication more resilient against time synchronization errors by
timestamp from the client. removing the need to transfer an encrypted timestamp from the client.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2020. This Internet-Draft will expire on December 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10.7. Denial of Service Attacks . . . . . . . . . . . . . . . 18 10.7. Denial of Service Attacks . . . . . . . . . . . . . . . 18
10.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . 18 10.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . 18
10.9. Reply-Key Encryption Type . . . . . . . . . . . . . . . 19 10.9. Reply-Key Encryption Type . . . . . . . . . . . . . . . 19
10.10. KDC Authentication . . . . . . . . . . . . . . . . . . . 19 10.10. KDC Authentication . . . . . . . . . . . . . . . . . . . 19
11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 19 11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 20 12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 20
12.1.1. Registration Template . . . . . . . . . . . . . . . 20 12.1.1. Registration Template . . . . . . . . . . . . . . . 20
12.1.2. Initial Registry Contents . . . . . . . . . . . . . 20 12.1.2. Initial Registry Contents . . . . . . . . . . . . . 20
12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 20 12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 20
12.2.1. Registration Template . . . . . . . . . . . . . . . 20 12.2.1. Registration Template . . . . . . . . . . . . . . . 21
12.2.2. Initial Registry Contents . . . . . . . . . . . . . 21 12.2.2. Initial Registry Contents . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25
Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 26 Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 26
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 27
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC
skipping to change at page 19, line 50 skipping to change at page 19, line 50
This document establishes two registries with the following This document establishes two registries with the following
procedure, in accordance with [RFC8126]: procedure, in accordance with [RFC8126]:
Registry entries are to be evaluated using the Specification Required Registry entries are to be evaluated using the Specification Required
method. All specifications must be be published prior to entry method. All specifications must be be published prior to entry
inclusion in the registry. Once published, they can be submitted inclusion in the registry. Once published, they can be submitted
directly to the krb5-spake-review@ietf.org mailing list, where there directly to the krb5-spake-review@ietf.org mailing list, where there
will be a three-week long review period by Designated Experts. will be a three-week long review period by Designated Experts.
The Designated Experts ensure that the specification is publicly
available. It is sufficient to have an Internet-Draft (that is
posted and never published as an RFC) or a document from another
standards body, industry consortium, university site, etc. The
Designated Experts may provide additional in-depth reviews, but their
approval should not be taken as endorsement of the specification.
Prior to the end of the review period, the Designated Experts must Prior to the end of the review period, the Designated Experts must
approve or deny the request. This decision is conveyed to both IANA approve or deny the request. This decision is conveyed to both IANA
and the submitter. Since the mailing list archives are not public, and the submitter. Since the mailing list archives are not public,
it should include both a reasonably detailed explanation in the case it should include both a reasonably detailed explanation in the case
of a denial as well as whether the request can be resubmitted. of a denial as well as whether the request can be resubmitted.
IANA MUST only accept registry updates from the designated experts
and SHOULD direct all requests for registration to the review mailing
list.
12.1. Kerberos Second Factor Types 12.1. Kerberos Second Factor Types
This section species the IANA "Kerberos Second Factor Types" This section species the IANA "Kerberos Second Factor Types"
registry. This registry records the number, name, and reference for registry. This registry records the number, name, and reference for
each second factor protocol. each second factor protocol.
12.1.1. Registration Template 12.1.1. Registration Template
ID Number: This is a value that uniquely identifies this entry. It ID Number: This is a value that uniquely identifies this entry. It
is a signed integer in range -2147483648 to 2147483647, inclusive. is a signed integer in range -2147483648 to 2147483647, inclusive.
 End of changes. 9 change blocks. 
11 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/