[Standards] Request for Comments: XEP: Two-factor user authentication with a shared secret

Teemu Väisänen uolevi at gmail.com
Fri Mar 21 17:16:43 UTC 2014


Hmmm. Apparently html file is not shown correctly (perhaps because of
MoinMoin). At least Glossary chapter is shown empty in all my
browsers. So, here is the xml file

You can find it also from https://a2nets.erve.vtt.fi/TeemuVaisanen

Happy weekend!

-Teemu V

2014-03-21 18:48 GMT+02:00 Teemu Väisänen <uolevi at gmail.com>:
> 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 <uolevi at gmail.com>:
>> 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 <dave at cridland.net>:
>>> 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 <uolevi at gmail.com> 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 <dave at cridland.net>:
>>>> > 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" <uolevi at gmail.com> 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 <binary at jrudevels.org>:
>>>> >> > 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.
>>>
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xep-0000-UserAuth-draft-0.0.4.xml
Type: text/xml
Size: 47899 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140321/fb79a49f/attachment.xml>


More information about the Standards mailing list