Thank you Dave, I changed the title and added few real-world examples. Intro starts to be quite long...
New version of html file is in https://a2nets.erve.vtt.fi/TeemuVaisanen?action=AttachFile&do=view&target=xep-0000-UserAuth-draft-0.0.3.html Comments? Btw, does anyone have/know about a bibtex file of all the XEPs? For RFCs there exist some.. -Teemu 2014-02-25 16:09 GMT+02:00 Dave Cridland <[email protected]>: > 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. > >
