Groups | Search | Server Info | Login | Register
Groups > comp.protocols.kerberos > #5355
| From | Ken Hornstein <kenh@cmf.nrl.navy.mil> |
|---|---|
| Newsgroups | comp.protocols.kerberos |
| Subject | Why do "strict acceptor checking"? |
| Date | 2024-10-07 20:23 -0400 |
| Organization | TNet Consulting |
| Message-ID | <mailman.126.1728347015.2322.kerberos@mit.edu> (permalink) |
| References | <202410080023.4980NSGB010697@hedwig.cmf.nrl.navy.mil> |
Twice this week I have helped other sites deal with issues related to "strict acceptor checking" (the programs in question were sshd and sudo). Both of these programs explicitly have code that constructs a service name based on the value of gethostname() and thus will only accept a service ticket for that name regardless of what's actually in the keytab, and this fails in a number of complicated multihomed networking situations (sudo does this for the service principal passed to krb5_verify_init_creds()). At least in the case of sshd there is an explicit knob to turn this off. However, this has made me wonder: why do this at all? What is the possible security gain here? It's not the default in the code; you have to explicitly write code to enable this behavior. But I can't really think of a case where NOT having strict acceptor checking is a security problem; I could maybe squint and envision some kind of weird hosted server setup where it might matter, but I'm not sure that is ever done in the real world. I will admit it is entirely possible I am missing something; if I am, I'd sure like to understand what I am missing. --Ken
Back to comp.protocols.kerberos | Previous | Next | Find similar
Why do "strict acceptor checking"? Ken Hornstein <kenh@cmf.nrl.navy.mil> - 2024-10-07 20:23 -0400
csiph-web