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

Dave Cridland dave at cridland.net
Tue Feb 25 14:09:46 UTC 2014


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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140225/a857d604/attachment.html>


More information about the Standards mailing list