Subject: [Ietf-krb-wg] String normalization in draft-ietf-krb-wg-otp-preauth

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Oct 2011 13:13:34 -0400

Folks, these issues will probably require discussion at IETF 82.  I hope
that we can have list discussion that gets us most of the way, but it
sounds like the IESG really wants us to actually go into detail about
how these strings are used, which probably means actually specifying a
bit more client behavior.

Subject: Topics

Topics:
   Pete Resnick's Discuss on draft-ietf-krb-wg-otp-preauth-19: (with  DISCUSS)
   Peter Saint-Andre's Discuss on draft-ietf-krb-wg-otp-preauth-19:  (with DISCUSS and COMMENT)

Subject: Pete Resnick's Discuss on draft-ietf-krb-wg-otp-preauth-19: (with DISCUSS)
From: Pete Resnick <[email-masked]>
To: The IESG <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 05 Oct 2011 15:52:39 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-krb-wg-otp-preauth-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Peter's analysis in the end regarding otp-service and otp-vendor: These items are not used in any comparison, and therefore there should not be any mention of their case-sensitivity (or lack thereof) or their comparison.

On the PIN however, you have a real problem. This appears to be a UTF-8 string taken from user input and then used in the security token. Unicode strings taken from user input have all sorts of interesting issues depending on the kinds of normalization used by the input method. In the best circumstances, this means a bunch of false negatives when comparing. In the worst circumstances, there could be some interesting false positives. I don't know if it's the place of this document to discuss all of this, but there at *least* needs to be some comment in the security considerations section if this is going to be a UTF-8 string.

Subject: Peter Saint-Andre's Discuss on draft-ietf-krb-wg-otp-preauth-19: (with DISCUSS and COMMENT)
From: Peter Saint-Andre <[email-masked]>
To: The IESG <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 05 Oct 2011 12:02:55 -0700

Peter Saint-Andre has entered the following ballot position for
draft-ietf-krb-wg-otp-preauth-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document appears to nicely extend RFC 6113 and RFC 4120.

There is one point I would like to chat about.

I think we need to say a bit more about string comparison of elements
that are of type UTF8String. Section 3.3 says:

   Any string comparison operations carried
   out against the values of otp-service and otp-vendor MUST be case
   sentive.

First, see draft-iab-identifier-comparison-00 for an extensive
discussion of security issues related to comparison of identifiers.

Second, it is not clear if the otp-service and otp-vendor elements are
in fact subject to automated string comparison in the client.  For
example, Section 3.2 states:

   The KDC MAY use the otp-service field to assist the client in
   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 that are used for different purposes.

and:

   The KDC MAY include the otp-vendor field in an otp-tokenInfo to
   identify the vendor of the token that can be used in the
   authentication request in order to assist the client in locating that
   token.

Furthermore, Section 3.3 states:

   The otp-service, otp-vendor, otp-tokenID, otp-length and otp-algID
   elements of the PA-OTP-CHALLENGE are provided by the KDC to assist
   the client in locating the correct token to use but the use of the
   above fields will depend on the type of token.  If connected tokens
   are used then these values SHOULD be used by the client to locate the
   correct token if connected and otp-vendor and otp-service MAY also be
   displayed to prompt the user if the correct token is not found.  If
   the token is not a connected token, then the values of otp-service
   and otp-vendor MAY be displayed to the user in order to help the user
   select the correct token and the values of otp-algID, otp-tokenID and
   otp-length MAY be ignored.  Any string comparison operations carried
   out against the values of otp-service and otp-vendor MUST be case
   sentive.

And Appendix B.1 states:

   6.   The client displays the value of otp-service and prompts the
           user to connect the token.

So it seems that the otp-service and otp-vendor elements are shown to
the user for visual comparison, not compared within the client in an
automated fashion.

If that is so, then we might be able to remove the sentence about string
comparison, but we will want to add some stern warnings about the
hazards of visual comparison, such as the following text from
draft-iab-identifier-comparison...

   Some strings are visually confusable with others, and hence if a
   security decision is made by a user based on visual inspection, many
   opportunities for false positives exist.  As such, highly secure
   systems should not rely on visual inspection.

