krb524 and port 4444 blocks

[James Reynolds]

I was wondering if the delay associated with krb5 and a blocked 4444
port have been addressed. The delay is talked about in this email:
http://mailman.mit.edu/pipermail/krbdev/2002/000985.html

Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4. We
are seeing the ~21 second delay. We would like this to go away.

Do you have any recommendations? Should we poke a hole for port
4444? Should we downgrade to kerberos 4? Is it possible to get
krb524 to not do anything? Is there some other work around?

--

Thanks,

James Reynolds
University of Utah
Student Computing Labs
***@scl.utah.edu
801-585-9811

[Douglas E. Engert]

Post by James Reynolds
I was wondering if the delay associated with krb5 and a blocked 4444
http://mailman.mit.edu/pipermail/krbdev/2002/000985.html
Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4. We
are seeing the ~21 second delay. We would like this to go away.
Do you have any recommendations? Should we poke a hole for port
4444? Should we downgrade to kerberos 4? Is it possible to get
krb524 to not do anything? Is there some other work around?

Sounds like the login is trying to get you a K4 ticket automaticly
even if you don't want it. Is there something in the krb5.conf
on the Mac OS X that is doing this? Is there somthing like:

[login]
krb5_convet = true

The documentation says:

krb4_convert
Indicate whether or not to use the Kerberos conversion daemon to get V4 tickets.
The default value is false. If this is set to false and krb4_get_tickets is true,
then login will get the V5 tickets directly using the Kerberos V4 protocol
directly. This does not currently work with non-MIT-V4 salt types (such as the AFS3
salt type). Note that if this is set to true and krb524d is not running, login will
hang for approximately a minute under Solaris, due to a Solaris socket emulation
bug.

This sounds similiar.

Post by James Reynolds
--
Thanks,
James Reynolds
University of Utah
Student Computing Labs
801-585-9811
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[James Reynolds]

Post by Douglas E. Engert

Post by James Reynolds
I was wondering if the delay associated with krb5 and a blocked 4444
http://mailman.mit.edu/pipermail/krbdev/2002/000985.html
Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4. We
are seeing the ~21 second delay. We would like this to go away.
Do you have any recommendations? Should we poke a hole for port
4444? Should we downgrade to kerberos 4? Is it possible to get
krb524 to not do anything? Is there some other work around?

Sounds like the login is trying to get you a K4 ticket automaticly
even if you don't want it. Is there something in the krb5.conf
[login]
krb5_convet = true
krb4_convert
Indicate whether or not to use the Kerberos conversion daemon to get V4 tickets.
The default value is false. If this is set to false and
krb4_get_tickets is true,
then login will get the V5 tickets directly using the Kerberos V4 protocol
directly. This does not currently work with non-MIT-V4 salt types (such as the AFS3
salt type). Note that if this is set to true and krb524d is not running, login will
hang for approximately a minute under Solaris, due to a Solaris socket emulation
bug.
This sounds similiar.

Just to check, I added them to the preferences file and it didn't help.

I tried:

[login]
krb5_convert = false

and

[login]
krb5_convert = false
krb5_get_tickets = false

And just in case I misunderstood, I tried this as well:

[login]
krb4_convert = false

and

[login]
krb4_convert = false
krb4_get_tickets = false

--

Thanks,

James Reynolds
University of Utah
Student Computing Labs
***@scl.utah.edu
801-585-9811

[James Reynolds]

I just tested the following command:

sudo ipfw add unreach port udp from me to any krb524

and it successfully kills the delay. We are going to implement this
on our lab computers, so, problem solved as far as we are concerned.
We figure nothing is really going to be using port 4444 anymore since
W32.BLASTER.WORM basically took it over.

Wouldn't it suck if a worm took over a common port like 80? Can't
block that at the router. Ouch...

Thanks everyone who responded and helped.

--

Thanks,

James Reynolds
University of Utah
Student Computing Labs
***@scl.utah.edu
801-585-9811

Post by James Reynolds
Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4.
We are seeing the ~21 second delay. We would like this to go away.
Do you have any recommendations? Should we poke a hole for port
4444? Should we downgrade to kerberos 4? Is it possible to get
krb524 to not do anything? Is there some other work around?

