Subject: [Ietf-krb-wg] Referrals: follow-referrals FAST option

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Jun 2011 14:08:00 -0400

On page 29, RFC 6113 reserves bit 16 of the fast options for the
follow-referrals option.
We removed the description of this option from the preauth framework to
remove a normative reference on the referrals draft.
The text for this option from a previous draft was:

   The kdc-follow-referrals Option                                              
                                                                                
      The Kerberos client described in [RFC4120] has to request referral        
      TGTs along the authentication path in order to get a service              
      ticket for the target service.  The Kerberos client described in          
      the [REFERRALS] needs to contact the AS specified in the error            
      response in order to complete client referrals.  The kdc-follow-          
      referrals option is designed to minimize the number of messages           
      that need to be processed by the client.  This option is useful           
      when, for example, the client may contact the KDC via a satellite         
      link that has high network latency, or the client has limited             
      computational capabilities.  If the kdc-follow-referrals option is        
      set, the KDC MAY act as the client to follow TGS referrals                
      [REFERRALS], and return the service ticket to the named server            
      principal in the client request using the reply key expected by           
   The kdc-follow-referrals Option                                              
                                                                                
      The Kerberos client described in [RFC4120] has to request referral        
      TGTs along the authentication path in order to get a service              
      ticket for the target service.  The Kerberos client described in          
      the [REFERRALS] needs to contact the AS specified in the error            
      response in order to complete client referrals.  The kdc-follow-          
      referrals option is designed to minimize the number of messages           
      that need to be processed by the client.  This option is useful           
      when, for example, the client may contact the KDC via a satellite         
      link that has high network latency, or the client has limited             
      computational capabilities.  If the kdc-follow-referrals option is        
      set, the KDC MAY act as the client to follow TGS referrals                
      [REFERRALS], and return the service ticket to the named server            
      principal in the client request using the reply key expected by           
 
      the KDC knows the reply key.  The KDC can ignore kdc-referrals            
      option when it does not understand it or it does not allow this           
      option based on local policy.  The client SHOULD be capable of            
      processing the KDC responses when this option is not honored by           
      the KDC.  Clients SHOULD use TCP to contact a KDC if this option          
      is going to be used to avoid problems when the client's UDP               
      retransmit algorithm has timeouts insufficient to allow the KDC to        
      interact with remote KDCs.                                                

The question is do we actually want to take advantage of this
reservation and add the above to the referrals draft?

This text is intended to address r-6 and r-7 and the issue described in
section 5.5 of RFC 5868.

So, do we want to include this text?  Do we believe that saying SHOULD
TCP is sufficient advice to handle the fact that referrals requests may
take longer?

Is this sufficient detail or is more clarity required?

My default assumption is that we should include this text because we
seemed to have support for it while it was in the preauth draft, but
removed it only to remove the dependency.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Fri, 10 Jun 2011 12:31:57 -0400

> TCP is sufficient advice to handle the fact that referrals requests may

I have a weak preference for not including this text unless someone
knows of an implementation or planned implementation of functionality
like the follow-referrals bit.

My rationale:

* This seems like useful functionality from the client's point of view,
but problematic functionality to implement from the KDC's point of view.

* I don't want to complicate standards documents with verbiage about
features nobody is actually going to implement.

* Nothing prevents us from specifying this in a separate document at a
later time when there is more implementation interest.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jun 2011 16:13:10 -0400

OK. I'd like to hear a call from the chairs (I'm a document editor for
this document) on what to do here.
We had consensus for the text when it was in the preauth framework, but
we have a weak preference against now.
>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Thu, 2011-06-09 at 14:08 -0400, Sam Hartman wrote:
    >> So, do we want to include this text?  Do we believe that saying
    >> SHOULD TCP is sufficient advice to handle the fact that referrals
    >> requests may take longer?

    Greg> I have a weak preference for not including this text unless
    Greg> someone knows of an implementation or planned implementation
    Greg> of functionality like the follow-referrals bit.

    Greg> My rationale:

    Greg> * This seems like useful functionality from the client's point
    Greg> of view, but problematic functionality to implement from the
    Greg> KDC's point of view.

    Greg> * I don't want to complicate standards documents with verbiage
    Greg> about features nobody is actually going to implement.

    Greg> * Nothing prevents us from specifying this in a separate
    Greg> document at a later time when there is more implementation
    Greg> interest.