headers
Ken Raeburn | 1 Oct 2002 17:07
Picon
Favicon

Re: KRB-WG Interim Meeting Tommorrow

Simon Josefsson <simon+ietf-krb-wg <at> josefsson.org> writes:
> I have some on draft-ietf-krb-wg-crypto-01.txt.  I hope that draft is
> part of Clarifications, if not please ignore this.

Yes, and I meant to reply to your earlier email to me on these.

I think I've incorporated all your changes at this point, and they're
in the new draft I submitted this morning (copy also at
www.mit.edu/~raeburn/kcrypto.txt), although I haven't rebuilt my test
code to confirm the error in the string-to-key test vectors.

Thanks for sending them in!  I'm glad to see someone other than me is
actually looking at the crypto draft. :-)

Ken

P.S.  The new draft also has added hooks in the simplified profile to
support truncated HMACs (see RFC 2104 section 5) and cipher text
stealing, for use in AES.  The updated AES draft will be coming out a
little later.
Permalink | Reply | 0 comments |
headers
crawdad+gridsec | 1 Oct 2002 20:34
Favicon

Re: [security-wg] Re: bridging of Kerberos realms

> As Derek pointed out, this then is a problem of determine the path to use
> between the three realms. U determines that to get to R, it needs to get a
> TGT from X for B, then gets a TGT from B to Y. 
> 
> All this code is in place, including the [capath] section. (That's
> Configurable Authentication path) which could define X->B->Y as the path.

Hm.  That could easily go into DNS.  At least, less easily than the
name of the host's realm and locations of the realm's KDCs.
Something like:

FOREIGN-REALM._kerberos.LOCAL-REALM. TXT "TRANSIT-REALM-1" "TRANSIT-REALM-2"
				     TXT "TRANSIT-REALM-1a" "TRANSIT-REALM-2b"

I've illustrated an uglier-than-normal case there the client has a
choice of going by either of two three-step paths.
Permalink | Reply | 4 comments |
headers
Douglas E. Engert | 1 Oct 2002 22:28
Favicon

Re: [security-wg] Re: bridging of Kerberos realms

BUT Then you are trusting DNS to tell you what realms can be in the trust
path, and no way to verifiy that this is correct.     

crawdad+gridsec <at> fnal.gov, crawdad+krb-wg <at> gungnir.fnal.gov wrote:
> 
> > As Derek pointed out, this then is a problem of determine the path to use
> > between the three realms. U determines that to get to R, it needs to get a
> > TGT from X for B, then gets a TGT from B to Y.
> >
> > All this code is in place, including the [capath] section. (That's
> > Configurable Authentication path) which could define X->B->Y as the path.
> 
> Hm.  That could easily go into DNS.  At least, less easily than the
> name of the host's realm and locations of the realm's KDCs.
> Something like:
> 
> FOREIGN-REALM._kerberos.LOCAL-REALM. TXT "TRANSIT-REALM-1" "TRANSIT-REALM-2"
>                                      TXT "TRANSIT-REALM-1a" "TRANSIT-REALM-2b"
> 
> I've illustrated an uglier-than-normal case there the client has a
> choice of going by either of two three-step paths.

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
(Continue reading)

Permalink | Reply | 3 comments |
headers
crawdad+gridsec | 1 Oct 2002 22:36
Favicon

Re: [security-wg] Re: bridging of Kerberos realms

I would never trust DNS that far!  I was just thinking of helping the
client.  The service's realm's KDC and/or the service itself should
still make whatever checks they deem necessary.

> BUT Then you are trusting DNS to tell you what realms can be in the trust
> path, and no way to verifiy that this is correct.     
> > ...
> > Hm.  That could easily go into DNS.  At least, no less easily than the
> > name of the host's realm and locations of the realm's KDCs.
Permalink | Reply | 2 comments |
headers
Douglas E. Engert | 1 Oct 2002 23:13
Favicon

