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

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


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.
>>
>>



More information about the Standards mailing list