Re: [reSIProcate] Helper::advancedAuthenticateRequest() and old nonces

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Is it reasonable to expect that we will encounter an endpoint that  
persists in giving us bad nonces even when we issue a challenge (with  
a new nonce)? I _suppose_ this could happen (and keep in mind that a  
malicious endpoint can do this whenever it wants regardless of what  
response we use, so we're only really concerned with endpoints that  
are _trying_ to behave themselves). My concern is that the default  
behavior of the stack is broken with respect to handling digest  
challenge logic. This needs to be fixed somehow. I think a reasonable  
course of action would be to have a BadNonce return from Helper when  
this sort of thing happened, and the app could decide what it wants  
to do (instead of returning Failed, which basically forces the app  
into sending a 403).

Best regards,
Byron Campen

> Exactly - we may have infinity message flow:
> (Request with bad credential) <-> (401 with challenge)
>
> I don't see any use cases when 401 will help.
> Even if you use pool of proxies - you may share one nonce helper key
> among servers.
> But if somebody provides credential for YOUR domain/ip and it does not
> contain proper nonce - it should be rejected.
>
> Regards
> Alexander Altshuler
> http://xeepe.com
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Wednesday, March 12, 2008 5:38 PM
> To: Alexander Altshuler
> Cc: 'resiprocate-devel'
> Subject: Re: [reSIProcate] Helper::advancedAuthenticateRequest()  
> and old
> nonces
>
>         This is certainly useful. Do you have an opinion on the 403 vs.
> 401
> issue though? It seems that sending a 403 buys us absolutely nothing,
> and hurts interop besides. I see no reason to continue doing it. I
> could maybe see sending a 403 if someone sends us credentials that
> are malformed, on the assumption that the endpoint is broken and we
> should just tell it to shut up. (This brings up the question of how
> we deal with endpoints that don't know when to quit sending us bad
> credentials.)

Attachment: smime.p7s
Description: S/MIME cryptographic signature