[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] WSS One Time Password
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]