Subject: [kitten] Comments on draft-josefsson-kitten-crotp-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 29 Mar 2011 12:50:21 +0200

[email-masked] wrote:
 [...]

>The CROTP mechanism family provide support for two-factor
>authentication using a static long-term password and a single use
>changing one-time password (OTP) in the SASL and GSS-API frameworks.
>The design of CROTP is based on SCRAM described in RFC 5802.  CROTP
>works with several OTP system, including the Open AuTHentication HOTP
>algorithm described in RFC 4226.
>  
>
Some quick comments on the draft (which looks quite reasonable otherwise):

4.  Protocol

      ;; variant used by CROTP
      otp                                = "o=" saslname

What is the exact semantics of this field?
Does it need an IANA registry?

   [TODO: Require TLS for OTP protection, or derive keys from the SCRAM
   negotiation and GSS_Wrap the OTP?]

I would personally prefer the latter, to keep this more generic.

7.  IANA Considerations

   IANA has added the following family of SASL mechanisms to the SASL

I think this should use future tense for now.

   Mechanism registry established by [RFC4422]:

     Note: The family names are intended to match the SCRAM names,
       and uses the same (but separate) registration policy.
       Registration of CROTP names should be reviewed for alignment
       with similar SCRAM names.  XXX: registration policy?

Yes, something needs to be done about that :-).

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Mar 2011 14:16:18 +0200

> Does it need an IANA registry?

My experience is that the semantics of OTP values are the same as
semantics for passwords: they are site-specific.  Thus I don't know what
more could be said here.  Maybe you could give an example of what you
are thinking of here?  Are you thinking of some kind of "OTP vendor"
field?

Hm.  What _would_ be useful is for the server be able to specify, in
server-first-message, a vendor and token identifier, or similar.  That
will allow the client (or user) to locate the proper OTP token.  This
also aligns well with draft-ietf-krb-wg-otp-preauth-16.

> I would personally prefer the latter, to keep this more generic.

If it can be done without modifying the protocol flow (2 complete
round-trips) I would agree -- and I think that can be done.

However a bigger question is whether an OTP needs to be more than
integrity protected at all.

> Yes, something needs to be done about that :-).

Thanks, I'll revisit this part if this is going forward at all.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 29 Mar 2011 14:51:51 +0200

>are thinking of here?  Are you thinking of some kind of "OTP vendor"
After seeing "saslname", I was expecting some kind of OTP mechanism name 
here.

I actually not entirely sure what you want to put here, so at least 
seeing some examples would be useful.

>server-first-message, a vendor and token identifier, or similar.
>
Yes, I was expecting this as well.

>That
 [...]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Mar 2011 14:58:52 +0200

Alexey Melnikov <[email-masked]> writes:

> After seeing "saslname", I was expecting some kind of OTP mechanism
> name here.
>

OK -- the intention was just to re-use the ABNF for 'saslname':

   saslname        = 1*(value-safe-char / "=2C" / "=3D")

Possibly I should rename this to avoid confusion.

Examples values would be something like this:

otp=234020
otp=dteffujedcflcindvdbrblehecuitvjkjevvehjd

> Yes, I was expecting this as well.

Will add something.

Thanks,
Simon

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Mar 2011 08:56:54 -0500

When do OTPs _not_ need confidentiality protection?  I believe they always
do.  Moreover, for those doing two-factor authentication, protecting the OTP
with a pasword-derived key is out (since an attwacker that knows the
password can MITM the user).

In other words, OTP really wants TLS or PKU2U in the GSS context. It also
wants another mech to do password-based auth (SCRAM, IAKERB, ...).  IOW, OTP
in GSS really wants to be like a pseudo-mechanism that combines two other
concrete mechanisms.  And yet it could be done in three round-trips, and
with with some cleverness in just two! (the margins of this e-mail lack
space for me to share that [or, rather, I'll explain later if t' still
relevant, but also, it's fairly obvious.]).

But I have to wonder, with GSS-EAP and IAKERB, do we _really_ need an OTP
mech?  (A: well, if you want krb5 preauth based on GSS... -ed.  Oh, that's
right!).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 Mar 2011 17:53:19 +0200

> password can MITM the user).

Good point.

> relevant, but also, it's fairly obvious.]).

In the extreme, you could have a multi-factor meta-GSS mechanism that
combines several mechanism into providing multi-factor authentication.

However, how to resolve the problem you brought up about deriving keys
that are protecting the OTP from something other than the password?
Perhaps TLS is necessary here after all.

> mech?  (A: well, if you want krb5 preauth based on GSS... -ed.  Oh, that's

I guess it is an open question whether we need this.  My use case is
making some GSS-API and SASL applications support username+OTP.  You
can't always assume Kerberos is present in these environments.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 15:34:33 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >> But I have to wonder, with GSS-EAP and IAKERB, do we _really_
    >> need an OTP mech?  (A: well, if you want krb5 preauth based on
    >> GSS... -ed.  Oh, that's right!).

    Simon> I guess it is an open question whether we need this.  My use
    Simon> case is making some GSS-API and SASL applications support
    Simon> username+OTP.  You can't always assume Kerberos is present in
    Simon> these environments.

Well, perhaps not today.  IN a couple of years I expect we'll have mini
KDC libraries to link into applications Heimdal mostly already does
although I suspect it's a bit heavy-weight on the app configuration side
of things.

However, Kerberos assumes a certain model about passwords.  If you have
a plaintext legacy password, Kerberos is out.

Eap does have a more consistent story than GSS for combining keys.

I have not formed a strong opinion; just thoughts on the issues.