If that is not so and the otp-service and otp-vendor elements are indeed
compared in an automated way within the client, we will need to say more
than merely "compare in a case-sensitive manner" (see RFC 5895 for some
related considerations) and Pete Resnick and I will probably want to
confer about recommended text.

Finally, given that the PIN element is also of type UTF8String, it would
be good to clarify whether it, too, is compared in an automated fashion
(within the server) or whether it even needs to be a UTF8String.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It would be helpful to cite RFC 4120 regarding the definition of the
"nonce" production as a 32-bit integer (so as to avoid confusion about
comparison of nonces when authenticating the user) and to clarify the
exact nature of the nonce (e.g., Section 4.1 states "This nonce string 
MUST contain a randomly chosen component at least as long as the 
armor key length" whereas Section 4.2 states "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" -- the use of "string" here 
might be taken to imply that the nonce is not an integer, and the 
difference between "at least as long" in 4.1 and "as long" in 4.2 might 
cause confusion about the allowable length).

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Oct 2011 11:20:16 -0600

> bit more client behavior.

Hi Sam,

I agree that we might need to chat about these matters in Taipei.

My impression is that the otp-service and otp-vendor elements are not in
fact compared within the client in an automated manner -- they are
merely presented to the user. So I think we can probably just remove the
following sentence:

I think we need to have more discussion about the pin element.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 7 Oct 2011 09:59:29 -0400

The text in section 3.3 that Peter refers to was meant to describe how otp-vendor and otp-service can be used in two ways: to prompt the user and by the client to inspect a connected token.

For disconnected tokens, the two values would be used by the client to prompt the user to select the correct token and so there would be no comparison by the client.  However for connected tokens the client could also display the values to help the user select the token to connect but once connected, the values could be used by the client to verify that the correct token has been connected.

The concept of otp-service came from OTP PKCS#11 attribute [OTP_P11] CKA_OTP_SERVICE_IDENTIFIER and one anticipated use of otp-service would be to set this attribute in a C_FindObjects template to search the connected device for the correct token.  The other element, otp-vendor, is not based upon a PKCS#11 attribute but could be used in a similar manner.

--Gareth

[OTP_P11] ftp://ftp.rsa.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a1.pdf

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Sam Hartman
> Sent: 06 October 2011 18:14
> To: [email-masked]
> Subject: [Ietf-krb-wg] String normalization in draft-ietf-krb-wg-otp-
> preauth
>
> Folks, these issues will probably require discussion at IETF 82.  I
> hope that we can have list discussion that gets us most of the way, but
> it sounds like the IESG really wants us to actually go into detail
> about how these strings are used, which probably means actually
> specifying a bit more client behavior.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Oct 2011 10:58:11 -0400

>>>>>   <[email-masked]> writes:

    > The text in section 3.3 that Peter refers to was meant to describe
    > how otp-vendor and otp-service can be used in two ways: to prompt
    > the user and by the client to inspect a connected token.  The
    > otp-service, otp-vendor, otp-tokenID, otp-length and otp-algID
    > above fields will depend on the type of token.  If connected
    > tokens are used then these values SHOULD be used by the client to
    > locate the correct token if connected and otp-vendor and
    > otp-service MAY also be displayed to prompt the user if the
    > correct token is not found.  If the token is not a connected
    > token, then the values of otp-service and otp-vendor MAY be
    > displayed to the user in order to help the user select the correct
    > token and the values of otp-algID, otp-tokenID and otp-length MAY
    > be ignored.  Any string comparison operations carried out against
    > the values of otp-service and otp-vendor MUST be case sentive.

I think the issue is that the processing of these elements for connected
tokens is not really well specified enough for interoperable
implementations.  String comparison is probably only one of the areas.
We were aware that this was somewhat under-specified , but we seemed to
be willing to let it slide.  Now, we're getting push-back to that
decision.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 10 Oct 2011 07:23:17 -0400

