Sorry, I'm still lost here. In particular, I don't understand what the two factors in this proposal are - it looks to me like you have two accounts, and the identities of one of them is (non-mutually) proven to the other. That sounds like single-factor end-to-end authentication, and not two-factor authentication at all.
Furthermore, your design appears to hinge on having a trusted, authenticated, communications path between the two parties to begin with, so I'm deeply confused about why you'd want to authenticate another. Can you give me an actual, real-world, example of how this is intended to be used? On Mon, Feb 24, 2014 at 8:27 AM, Teemu Väisänen <[email protected]> wrote: > Hello Dave. More details come here. I hope the draft version of 0.0.2 > describes things better than the version 0.0.1. At least there is now > one figure describing a simplified use case. Two use cases described > in this message include more details than the simplified use case in > the XEP proposal. What are your opinions, should I use as much details > or is the level used in the XEP proposal enough? > > For the Council: Yes, I have sent XML-version to the editor. > > ---- > > Use case 1. > > 1. User UserU starts device DeviceD. > 2. Another user UserD presenting a device logins to its XMPP account > DeviceAccountB in XMPP client DeviceClientB in DeviceD. > 3. UserU logins to his/her XMPP account UserAccountA in XMPP client > UserClientA in DeviceD. Order of 2. and 3. could be changed. > 3+. This step was missing: After a succesful login in step 1., > UserClientA transmits full JID of UserAccountA to DeviceClientB using > a secure channel which is out of scope of XEP proposal. When both XMPP > clients are running in same application in same device, the > DeviceClientB would know that UserAccountA is succesfully logged in > from UserClientA in DeviceD. > > This might be enough in the simplest use case where we want to be sure > that the userU has access to the DeviceD when he/she logins. Actually > in such case, there is no need to transmit full JID of UserAccountA > but bare one would usually be enough for e.g., roster based access > control. > > In the original example (in the message Dave refers to) I used also > the following steps for enabling more generic and complex use cases: > > 4. DeviceClientB selects an authentication mechanism and generates a > shared secret K. How the authentication mechanism is selected is out > of scope of the XEP proposal. > 5. DeviceClientB transmits this to K and information about wanted/used > authentication mechanism to UserClientA using a secure channel which > is out of scope of the XEP proposal. > 6. DeviceClientB transmits full JID of DeviceAccountB to UserClientA > using a secure channel which is out of scope of the XEP proposal as > are secure channels of steps 3+. and 5. Now UserClientA knows full JID > of DeviceAccountB and DeviceClientB knows full JID of UserAccountA. > 7. UserAccountA sends K from UserClientA to DeviceAccountB in > DeviceClientB, using presented new ad-hoc commands and known full JID. > UserAccountA in UserClientA may logout anytime after succesfull > transmission. > 8. DeviceClientB checks if sender's full JID is the same as > UserAccountA's full JID and checks if received K is correct or not. > 9. DeviceCLientB can be sure whether UserAccountA really exists or > not, whether UserU knew UserAccountA's credentials or not, and that > UserAccountA from UserClientA in DeviceD and no-one else sent the > wanted K, all these inside certain wanted timeslot. > > After this DeviceClientB may check, e.g., if UserAccountA is > authorized or not to access certain resources, do something, or start > something in DeviceD or somewhere else. > > Now you might wonder why to execute the steps 4-9 in the use case 1., > if 1-3+. are enough to fulfill requirements in our simplest use case? > Well, I try to describe the reason in the use case 2. below. It is > more complex. There are two different devices, DeviceD where the userU > logins and DeviceK that stores the shared secret K which is required > for authentication. In above example DeviceD and DeviceK are the same > and manual input of K is not necessarily possible. > > ---- > > Use case 2. > > 1. UserU starts DeviceD. > 2. UserU logins to his/her XMPP account UserAccountA in XMPP client > UserClientA in DeviceD. > 3. UserD logins to its XMPP account DeviceAccountB in XMPP client > DeviceClientB in DeviceD. > 4. UserClientA transmits full JID of UserAccountA to DeviceClientB > using a secure channel which is out of scope of the XEP proposal. > 5. DeviceClientB generates a shared secret K. > 6. DeviceClientB transmits K to DeviceK using a secure channel which > is out of scope of the XEP proposal. > 7. UserU gets K from DeviceK, e.g., by reading it manually from > DeviceK's screen if such exists or UserClientA gets K from DeviceK > with some protocol which is out of scope of the XEP proposal. > 8. DeviceClientB transmits full JID of DeviceAccountB to UserClientA > using a secure channel which is out of scope of XEP proposal. Now > UserClientA knows full JID of DeviceAccountB and DeviceClientB knows > full JID of UserAccountA. > 9. UserU inputs manually K to forms received in ad-hoc commands. It > could be done also automatically if such is implemented. UserAccountA > sends K from UserClientA to DeviceAccountB in DeviceClientB, using > presented new ad-hoc commands and known full JID. UserAccountA in > UserClientA may logout anytime after succesfull transmission. > 10. DeviceClientB checks if sender's full JID is the same as > UserAccountA's full JID and checks if received K is correct or not. > 11. DeviceClientB can be sure whether UserAccountA really exists or > not, whether User UserU knew UserAccountA's credentials or not, and > that UserAccountA from UserClientA in DeviceD and no-one else sent the > wanted K, and that UserU (or UserClientA in automatic case) has > required access to DeviceK, all these inside a certain wanted > timeslot. > > After this DeviceClientB may check, e.g., if UserAccountA is > authorized or not to access certain resources, do something, or start > something in DeviceD or somewhere else. > > ---- > > So, use cases 1. and 2. are basically the same, if we think that > DeviceK and DeviceD are one and the same device and there is no manual > input done by the UserU. > > K can be a shared secret, or a one-time password calculated from a > shared secret, or something else. > > Does anyone have ideas how the name of the XEP proposal should be modified? > > Should I add real life scenarios where the XEP proposal could/have been be > used? > > -Teemu > > > 2014-02-05 17:56 GMT+02:00 Dave Cridland <[email protected]>: > > I'm really sorry, but I genuinely do not know what is going on at all in > > your example below. Could you give a concrete example, with things like > "An > > app" instead of A, or whatever it's meant to be. > > > > I just don't follow what A and B are, and why they need to authenticate > to > > each other, and why U and D might possibly have different accounts, and > > perhaps a simple use-case might clarify things. > > > > On 20 Dec 2013 17:47, "Teemu Väisänen" <[email protected]> wrote: > >> > >> Thank Sergey for your message. > >> > >> I try to clarify it with a simple example with a device. Does it make > any > >> sense? > >> > >> A presents XMPP account of a user U. > >> B presents XMPP account of the device D. > >> U does not know B. > >> U knows D and has it in his/her hand. > >> A does not (necessarily) know B. > >> B does not (necessarily) know A. > >> > >> 1. U starts D. > >> 2. B logins in D. > >> 3. A logins in D. > >> 4. B generates a shared secret K. > >> 5. B transmits K to A, e.g., programmatically when both A and B are in > >> same D. > >> 6. Both A and B know now each other (at least inside the program). > >> 7. A sends K to B using presented new ad-hoc commands. A may logout > >> anytime after succesful transmission. > >> 8. B checks if sender's full JID is known A's full JID and checks if > >> received K is correct or not. > >> 9. B can be sure whether A really exists or not, whether U knew A's > >> credentials or not, and that A and no-one else sent the wanted K. > >> > >> After this B may check, e.g., if A is authorized or not to access > >> certain resources, do something, or start something. > >> > >> > >> -Teemu V > >> > >> > >> 2013/12/20 Sergey Dobrov <[email protected]>: > >> > Hello Teemu, > >> > > >> > I would like to see some example chart of some example how it works > and > >> > why does it need. Because current text description in the first > >> > paragraph is hard to understand, from my point of view. > >> > > >> > Thanks. > >> > > >> > On 12/19/2013 06:04 PM, Teemu Väisänen wrote: > >> >> Hello all. > >> >> > >> >> I have written a new proposal for a XEP: Two-factor user > >> >> authentication with a shared secret. html and xml files can be > >> >> downloaded from https://a2nets.erve.vtt.fi/TeemuVaisanen > >> >> > >> >> For the next version we have to think, e.g., if there should be only > >> >> one ad hoc command to ask all supported mechanisms or use separate > >> >> commands for each authentication mechanism (as in current version). > >> >> > >> >> Any questions, comments and suggestions are welcome. > >> >> > >> >> Best regards, > >> >> > >> >> Teemu Väisänen > >> >> > >> > > >> > > >> > -- > >> > With best regards, > >> > Sergey Dobrov, > >> > XMPP Developer and JRuDevels.org founder. >
