Subject: RE: Synopsis of Kerberos Revisions Comments by section

From: "John Brezak" <[email-masked]>
Date: Fri, 22 Sep 2000 18:23:08 -0700

Agreed. This is information that can be returned in the referral.

> -----Original Message-----
> From: Jonathan Trostle [mailto:[email-masked]]
> Sent: Friday, September 22, 2000 1:10 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Synopsis of Kerberos Revisions Comments by section
> 
> 
> I'd like to see the following ASN.1 structure included in the 
> ticket extension
> types:
> 
> KRB-TE-REFERRAL  :: =  SEQUENCE { 
>       referred-realm[0]                   Realm, 
>       referred-server-names[1]    SEQUENCE OF PrincipalNames OPTIONAL 
> } 
> 
> The ASN.1 encoded data should be encrypted using the same key 
> that encrypts the
> encrypted part of the KDC reply message.
> 
> Jonathan
> 
> 
> At 10:51 AM 9/21/00 -0500, Douglas E. Engert wrote:
> >Cliff asked me to summarize the comments sent in so far
> >for the Kerberos Revisions. This will help him in his editing.
> >If I have misinterpreted anyone's notes, please let me know.
> >
> >
> >Section 1:
> >(Cliff has already started editing this section, So I will not
> >summarize the comments. Name canonicalization and referrals where
> >the main discussion points.) 
> >
> >Section 2:
> >  Doug Engert: 8/8/00 2.9.1 Minor editing. What are "common Names"
> >
> >  Jeffrey Hutzelman 8/8/00 2.9 Name canonicalization is to vague,
> >    implying it could be used as substitute for DNS. This should be 
> >    avoided. 
> >  
> >Section 3:
> >  Martin Rex: 8/24/00 (2 notes) Worried about KERB_ERROR message
> >    being checksumed using user's private key, might be easier to 
> >    mount a dictionary attack. 
> >
> >  Cliff Nueman 8/24/00 responded that 5.9.1 addresses the issue.
> >   (DEE: Maybe Section 3.1 should had a reference to 5.9.1)
> >
> >  
> >   Ken Raeburn 8/24/00 Comments on the mark-up language use in these
> >     
> >Section 4:
> >  Nicolas Williams 9/11/00 Section 4 must be a guideline only. 
> >   
> >  Booker C. Bense and Nicolas Williams 9/13/00 discussed a 
> number of issues
> >    with allowing key to be retrieved from the database for servers
> >    which share the same key. They also discussed the use of hardware
> >    encryption devices to store keys. 
> >
> >  Ken Hornstein 9/13/00 Has no problems with transferring 
> for a key for 
> >   servers which share the same key.  
> > 
> > Broker C. Bense 9/15/00 Concerns about synchronizing the 
> distribution
> >  of shared keys. If client password/key change code could 
> store to local 
> >  disk before the updating KDC database he could live with this. 
> >    
> >  
> >  (DEE: This discussion is not complete, and no specific 
> changes to the
> >   draft where proposed. Would Nicolas and Brooker (and 
> anyone else) care 
> >   to continue the discussion, with regard to Hardware encryption,
> >   servers with shared keys, and replicated KDCs and suggest 
> any changes 
> >   to the document if changes are needed to support these devices? )
> >
> >Section 5:
> >    No comments
> >
> >Section 6:
> >    Not released yet
> >
> >Section 7:
> >   Pat Moore 7/14/00 Needs support for SRV_HST where the service name
> >     is separated by / and the host is the final component. 
> The current 
> >     draft does not support this. Pat gave updated text for 
> the Revisions,
> >     and suggested as an alternative a NT_CPLXSRV_HST. 
> Compatibility with 
> >GSSAPI
> >     is critical, and SRV_HST could map gss_nt_servoce_name 
> to NT_SRV_HST.
> >
> >  Sam Hartman 9/18/00 Commented on the use of name types as 
> specified in the
> >     document.  He could send text on this, but would argue 
> they should not
> >     be used at all. 
> >
> >    (DEE: Further discussion on this is welcome.)
> >
> >Section 8:
> >    Released yesterday.
> >    Ken Raeburn 9/20/00 COmments on not allowing IPv4 
> loopback address. 
> >    Port 88 should be the suggest stand port, but others 
> could be used.
> >    Questions on ow TCP connections to the KDC should be 
> closed. Questions
> >    on the extension of the length field used with TCP. Pointed out
> >    inconsistencies with name types table. He also questions 
> why internal
> >    errors in the database have separate error code and sent 
> to the client.
> > 
> >Section 9:
> >    Released yesterday, no comments yet. 
> >
> >
> >
> >
> >
> >Section 9: 
> >    Released yesterday.
> > 
> >
> >
> >    
> >   
> >
> >
> >
> >  
> >
> > 
> >
> >
> >-- 
> >
> > Douglas E. Engert  <[email-masked]>
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois  60439 
> > (630) 252-5444
>