> be willing to let it slide.  Now, we're getting push-back to that

Understood, I was really just clarifying that the otp-service and otp-vendor can be used in comparisons and not just displayed to the user.  (This is obviously not clear in the text.)

Also, I noticed that the type used for the PIN is not consistent.  The type of pin in the PA-OTP-PIN-CHANGE (i.e when a new PIN is returned to the client) is a UTF8String but the fields used by the client in the PA-OTP-REQUEST to send the PIN (otp-pin) or PIN+OTP (otp-value) are of type OCTET STRING.

--Gareth

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 05:53:37 -0400

Pete Resnick's issue regarding the PIN was:

In the current draft, the PIN taken from user input is carried in the otp-pin or otp-value of the PA-OTP-REQUEST and both of these are of type OCTET STRING.  The UTF-8 PIN value carried in the PA-OTP-PIN-CHANGE is sent by the KDC to be displayed by the client and is never used for string comparisons.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 09:20:54 -0400

> 	On the PIN however, you have a real problem. This appears to be
    > a UTF-8 string taken from user input and then used in the security
    > token. Unicode strings taken from user input have all sorts of
    > interesting issues depending on the kinds of normalization used by
    > the input method. In the best circumstances, this means a bunch of
    > false negatives when comparing. In the worst circumstances, there
    > could be some interesting false positives. I don't know if it's
    > the place of this document to discuss all of this, but there at
    > *least* needs to be some comment in the security considerations
    > section if this is going to be a UTF-8 string.

    > In the current draft, the PIN taken from user input is carried in
    > the otp-pin or otp-value of the PA-OTP-REQUEST and both of these
    > are of type OCTET STRING.  

Yeah, that's kind of bad in itself.  It is a strong of characters
however we encode it.  IETF policy requires us to define its character
set and requires that UTF-8 be one of the character sets we support.
(I'm sorry I missed this)

Current thinking says we need to discuss comparisons.

My recommendation is that we say it's always UTF-8 (possibly tagging it
as such)

So I think we have two cases.

1) What happens with PINs in the mode where we use the OTP value to
generate a key?
Do you ever use a PIN there, possibly combined with an OTP value on the
client?
If so, then we need to fully specify processing on the client.

2) When we send the PIN to the KDC, we should say that clients SHOULD
NOT normalize the value; they send what they get.  I recommend SHOULD
NOT not MUST NOT because there are possibly client implementations where
the Kerberos client doesn't get the pre-normalized form.  We also need
to have a recommended processing on the KDC.  There, I think today we
have to say that the KDC should saslprep the string before comparison,
just as SASL plain recommends.  We should add a note saying that as
improved string comparison technologies are standardized, we expect to
move to one of them; we will maintain as much compatibility with
saslprep as possible.

Does this approach make sense for #2?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 09:32:23 -0400

>> 
    >> I think the issue is that the processing of these elements for
    >> connected tokens is not really well specified enough for
    >> interoperable implementations.  String comparison is probably
    >> only one of the areas.  We were aware that this was somewhat
    >> under-specified , but we seemed to be willing to let it slide.
    >> Now, we're getting push-back to that decision.

    > Understood, I was really just clarifying that the otp-service and
    > otp-vendor can be used in comparisons and not just displayed to
    > the user.  (This is obviously not clear in the text.)

I've been thinking about this.  Here's my proposal here.

The OTP-Vendor and OTP-Service are both display strings and
identifiers. When dealing with disconnected tokens, or when no
appropriate token can be found, these strings are displayed to the user.

