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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 17 Feb 2004 09:09:03 -0800

Nicolas.Williams wrote:
> 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?

In our current implementation, this realm name is the realm of the KDC
this AS_REQ is sent to, not the "true" realm of the client.  

> 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.

The sname and realm in the request are protected by the authenticator
checksum in PA_TGS_AP_REQ, and the referred names in the reply are
protected by this subkey, which prevents the PA data from being stripped
out by disturbing the key derivation. Is the protection here adequate?

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2004 8:26 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-krb-wg-kerberos-referrals-03.txt

On Mon, Feb 16, 2004 at 10:57:21PM -0800, Liqiang(Larry) Zhu wrote:
> 
> 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 --,

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

> > - 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 

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?

> > - 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?

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
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Feb 2004 11:42:05 -0600

> this AS_REQ is sent to, not the "true" realm of the client.  

We're talking TGS-REQs here.

Also, a single KDC can serve multiple realms.

> out by disturbing the key derivation. Is the protection here adequate?

I'll think about this a little more -- somethin makes me uncomfortable.