Re: [security-wg] Re: bridging of Kerberos realms


crawdad+gridsec <at> fnal.gov, crawdad+krb-wg <at> gungnir.fnal.gov wrote:
> 
> I would never trust DNS that far!  I was just thinking of helping the
> client.  The service's realm's KDC and/or the service itself should
> still make whatever checks they deem necessary.

But you also don't want the client delegating to the wrong service. 
If the client can't trust the path, this can happen too.

> 
> > BUT Then you are trusting DNS to tell you what realms can be in the trust
> > path, and no way to verifiy that this is correct.
> > > ...
> > > Hm.  That could easily go into DNS.  At least, no less easily than the
> > > name of the host's realm and locations of the realm's KDCs.

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
Permalink | Reply | 1 comment |
headers
Douglas E. Engert | 1 Oct 2002 23:21
Favicon

Updates for KRB-WG Clarifications

During the interim meeting today the http://www.kerberos.isi.edu/
page has had major updates.  Please review these tonight and get
comments with section numbers to the list be tomorrow morning. 

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
Permalink | Reply | 0 comments |
headers
Lawrence Greenfield | 1 Oct 2002 22:10
Picon

section 1.2

If I can decipher the web page to understand what's the latest and
greatest up to the minute draft, I just wanted to say I'm very happy
with what I see as section 1.2 right now.

That's
<http://www.isi.edu/people/bcn/krb-revisions/krbclar1-3.html>

It addresses all of my concerns with previous text/footnotes.

thanks,
Larry
Permalink | Reply | 0 comments |
headers
Douglas E. Engert | 2 Oct 2002 14:31
Favicon

Editing and content comments + Security concern

3.1.3 p3  "If there is more than one supported strong encryption type in the etype 
           list, the first valid etype..." Should it read the first strong valid etype..."

3.1.5 p2 " user user "

3.3.1 p2 Using a network service to obtain the configuration path could be a point of
attack,
if the network service was to return a path which was not the "correct" path. This could
lead
a valid KDC but one not on the correct path to substitute its own path to the expect
expected,
realm, so it can impersonate a host, so as to obtain a forward credential of a user. 
For example, A, B, C and H are realms. B shared keys with a A, C and H. user <at> A wants to get
to
server <at> C. Hackers control DNS, which might be used as the network service. Network service
should return path as A, B, C, but returns A, B, H, C. H and DNS then routes the user to 
a dummy realm C, which returns dummy server <at> C. User then forwards TGT to the dummy server.
which is then used to attack impersonate the user in any realm.  
Moral of the story: User must trust the network service to return valid path. 
Because of section 3.3.3 p2 "closest" This attack may only work if clint  had contacted a 
service in H first, and had a TGT for H, and thought the path to C was via H.   

 
3.4.1 "Transfer interrupted"...

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
(Continue reading)

Permalink | Reply | 0 comments |
headers
crawdad+gridsec | 1 Oct 2002 23:58
Favicon

Re: [security-wg] Re: bridging of Kerberos realms

> > I would never trust DNS that far!  I was just thinking of helping the
> > client.  The service's realm's KDC and/or the service itself should
> > still make whatever checks they deem necessary.
> 
> But you also don't want the client delegating to the wrong service. 
> If the client can't trust the path, this can happen too.

Ah, I see I still don't have the griddish "of course you always
delegate" mindset ... even though I usually do delegate.

OK, it can stay in [capaths], although shorter realm paths are of
course better.  (Ever try to convince yourself to trust a PGP key
five "handshakes" from your own?  Then you know the feeling.)
Permalink | Reply | 0 comments |
headers
Douglas E. Engert | 2 Oct 2002 14:31
Favicon

Security concerns list


  3.1  Use preauth...

  3.1.2 Use replay cache

  3.1.5 For login, get TGT, and get server ticket for host

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
Permalink | Reply | 0 comments |

Gmane