However, these strings are also used for comparison to find an
appropriate token. In this case, the KDC will have access to the exact
octets of the string contained on the token. Typically the KDC's
information about a token will be supplied by code supplied by the token
vendor or by an administrator entering information from a data sheet for
a class of tokens. As such, clients MUST support matching based on a
binary comparison of the OTP-Vendor and OTP-Service strings. Clients MAY
have other comparisons including normalization insensitive comparisons
to try and find the right token. Tokens differing only in the normalized
form of their OTP-Vendor or OTP-Service strings are never expected and
are not a useful attack vector. Future versions of this specificatino
may recommend specific comparisons for clients to perform if operational
experience challenges the assumption that octet-level comparison is sufficient.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 12:47:03 -0400

> appropriate token can be found, these strings are displayed to the

Agreed

> experience challenges the assumption that octet-level comparison is

I am not sure if we can require binary comparison matching since I would think that in many cases, connected tokens would be supported via a token specific library (possibly PKCS#11-based) provided by the vendor and that library will compare the strings in whatever way it does.

--Gareth

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 13:08:22 -0400

> If so, then we need to fully specify processing on the client.

If the "separate-pin-required" flag is set then the client is required to collect a separate PIN to the OTP value and return it to the KDC in the PA-OTP-REQUEST and so we would need to specify how it processes it.

If the flag is not set (which I think will be very common) then the OTP value used to generate the key will be the combined PIN+OTP and I would imagine that the client would generally display a single prompt ("Enter OTP" or whatever) and the user will simply enter the combined value.  The client will then never see the PIN as a separate string.  

If the token is a connected device then the PIN may be collected by the client and sent to the token in order to generate the OTP value.  In this case there could be client processing.

The OTP value, possibly combined with the PIN, will then either be used to generate the key or returned to the KDC in the PA-OTP-REQUEST.  

> Does this approach make sense for #2?

I agree that it would probably be safest if the client simply sent the PIN as-is.  In some cases, it will also need to send the OTP value to the KDC that it collected from the user and both this and the PIN would be strings and I would think that the same rules would apply.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 13:13:05 -0400

> I am not sure if we can require binary comparison matching since I
    > would think that in many cases, connected tokens would be
    > supported via a token specific library (possibly PKCS#11-based)
    > provided by the vendor and that library will compare the strings
    > in whatever way it does.

My text is intended to permit the library to be more permissive than
octet-level.  However, if we really can't guarantee that if the KDC
sends the same octets that are on the token it will work, we should give
up on connected tokens and go home.
What I'm trying to say is that.

1) The client MUST work if the strings are octet-level the same.

2) That's good enough because we believe we can get the octets on the
KDC

3) The client may work in other cases; we reserve the requirement to add
additional things that should/must work in the future if we find we need
them.

4) Having the client work in arbitrary other cases isn't going to be a
problem with real-world tokens (No one will sell both an RSA token and
an rSa token) and it's not an attack vector even if they do.

If you don't buy into #1, then I really do think connected tokens are
fairly hopeless from an interop standpoint.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 13:26:06 -0400

> fairly hopeless from an interop standpoint.

Sorry, I must have read what you had written too quickly - I read it as the client MUST do a binary comparison.
I don't have a problem with #1.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 13:31:58 -0400

>> 1) What happens with PINs in the mode where we use the OTP value
    >> to generate a key?  Do you ever use a PIN there, possibly
    >> combined with an OTP value on the client?  If so, then we need to
    >> fully specify processing on the client.
    >> 

    > If the flag is not set (which I think will be very common) then
    > the OTP value used to generate the key will be the combined
    > PIN+OTP and I would imagine that the client would generally
    > display a single prompt ("Enter OTP" or whatever) and the user
    > will simply enter the combined value.  The client will then never
    > see the PIN as a separate string.

It's probably still OK, but not as clear cut.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 20 Oct 2011 18:58:14 -0400

On Thu, 2011-10-20 at 13:08 -0400, [email-masked] wrote:
> If the "separate-pin-required" flag is set then the client is required
>  to collect a separate PIN to the OTP value and return it to the KDC in
>  the PA-OTP-REQUEST and so we would need to specify how it processes
>  it.

