Subject: RE: I-D ACTION:draft-ietf-krb-wg-kerberos-referrals-03.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 16 Feb 2004 22:57:21 -0800

Nicolas Williams wrote:
> - The text assumes there's a "service realm name" ("srealm") in a KDC
>   request -- not so, there's a single field of type Realm in a KDC
>   request and it applies to both, the client principal name and the
>   service principal name.

on page 122, I saw the following text

   KDC-REQ-BODY    ::= SEQUENCE {
           kdc-options             [0] KDCOptions,
           cname                   [1] PrincipalName OPTIONAL
                                       -- Used only in AS-REQ --,
           realm                   [2] Realm
                                       -- Server's realm
                                       -- Also client's in AS-REQ --,

> - The text assumes that the realm ("srealm," as per the draft) field
of
>   a KDC-REQ body can be null or left out ("When using
canonicalization,
>   the client can omit the service realm name...").

You are correct 

> - The text refers to KERB-ENCRYPTED-DATA -- presumably EncryptedData
>   was intended.

You are correct

> - Is there any pre-auth data in a x-realm TGT reply to a request, w/

>   the "canonicalize" KDC option set, for a servive principal?

>   How is the client to be assured that the KDC exchange has not been
>   tampered with?

>  PA-SERVER-REFERRAL-DATA protects the canonicalized service name but

>   provides no binding to the requested name, unless we expect the KDC
>   to set sname/srealm in the KDC-REP encpart to that requested by the
>   client, but this is not clear from the text.

Would it work if we throw in a subkey here (see below), and the
encrypted KDC reply is encrypted with this subkey if a
PA-SERVER-REFERRAL is sent in the KDC reply?

                PA-SERVER-REFERRAL-INFO        25 
                 
                PA-SERVER-REFERRAL :: = EncryptedData  
                                           -- PA-SERVER-REFERRAL-DATA 
                 
                PA-SERVER-REFERRAL-DATA ::= SEQUENCE { 
                        referred-server-realm [0]  KERB-REALM, 
                        referred-name         [1]  PrincipalName
OPTIONAL,
                        subkey                [2]  EncryptionKey,
                        ... 
 
                }

Thanks, Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Monday, February 16, 2004 2:08 PM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-krb-wg-kerberos-referrals-03.txt

On Mon, Feb 16, 2004 at 03:39:29PM -0500, [email-masked]
wrote:
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals
-03.txt

I've cursorily read this I-D.  Here's some comments:

 - The text assumes there's a "service realm name" ("srealm") in a KDC
   request -- not so, there's a single field of type Realm in a KDC
   request and it applies to both, the client principal name and the
   service principal name.

 - The text assumes that the realm ("srealm," as per the draft) field of
   a KDC-REQ body can be null or left out ("When using canonicalization,
   the client can omit the service realm name...").

   The realm field is NOT OPTIONAL and was never intended to hold a null
   name.

 - The text refers to KERB-ENCRYPTED-DATA -- presumably EncryptedData
   was intended.

 - Is there any pre-auth data in a x-realm TGT reply to a request, w/
   the "canonicalize" KDC option set, for a servive principal?

   How is the client to be assured that the KDC exchange has not been
   tampered with?

   PA-SERVER-REFERRAL-DATA protects the canonicalized service name but
   provides no binding to the requested name, unless we expect the KDC
   to set sname/srealm in the KDC-REP encpart to that requested by the
   client, but this is not clear from the text.

 - Nit: non-ASCII and/or non-spacing control characters are present in
   the draft.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 10:25:59 -0600

>                                        -- Also client's in AS-REQ --,

Ah, yes, ok.  So simply change "srealm" in request contexts to "realm."

> >   the client can omit the service realm name...").

I'm also right about that field not being optional, so presumably you're
saying is that what should be sent is an empty string?

> PA-SERVER-REFERRAL is sent in the KDC reply?

It's not about keying -- it's about having both, the sname/realm
requested by the client and the referred-to sname/realm be protected in
the reply.  The use of PA for this is a fine hack though.

Nico
--