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

Teemu Väisänen uolevi at gmail.com
Wed Mar 19 13:14:01 UTC 2014


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