Right.  In this case, the client is just sending the PIN to the KDC, and
it should send what it gets without doing any string processing (other
than encoding as UTF-8).  Then we have to specify how the KDC does
comparison, which likely should be case-sensitive but
normalization-insensitive, though we have to say what that means.
That's exactly Sam's case 2, below.  

> If the flag is not set (which I think will be very common) then the OTP
>  value used to generate the key will be the combined PIN+OTP and I
>  would imagine that the client would generally display a single prompt
>  ("Enter OTP" or whatever) and the user will simply enter the combined
>  value.  The client will then never see the PIN as a separate string.  

OK, so in this case, the client processing of the PIN is exactly the
same as that of the OTP.  We probably should say that the client SHOULD
first process the PIN and OTP separately and then concatenate them.
However, if the user enters the combined PIN+OTP (which I agree will be
very common), then the client won't be able to do that -- it can only
process the combined string, because it doesn't know where the division
is.  In practice this is unlikely to be a problem.

> If the token is a connected device then the PIN may be collected by the
>  client and sent to the token in order to generate the OTP value.  In
>  this case there could be client processing.

If the token is a connected device, then anything conveyed from the
token to the KDC should not require any string processing by the client;
that's between the token and whatever backend is in use on the KDC.
Anything conveyed by the client from the user to the token is actually
out of scope for our protocol, and is between the token vendor and the
client implementation (mostly, the former).

> The OTP value, possibly combined with the PIN, will then either be used
>  to generate the key or returned to the KDC in the PA-OTP-REQUEST.  

Except that as far as we're concerned, the key is generated using the
value we got from the connected token; the fact that a PIN was first
sent to the token is irrelevant (and it's probably not part of the key
anyway at that point).

> I agree that it would probably be safest if the client simply sent the
>  PIN as-is.  In some cases, it will also need to send the OTP value to
>  the KDC that it collected from the user and both this and the PIN
>  would be strings and I would think that the same rules would apply.

Yes, I agree with this conclusion.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 22:02:38 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> OK, so in this case, the client processing of the PIN is
    Jeffrey> exactly the same as that of the OTP.  We probably should
    Jeffrey> say that the client SHOULD first process the PIN and OTP
    Jeffrey> separately and then concatenate them.  However, if the user
    Jeffrey> enters the combined PIN+OTP (which I agree will be very
    Jeffrey> common), then the client won't be able to do that -- it can
    Jeffrey> only process the combined string, because it doesn't know
    Jeffrey> where the division is.  In practice this is unlikely to be
    Jeffrey> a problem.

I think we actually want to process them together because the OTP may
 need processing and because you probably want the same processing for both.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Oct 2011 11:55:01 -0400

Hi.  We're actually doing much better in resolving the DISCUSS comments
than I thought we would by this point.

I think we have general approaches on the table for everything that has
been brought up. Gareth am I missing anything  I.E. are there issues
brought up by the IESG where you don't think we've discussed a
resolution?

I think we should still give the string handling discussion a couple of
days to see if anyone new jumps in or if any new points are raised.

Would it be reasonable to target having a new version of the draft mid
next week that we hope addresses these comments?  If so, we can give the
WG and IESG a couple of weeks to review it and get OTP approved during
the IETF.

--Sam

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 06:06:28 -0400

How about the following for the PIN handling?

a) Change the type of the otp-pin field in the PA-OTP-REQUEST to UTF-8

               otp-pin        [6]  UTF8String                OPTIONAL,

b) Extend the text describing the PIN handling section 3.3 "Client Response":

   If the "separate-pin-required" flag is set then any PIN collected by
   the client MUST be included as a UTF-8 string in the otp-pin of the 
   PA-OTP-REQUEST.  

   If the token is a connected device how the PIN is used to generate the 
   OTP value will depend on the type of device.  However, if the token is 
   a disconnected device, the it will depend on the "separate-pin-required"
   flag.  If the flag is not set then the OTP value
   MUST be generated by appending the PIN with the value from the token
   entered by the user and, if the flag is set,
   then the OTP value MUST be the value from the token.

   The clients SHOULD NOT normalize the PIN value or any OTP value collected 
   from the user or returned by a connected token in any way.