There is no way to disable this with the version of Kerberos for
Macintosh included with Mac OS X 10.2. If you have Kerberos v5
enabled, it always tries to contact the krb524 service on your KDCs.
If UDP packages on port 4444 cannot make it to the KDC, or the ICMP
port unreachable messages can't make it back, then the Kerberos
libraries have to wait for the attempt to time out. At Stanford, we
originally saw thisy with users behind NAT firewalls which often did
not forward ICMP messages, and more with campus firewalls that block
port 4444 because of a Windows virus.
The best solution we came up with was to have affected users run the
sudo ipfw add unreach port udp from me to any krb524
This adds a firewall rule to Mac OS X that immediately fails any
attempt to contact the krb524 port (4444) on another host. This
eliminates the delay, but it creates a few other problems, including
blocking any legitimate use of UDP on port 4444. It also disables
Mac OS X's built in Internet Firewall preferences, so Stanford only
hands out the command (I think we built an app that runs it for you)
to users who complain about this.
--

Post by James Reynolds
Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4.
We are seeing the ~21 second delay. We would like this to go away.
Do you have any recommendations? Should we poke a hole for port
4444? Should we downgrade to kerberos 4? Is it possible to get
krb524 to not do anything? Is there some other work around?

There is no way to disable this with the version of Kerberos for
Macintosh included with Mac OS X 10.2. If you have Kerberos v5
enabled, it always tries to contact the krb524 service on your KDCs.
If UDP packages on port 4444 cannot make it to the KDC, or the ICMP
port unreachable messages can't make it back, then the Kerberos
libraries have to wait for the attempt to time out. At Stanford, we
originally saw thisy with users behind NAT firewalls which often did
not forward ICMP messages, and more with campus firewalls that block
port 4444 because of a Windows virus.
The best solution we came up with was to have affected users run the
sudo ipfw add unreach port udp from me to any krb524
This adds a firewall rule to Mac OS X that immediately fails any
attempt to contact the krb524 port (4444) on another host. This
eliminates the delay, but it creates a few other problems, including
blocking any legitimate use of UDP on port 4444. It also disables
Mac OS X's built in Internet Firewall preferences, so Stanford only
hands out the command (I think we built an app that runs it for you)
to users who complain about this.
--

[Alexei Kosut]

Post by James Reynolds
Specifically, we are using kerberos 5 to authenticate our Mac OS X
computers and we don't reuse tickets and we don't use kerberos 4. We
are seeing the ~21 second delay. We would like this to go away.
Do you have any recommendations? Should we poke a hole for port 4444?
Should we downgrade to kerberos 4? Is it possible to get krb524 to
not do anything? Is there some other work around?

There is no way to disable this with the version of Kerberos for
Macintosh included with Mac OS X 10.2. If you have Kerberos v5
enabled, it always tries to contact the krb524 service on your KDCs.
If UDP packages on port 4444 cannot make it to the KDC, or the ICMP
port unreachable messages can't make it back, then the Kerberos
libraries have to wait for the attempt to time out. At Stanford, we
originally saw thisy with users behind NAT firewalls which often did
not forward ICMP messages, and more with campus firewalls that block
port 4444 because of a Windows virus.

The best solution we came up with was to have affected users run the
following command from a Terminal prompt:

sudo ipfw add unreach port udp from me to any krb524

This adds a firewall rule to Mac OS X that immediately fails any
attempt to contact the krb524 port (4444) on another host. This
eliminates the delay, but it creates a few other problems, including
blocking any legitimate use of UDP on port 4444. It also disables Mac
OS X's built in Internet Firewall preferences, so Stanford only hands
out the command (I think we built an app that runs it for you) to users
who complain about this.

[Sam Hartman]

James> I was wondering if the delay associated with krb5 and a
James> blocked 4444 port have been addressed. The delay is talked
James> about in this email:
James> http://mailman.mit.edu/pipermail/krbdev/2002/000985.html


Fix your firewall to return port unreachable messages if it is going
to block packets.