Subject: Re: [Ietf-krb-wg] WG Last Call: draft-ietf-krb-wg-otp-preauth-12

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 08:50:17 -0400

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

    > The current ID is based on the assumption that it will be prfiled
    > for different tokens based on the oalgorithm ID (otp-algID).  For
    > example, it might state that a client MUST return OTP values in
    > plain text unless the KDC sets the must-encrypt-nonce flag.

Ah, you've finally come out and said that even for the disconnected mode
you're expecting the client to understand the algorithm ID and to change
its behavior based on this.

>From an implementation standpoint, this is undesirable.  It requires the
implementation to have code specific to each token algorithm.

If we're going to go down that route, I believe that we must:

* Have a section describing what a profile must include

* Normatively reference something setting up a profile registry and
giving registration requirements

* Have constraints on what behavior changes a profile is allowed to make
  so that an implementation can reasonably provide a provider framework
  and limit what will be required to profile new mechanisms

* Write up at least one profile to go along with this document  as a
  standards track profile.

I'm rather uncomfortable with this architecture. It seems like a great
opportunity to provide a mechanism for vendors to sell the rights for
clients to use a particular OTP token with a Kerberos implementation. I
don't think that is in the best interest of Kerberos interoperability.

I'd be much happier with an architecture where the behavior of the
Kerberos implementation was completely specified by this document. I
don't have a problem if token algorithm identifiers need to be plugged
into something like PKCS11 (or matched against that interface to find a
token), but it would be desirable for no profiling of the Kerberos
implementation behavior to be required.

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

---

From: <[email-masked]>
Date: Wed, 1 Sep 2010 09:03:24 -0400

> Ah, you've finally come out and said that even for the 
> disconnected mode you're expecting the client to understand 
> the algorithm ID and to change its behavior based on this.
> 
> From an implementation standpoint, this is undesirable.  It 
> requires the implementation to have code specific to each 
> token algorithm.
> 
> 
> * Normatively reference something setting up a profile 
> registry and giving registration requirements
> 
> I'm rather uncomfortable with this architecture. It seems 
> like a great opportunity to provide a mechanism for vendors 
> to sell the rights for clients to use a particular OTP token 
> with a Kerberos implementation. I don't think that is in the 
> best interest of Kerberos interoperability.
> 
> I'd be much happier with an architecture where the behavior 
> of the Kerberos implementation was completely specified by 
> this document. I don't have a problem if token algorithm 
> identifiers need to be plugged into something like PKCS11 (or 
> matched against that interface to find a token), but it would 
> be desirable for no profiling of the Kerberos implementation 
> behavior to be required.
> 

I agree with you on this and I think that it should be possible to do
away with the profile concept since it is only mentioned in a few
places.  I will look into doing this during this update.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Wed, 1 Sep 2010 11:05:22 -0400

> be desirable for no profiling of the Kerberos implementation 

I think that the idea of the algorithm profiles can be removed with the
following changes:

1. Modify the paragraph 7 in section 3.3 so that the use of the OTP
value in the key generation is completely controlled by the
"must-encrypt-nonce" flag.
If the flag is set then the OTP value is used in key derivation, if the
flag is not set then it is returned to the KDC.

          If the "must-encrypt-nonce" flag is set in the
          PA-OTP-CHALLENGE then the OTP value MUST be used in key
          derivation as described in <xref target="ReplyKeyGen"/> and
          MUST NOT be included in the otp-value field of the
          PA-OTP-REQUEST.  If the flag is not set then the OTP value
          MUST be included in the otp-value field of the
          PA-OTP-REQUEST and MUST NOT be used in the key derivation.
          However, if the returning of OTP values in this way does not
          conform to local policy on the client then it SHOULD NOT use
          the token for authentication.

2. Move the "must-encrypt-nonce" flag from the flags in the
PA-OTP-CHALLENGE to the flags in the otp-keyInfo
In this way, the flag is per token rather than applying to all tokens
that the user could use to authenticate.  For example, if the user has
two tokens that can be used to authenticate to the KDC and the KDC can
only obtain the OTP value for the first of them then it would need to
set the flag in the first otp-keyInfo but not in the second.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 11:11:06 -0400

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Sep 2010 11:19:00 -0400

> don't think that is in the best interest of Kerberos interoperability.

Speaking as an individual, I agree.  That model would be a really poor 
idea; if you need a proprietary (or even token-specific) client extension 
to use a particular token, then that token will not be usable with most 
clients.  That means users will be able to use their tokens on their 
Windows desktops, but probably not on Linux and MacOS systems, and almost 
certainly not on devices like phones and tablets.

-- Jeff

---

From: Tom Yu <[email-masked]>
Date: Fri, 10 Sep 2010 02:03:15 -0400

Sam Hartman <[email-masked]> writes:

> [Tom you're explicitly copied because I'm asking for your help with some text]
>     >> Using the IDNA-2003 name of the KDC in the hash seems particularly
>     >> problematic.  First, I'd recommend something based on the realm rather
>     >> than a specific KDC.  Second, I think you can avoid 
>     >> introducing an IDNA
>     >> reference (and especially one to an obsolete IDNA).  I'd use 
>     >> the octets
>     >> of the realm string from the request itself.  You'll need to decide
>     >> whether or not to include length and tag (probably not), but 
>     >> that ought
>     >> to allow you to side step I18N entirely.
>     >> 
>
>     > Could you suggest some text for that section.
> If we're agreed on direction, I think Tom Yu would probably do a better
> job of writing text here.
> He's going to be one of the pickiest reviewers  so I'd rather start with
> something he will like.
> Tom, can you help us with this?

We have sidestepped most of the internationalization issues for the
Kerberos protocol so far.  Introducing IDNA semantics in a preauth
mechanism seems less appropriate than deliberately updating the core
Kerberos protocol (at a later date) to do so.  I agree with Sam: I
recommend using the octets of the realm name as sent in the protocol.
(The contents, not including any DER framing.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg