RE: [wss] WSS One Time Password

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

Per the procedural issue, I was respecting Jamie's direction from 24
January as I understood it, which said that "... [the TC is] free to
pursue the planned work that was the subject of the appeal, if it
chooses to do so.  Of course any such work still is subject to the
various voting and appeal rules...".  That text, and particularly its
"if it chooses" clause, suggested to me that a pending choice was to be
made by the TC.  

I hadn't anticipated that the OTP-Token item would be a topic of
interest to all TC members, and am glad now to know of Hal's interest
(and will plan to consider and respond separately on the technical
points he's now raised). I'd like to know of others who would comprise
an active constituency for work on the activity within the TC.  

--jl
 
-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Monday, February 06, 2006 11:30 PM
To: Linn, John; Granqvist, Hans; wss@lists.oasis-open.org
Subject: RE: [wss] WSS One Time Password

John,

> Following Jamie's note and the discussion on today's call, I think the
> specific tasking steps would be follow-on questions to consider if and
> only if the TC chooses to pursue the work item.  As input to this
> decision, I think it's important to get a sense of the extent of
> constituency within the TC that would have active interest in
discussion
> of the OTP topic, so as to assess whether a motivating level of
> "critical mass" exists.

This seems a strange time to bring up this point. There was a simple
majority vote of the TC to do the work. The TC Administrator has ruled
it is not out of scope. The TC has already done several profiles which
are of interest to only a subset of the TC, although others may have
voted in favor of their adoption. If you wanted a forum where 100% of
the participants were committed to the work, it would have been more
appropriate to start a new TC. This all seems like water over the dam,
unless RSA and Verisign wish to withdraw their submissions, I say lets
get on with it.

> 
> 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.

> 
> 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. 

> 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.

> 
> 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?

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?

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?

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?

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.

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

Hal

> --jl
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Monday, January 23, 2006 11:07 AM
> To: Granqvist, Hans; wss@lists.oasis-open.org
> Subject: RE: [wss] WSS One Time Password
> 
> The way to get this going is for one or two people to volunteer to be
> editor. The first task is to produce a consolidated document based on
> the submissions using the OASIS template. This will require a little
> work to decide what material to use from each submission. How to do
this
> is not completely clear to me.
> 
> It seems to me that this work would be significantly more valuable if
it
> could be used for integrity protection at least and perhaps
> confidentiality as well.
> 
> 1. Is it technologically feasible, for example to use a OTP as the
> secret in an HMAC? Or could some key derivation scheme be applied?
> 
> 2. Is it even feasible, to support signing and verification securely
by
> two parties using an OTP?
> 
> 3. Can a single scheme be used for all the types of OTP cited, or do
we
> need a scheme per type or even per OTP algorithm?
> 
> 4. Would the use of such a scheme weaken the OTP in some way?
> 
> Hal
> 
> > -----Original Message-----
> > From: Granqvist, Hans [mailto:hgranqvist@verisign.com]
> > Sent: Tuesday, November 08, 2005 4:29 PM
> > To: wss@lists.oasis-open.org
> > Subject: [wss] WSS One Time Password
> >
> > We voted on doing it so we should track it.
> >
> > I'd like to get started on this work. What's holding
> > us up?
> >
> > Hans
> >
> > > -----Original Message-----
> > > From: Linn, John [mailto:jlinn@rsasecurity.com]
> > > Sent: Wednesday, November 02, 2005 10:41 AM
> > > To: mgudgin@microsoft.com; wss@lists.oasis-open.org
> > > Subject: RE: [wss] Groups - OASIS WSS Issues List 81 (OASIS
> > > Web Services Security Issues List 81.htm) uploaded
> > >
> > > Per the TC vote on 4 October supporting work on an OTP
> > > profile, and subsequent submission of input documents, would
> > > it now be appropriate to add an item to the issues list to
> > > begin tracking this activity,
> > > comparable to entry #338?
> > >
> > > --jl
> > >
> > > -----Original Message-----
> > > From: mgudgin@microsoft.com [mailto:mgudgin@microsoft.com]
> > > Sent: Tuesday, November 01, 2005 5:24 PM
> > > To: wss@lists.oasis-open.org
> > > Subject: [wss] Groups - OASIS WSS Issues List 81 (OASIS Web
> > > Services Security Issues List 81.htm) uploaded
> > >
> > > The document named OASIS WSS Issues List 81 (OASIS Web
> > > Services Security Issues List 81.htm) has been submitted by
> > > Mr Martin Gudgin to the OASIS Web Services Security (WSS) TC
> > > document repository.
> > >
> > > Document Description:
> > > Covers decisions made during 2005-11-01 meeting.
> > >
> > > View Document Details:
> > > http://www.oasis-open.org/apps/org/workgroup/wss/document.php?
> > > document_i
> > > d=15151
> > >
> > > Download Document:
> > > http://www.oasis-open.org/apps/org/workgroup/wss/download.php/
> > 15151/OASI
> > > S%20Web%20Services%20Security%20Issues%20List%2081.htm
> > >
> > >
> > > PLEASE NOTE:  If the above links do not work for you, your
> > > email application may be breaking the link into two pieces.
> > > You may be able to copy and paste the entire link address
> > > into the address field of your web browser.
> > >
> > > -OASIS Open Administration
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS
> > > TC that generates this mail.  You may a link to this group
> > > and all your TCs in OASIS
> > > at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php
> > >
> > >
> > >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs
in
> > OASIS
> > at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php