Topics

Public Review Draft - IdentityStore validate


Darran Lofthouse
 

On the validation provided by the IdentityStore I have a few concerns.

The first is I think it is stretching the definition to effectively encapsulate the whole response to a challenge as a credential, generally a credential would be something like a password but now it also includes the username for some and in other cases more fields from the challenge and response may need to included.

Secondly it seems to be very much single shot, there doesn't seem to be an option for the validation to handle the multiple trip nature of some mechanisms such as SPNEGO which may require a continuation required response or Digest that may require a subsequent challenge due to a stale nonce.

Regards,
Darran Lofthouse.


Darran Lofthouse
 

One more point on this one as well, it also risks leaking information about HTTP responses into the IdentityStore so now the store may need to be aware of HTTP handling of Digest auth, if it is re-used for SASL authentication later or another similar scheme the store would then need to be aware or more details.


On Thu, 6 Jul 2017 at 16:31 Darran Lofthouse <darran.lofthouse@...> wrote:
On the validation provided by the IdentityStore I have a few concerns.

The first is I think it is stretching the definition to effectively encapsulate the whole response to a challenge as a credential, generally a credential would be something like a password but now it also includes the username for some and in other cases more fields from the challenge and response may need to included.

Secondly it seems to be very much single shot, there doesn't seem to be an option for the validation to handle the multiple trip nature of some mechanisms such as SPNEGO which may require a continuation required response or Digest that may require a subsequent challenge due to a stale nonce.

Regards,
Darran Lofthouse.


Arjan Tijms
 

Hi,

On Thu, Jul 6, 2017 at 5:32 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One more point on this one as well, it also risks leaking information about HTTP responses into the IdentityStore so now the store may need to be aware of HTTP handling of Digest auth, if it is re-used for SASL authentication later or another similar scheme the store would then need to be aware or more details.

The spec explicitly mentions that the identity store should not be aware of these details. 

Do note that a mechanism does not HAVE to delegate to an identity store. If it doesn't make to do so, it's under no obligation to do. The /test folder of Soteria even contains a few samples where the authentication mechanism does not delegate.

Kind regards,
Arjan Tijms


 


On Thu, 6 Jul 2017 at 16:31 Darran Lofthouse <darran.lofthouse@...> wrote:
On the validation provided by the IdentityStore I have a few concerns.

The first is I think it is stretching the definition to effectively encapsulate the whole response to a challenge as a credential, generally a credential would be something like a password but now it also includes the username for some and in other cases more fields from the challenge and response may need to included.

Secondly it seems to be very much single shot, there doesn't seem to be an option for the validation to handle the multiple trip nature of some mechanisms such as SPNEGO which may require a continuation required response or Digest that may require a subsequent challenge due to a stale nonce.

Regards,
Darran Lofthouse.



Darran Lofthouse
 



On Thu, 6 Jul 2017 at 19:57 Arjan Tijms <arjan.tijms@...> wrote:
Hi,

On Thu, Jul 6, 2017 at 5:32 PM, Darran Lofthouse <darran.lofthouse@...> wrote:
One more point on this one as well, it also risks leaking information about HTTP responses into the IdentityStore so now the store may need to be aware of HTTP handling of Digest auth, if it is re-used for SASL authentication later or another similar scheme the store would then need to be aware or more details.

The spec explicitly mentions that the identity store should not be aware of these details. 

I think that requirement does prevent certain mechanisms from being implemented to use an identity store where there is no credential that can be validated.

Do note that a mechanism does not HAVE to delegate to an identity store. If it doesn't make to do so, it's under no obligation to do. The /test folder of Soteria even contains a few samples where the authentication mechanism does not delegate.

I do like the IdentityStore being optional, that does lessen my concern on that one.
 

Kind regards,
Arjan Tijms


 


On Thu, 6 Jul 2017 at 16:31 Darran Lofthouse <darran.lofthouse@...> wrote:
On the validation provided by the IdentityStore I have a few concerns.

The first is I think it is stretching the definition to effectively encapsulate the whole response to a challenge as a credential, generally a credential would be something like a password but now it also includes the username for some and in other cases more fields from the challenge and response may need to included.

Secondly it seems to be very much single shot, there doesn't seem to be an option for the validation to handle the multiple trip nature of some mechanisms such as SPNEGO which may require a continuation required response or Digest that may require a subsequent challenge due to a stale nonce.

Regards,
Darran Lofthouse.