RE: [wss] WSS One Time Password

["Linn, John" <jlinn@rsasecurity.com>]

Responding to technical points from Hal's 6 February message, here excerpted: 

> 
> Pending that determination, I'd like to offer some thoughts on Hal's
> technical points:
> 
> Re (1), many OTPs are designed to fit in similar "form and function"
to
> passwords, in the sense of being easily entered by users.  This limits
> their size, and hence their entropy; as such, it's often desirable to
> incorporate some computational measures (e.g., iterated hashing)
and/or
> added randomness when deriving keys from OTPs instead of using the OTP
> values directly for keying purposes.

I don't see any practical way to increase entropy, so I presume you are
suggesting the use of a key derivation scheme, such as that specified in
the WS 1.1 Username Token Profile.

[JL] A naïve key derivation function (consider, e.g., one that concatenated copies of a small number of input bits enough times to fill the desired key size) wouldn't necessarily increase the effective entropy.  A key derivation function with iterated hashing, as in the 1.1 UsernameToken Profile, is one technique that can provide an output that's significantly harder to search than its input space would be. 

> 
> Re (2), it should be possible for a claimant and verifier sharing an
OTP
> value to apply it (via derivation as above) to protect the integrity
of
> an associated message; this form of secret-key protection based on a
> shared OTP secret would not, however, provide signing (and associated
> non-repudiation support) in the sense of public-key signatures.  Since
> OTPs are commonly generated and processed on a single-use basis, it
may
> not always be straightforward to apply this method for post-facto
> validation outside the realm of real-time interactions, but this isn't
a
> universal requirement.
> 
I was envisioning only ephemeral Authentication and Integrity
Protection. For that matter, given the fundamental weakness of the keys
in question, perhaps Confidentiality should also be considered somewhat
ephemeral. This still might be useful for data which will soon become
public in any event. 

[JL] The length of time for which a key can provide adequate cryptographic strength seems like an independent matter from the security service(s) that it's being used to provide; authentication, integrity, and confidentiality purposes are probably equivalent in this regard.  

> Re (3), I think most aspects are independent of particular OTP method
> characteristics; one possible exception concerns challenge-response
> methods where a challenge must be obtained from a verifier before an
OTP
> value can be generated.

Assuming the challenge is passed in the message I don't see a problem.
My suggestion would be to treat the Challenge just as the Nonce is
treated in the WSS password hash scheme. That is, the sender generates a
random challenge and sends it along. (Self-challenge) The receiver keeps
a cache to prevent replays. A timestamp can be used to limit the cache
size.

[JL] This fits some cases well, but it's possible for challenge-based methods to rely on the challenge being originated at the verifier, then passed to the claimant where it's used as input to compute the OTP value.  A verifier of this type keeps track of the challenges that it's issued, and won't accept OTPs based on other challenge values.  If such methods are to be accommodated, it seems necessary to provide some means to associate a preceding transaction (obtaining the challenge) from its successor (authenticating with the resulting OTP). 

> 
> Re (4), I'd be surprised if a scheme layered over an OTP method
> introduced otherwise-absent vulnerabilities into that method (vs.
> demonstrating possible flaws at the scheme layer itself), but this is
an
> interesting question; did you have possible examples in mind here?
> 
I have nothing specific in mind, but obviously the strength of these
one-time-password schemes depends in part on the fact that they are just
used one time. Would a new key be derived for every message? Or would
the derived key be reused a few times? What if the interval between msgs
is less that the password generation interval of a time-based scheme?

[JL] It's most common to use an OTP value no more than once, but there can be related methods where constrained reuse is permitted.  Comparable to passwords, however, I think of OTPs primarily as a means to protect a self-contained service request (e.g., to obtain a different form of credential) or to initiate a session, rather than as something that's most effectively applied directly to a sequence of messages in a stream.  Invoking OTP validation processes on a per-message basis could imply significant overhead. Consider TLS by analogy, where a handshake between the peers establishes authenticity and a session key, but the authentication process isn't repeated for each message subsequently sent across the channel.  Two-party key agreement and session management don't seem to fit the SOAP messaging model neatly, however. 

For that matter, in current practice, OTPs are created rarely, perhaps a
couple of times a day per user (master key). Would generating keys far
more frequently or in much larger numbers weaken the scheme in some way?

[JL] The question of strength for such a use case seems method-specific, dependent on particular OTP algorithms.  Cryptographic strength aside, however, I believe that most OTP technologies have been constructed and optimized for operation at the per-session/per-login level; the significantly greater loads that would result from per-message protection within sessions would likely fall outside components' design centers and might not be served effectively. 

What about delays? If the password check, signature verification or data
decryption takes place hours or days after generation does that
introduce any weaknesses or operational issues?

[JL] Potentially, dependent in part on the effort required (and anticipated) to search for a key. 

What about ordering of messages? As I recall the way SKey works, it is
infeasible to derived password N+1 from password N, but trivial to do
the reverse. Does this create any new weaknesses?

[JL] Good observation.  In an environment where multiple OTPs may be simultaneously "in flight", and where ordering can't be guaranteed, there's an implied requirement on the method that not all approaches may satisfy. 

The general point is that these schemes were developed to be used in a
specific way to meet specific threats. If assumptions are altered, we
need to take a hard look and the system's security properties.

[JL] Fully agree. 

Nevertheless, I still believe that the ability to do at least an HMAC
would eliminate the biggest weakness of OTP systems.

[JL] Rather than a weakness (in the sense of flaw) within the scope of OTPs' common usage for user-level authentication purposes, this seems more like a functional issue concerning the problem spaces that OTP methods can best serve.  

Hal

[JL] Thanks for the thoughtful observations. 

--jl