Hi. I hope you didn't read yet proposal's version 0.0.3, there is already 0.0.4 available with small changes:
https://a2nets.erve.vtt.fi/TeemuVaisanen?action=AttachFile&do=view&target=xep-0000-UserAuth-draft-0.0.4.html I modified (corrected) example messages. -Teemu V 2014-03-19 15:14 GMT+02:00 Teemu Väisänen <[email protected]>: > 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. >> >>
