Subject: [Ietf-krb-wg] Typos in draft-ietf-krb-wg-otp-preauth-16

From: Linus Nordberg <[email-masked]>
Date: Fri, 29 Apr 2011 08:14:34 +0200

Hi,

This got stuck somewhere between Gareth and my mailer.  I've been asked
to send it to the list.

--8<---------------cut here---------------start------------->8---
diff -up /u/rfc/draft-ietf-krb-wg-otp-preauth-16.txt /u/rfc/draft-ietf-krb-wg-otp-preauth-16-typos.txt
--- /u/rfc/draft-ietf-krb-wg-otp-preauth-16.txt	2011-04-21 18:45:44.341193102 +0200
+++ /u/rfc/draft-ietf-krb-wg-otp-preauth-16-typos.txt	2011-04-21 18:45:22.611193102 +0200
@@ -414,7 +414,7 @@ Internet-Draft           OTP Pre-authent
    locating the OTP token to be used by identifying the purpose of the
    authentication.  For example, the otp-service field could assist a
    user in identifying the token to be used when a user has multiple OTP
-   tokens from that are used for different purposes.
+   tokens that are used for different purposes.
 
    The KDC SHALL include a sequence of one or more otp-keyInfo elements
    containing information on the token or tokens that the user can use
@@ -768,7 +768,7 @@ Internet-Draft           OTP Pre-authent
    PIN value.  The KDC MAY also include the new PIN's expiration time
    and the expiration time of the OTP account within the last-req field
    of the PA-OTP-PIN-CHANGE.  (These fields can be used by the KDC to
-   handle cases where then account related to the user's OTP token has a
+   handle cases where the account related to the user's OTP token has a
    different expiration time to the user's Kerberos account.)  If the
    KDC determines that the user's PIN or OTP account are about to
    expire, it MAY return a PA-OTP-PIN-CHANGE with that information.
@@ -844,10 +844,10 @@ Internet-Draft           OTP Pre-authent
       {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
       {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}
 
-   The first input keys, K1, SHALL be the Armor Key and so, as described
+   The first input key, K1, SHALL be the Armor Key and so, as described
    in section 5.1 of [ZhHa10], the enctypes of the generated Client Key
    and Reply Key will be the same as the enctype of Armor Key. The
-   second input key, K2, shall be derived from the OTP value using
+   second input key, K2, SHALL be derived from the OTP value using
    string-to-key (defined in [RFC3961]) as follows.
 
    If the hash of the OTP value is to be used then K2 SHALL be derived
@@ -1025,7 +1025,7 @@ Internet-Draft           OTP Pre-authent
          set then there MUST only be a single otp-keyInfo element in the
          PA-OTP-CHALLENGE.
 
-         The "combine flag controls how the challenge included in otp-
+         The "combine" flag controls how the challenge included in otp-
          challenge shall be used.  If the flag is set then OTP SHALL be
          calculated using the challenge from otp-challenge and the
          internal token state (e.g. time or counter).  If the "combine"
@@ -1237,7 +1237,7 @@ Internet-Draft           OTP Pre-authent
       This field MUST be present if and only if a hash of the OTP value
       was used as input to string-to-key (see Section 3.6) and MUST
       contain nonce value generated by the client and used in the
-      generation of hashed OTP values as described in Section 3.6 .
+      generation of hashed OTP values as described in Section 3.6.
       This nonce string MUST be as long as the longest key length of the
       symmetric key types that the client supports and MUST be chosen
       randomly.
@@ -1333,7 +1333,7 @@ Internet-Draft           OTP Pre-authent
    otp-vendor
       If the PA-OTP-REQUEST is being sent in response to a PA-OTP-
       CHALLENGE that contained an otp-vendor field in the selected otp-
-      keyInfo then this field MUST be set to the same value otherwise,
+      keyInfo then this field MUST be set to the same value, otherwise
       this filed SHOULD be set to the vendor identifier of the token if
       known to the client.  It is RECOMMENDED that the KDC act upon this
       value if it is present in the request and it is capable of using
@@ -1630,7 +1630,7 @@ Internet-Draft           OTP Pre-authent
    Many valuable suggestions were also made by members of the Kerberos
    Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman,
    Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak and
-   Simon Jofesson.
+   Simon Josefsson.
 
    I would also like to thank Tim Alsop and Srinivas Cheruku of
    CyberSafe for many valuable review comments.
--8<---------------cut here---------------end--------------->8---
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg