OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-319) Client Reauthentication


    [ https://issues.oasis-open.org/browse/MQTT-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63896#comment-63896 ] 

Ken Borgendale commented on MQTT-319:
-------------------------------------

Combine MQTT-315 into this issue.  This text is from MQTT-315:

In MQTT-255 we added enhanced authentication which allows for challenge / response authentication and other authentication in SASL style. We specifically removed the re-validation (multiple authentication) from that issue so we are creating this new issue to track re-validation. 

The mechanism used for enhanced authentication (AUTH packet) can be extended without much problem to allow re-validation. However we need to design the semantics. This is not well defined in SASL (basically it just says it is possible without talking much about these semantics). 

A few of the issues: 
1. Who initiates re-validation. Is is always the client or can the server start it? 
2. Is it required to re-validate using the same authentication method used to validate? 
3. What can be done during the re-validation? 
4. What do we tell the server to do if re-validation fails? 
5. Does this work for all authentication methods or just some? 
6. Does anybody want this badly enough to spend some time working on it?

> Client Reauthentication
> -----------------------
>
>                 Key: MQTT-319
>                 URL: https://issues.oasis-open.org/browse/MQTT-319
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>    Affects Versions: 5
>            Reporter: Konstantin Dotchkoff
>
> For improved security, in many scenarios, security tokens with an expiration time are used to authenticate Clients. When the token expires, the Server will disconnect the Client, since the authentication information is not valid anymore. Re-establishing the Client connection is expensive operation and also interrupts the message exchange between the Client and Server.
> For those cases having the ability to re-authenticate the Client on an existing/open connection is very beneficial.
> At the at the 2016-10-13 MQTT TC meeting it was decided to move the re-authentication out of MQTT-255 into a separate issue.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]