Re: [kitten] SPAKE and not replying to requests

‘sarright. ;-)

> On Aug 28, 2017, at 6:07 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Wed, Aug 23, 2017 at 04:33:44PM -0400, Robbie Harwood wrote:
>> Greg Hudson <ghudson@mit.edu> writes:
>> 
>>> On 08/22/2017 02:16 PM, Robbie Harwood wrote:
>>>>> I propose to change this text to:
>>>>> 
>>>>>    [...] If either factor fails to validate, the KDC SHOULD respond
>>>>>    with an appropriate KRB-ERROR message.  The KDC MAY choose not to
>>>>>    respond to the request, with the expectation that the client will
>>>>>    retry against other KDC servers within the realm.
>>>> 
>>>> I wonder if we should be more explicit about what the client should do
>>>> if it doesn't get a reply from the server here.  Maybe something like,
>>>> e.g., "The KDC MAY choose not to respond to the request, at which point
>>>> the client SHOULD retry against other KDC servers within the realm." or
>>>> so?
>>> 
>>> I would prefer that this document not get into the weeds of client-KDC
>>> network communication, but looking at RFC 4120, I think you are right
>>> that nothing really says what the client should do in the face of a
>>> timeout.  There are also cases where a client might not be able to reach
>>> all KDC processes for a realm (network load balancers, MIT krb5 KDC
>>> worker processes, etc.), so perhaps black-holing requests is a hack we
>>> shouldn't encourage in the standard.
>>> 
>>> With that in mind, I guess I just want the text to say:
>>> 
>>>    If either factor fails to validate, the KDC SHOULD respond with an
>>>    appropriate KRB-ERROR message.
>>> 
>>> with no further discussion of what a KDC might choose to do instead.
>> 
>> Agreed, that makes sense to me.
> 
> It makes sense to me as well.
> 
> -Ben
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

Personal email.  hbhotz@oxy.edu