c) Add a paragraph describing the KDC handling of the PIN to section 3.4 "Verifying the pre-auth Data"

   If the otp-pin field is present in the PA-OTP-REQUEST then the PIN value
   has be value provided by the client.  The KDC SHOULD saslprep [RFC4013] 
   the value before comparison.   

   It should be noted that it is anticipated that, as
   improved string comparison technologies are standardized, the processing
   done by the KDC will change but efforts will be made to maintain as much 
   compatibility with saslprep as possible.

--Gareth

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 06:22:16 -0400

> experience challenges the assumption that octet-level comparison is

How about the following changes:

a) Modify paragraph 4 in section 3.2 "KDC Challenge"

   The KDC MAY use the otp-service field to assist the client in
   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 that are used for different purposes.  If the token is a 
   connected device, then these values SHOULD be an exact octet-level
   match for the values present on the target token.

b) Clarify the text in paragraph 3 in section 3.3 "Client Response"

   The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format and
   otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to
   assist the client in locating the correct token to use but the use of
   the above fields will depend on the type of token.  

   If the token is a disconnected device, then the values of
   otp-service and otp-vendor MAY be displayed to the user in order to
   help the user select the correct token and the values of otp-algID,
   otp-tokenID, otp-length and otp-format MAY be ignored.  

   If the token is a connected device, then these values, if present, 
   SHOULD be used by the client to locate the correct token.  
   When the token is connected, clients MUST support matching 
   based on a binary comparison of the otp-vendor and otp-service strings. 
   Clients MAY have other comparisons including normalization insensitive 
   comparisons to try and find the right token.
   The values of otp-vendor and otp-service
   MAY be displayed to prompt the user if the correct token is not
   found.  

--Gareth

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 06:27:22 -0400

> brought up by the IESG where you don't think we've discussed a

I think everything has be covered.  All of Sean Turner's and Adrian Farrel's points have already been resolved and the only other issues are the PIN, otp-service and otp-vendor normalization.

> WG and IESG a couple of weeks to review it and get OTP approved during

I think so,  I have already updated it to cover Sean and Adrian's points and so once the text for the string normalization is agreed then I should be able to submit an update.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Oct 2011 07:10:11 -0400

I aggree with this text as far as it goes.  This doesn't describe how to
prepare the OTP value on the client in the case where we're using it to
generate a key.

I think in section 3.6
in the case where you're hashing you need to saslprep otp before it goes
into h.
And saslprep otp before it is base64 encoded in the non-hash case.

I'm not thrilled with saslprep; it has the singular advantage of
existing today.  If connected tokens may produce raw binary OTP values
we should require that if saslprep fails, we use the raw value and
explain this is to deal with non-UTF-8 input or input from connected
tokens that happens to have prohibited codepoints.

However, if anyone in the WG has other ideas please speak up.

I also don't think it matters much what we choose here: PINs and OTP
values probably aren't very adventurous.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Oct 2011 07:12:01 -0400

This looks good.

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 08:31:22 -0400

> values probably aren't very adventurous.

Maybe the text describing the value of "OTP" in the generation of the hash from section 3.6 should be something like this:

   o  An initial hash value, H, is generated:

             H = hash(realm|nonce|OTP)

      *  If the OTP format is decimal, hexadecimal
         or alphanumeric, then OTP is the value of
         the OTP generated as described in Section 3.3.
         with saslprep [RFC4013] applied otherwise it is
         the unnormalized OTP value.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Oct 2011 06:47:19 -0400

I'm fine with that text.
I believe with that change we're doing fairly well.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 12:36:48 -0400

I have made the changes and so if there are no other comments I will be able to submit later this week

> From: Sam Hartman [mailto:[email-masked]]
> Sent: 25 October 2011 11:47
> To: Richards, Gareth
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Ietf-krb-wg] String normalization in draft-ietf-krb-wg-
> otp-preauth
>
> I'm fine with that text.