(mk|rd)_(priv|safe) and NAT
I'm still in the process of getting my app and server up and running with kerberos, so I can't test this yet, but the code for mk_priv/rd_priv and mk_safe/rd_safe seems to want addresses set on the auth_context, and all the samples show various permutations of this. I'm doing NAT traversal/punchthrough potentially on both sides of the connection, maybe even with a relay server in the middle for really bad cases, so there are a lot of potential addresses in play here. Which addresses do I set in a NAT-heavy environment like this? It looks like the mk versions require a local address set, and the rd versions require the remote address set (presumably to the local address set when the mk is called?). I'm going to be sending safe/priv messages both directions... I'm doing full mutual authentication with subkeys in both directions to avoid the need for a replay cache, if that matters. I found a post[*] that said kerberos was moving away from addresses since they're not very secure, but the current code seems to require them for these functions at least. Thanks, Chris * http://mailman.mit.edu/pipermail/kerberos/2007-December/012743.html Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
It almost looks like I can just set 1.2.3.4:5 for the address of any host behind a NAT, since at that point the code doesn't actually talk to the internet. Is there a security implication for doing that, given that tickets have already moved away from containing addresses? Thanks, Chris On 2011/08/03 00:11, Chris Hecker wrote: I'm still in the process of getting my app and server up and running with kerberos, so I can't test this yet, but the code for mk_priv/rd_priv and mk_safe/rd_safe seems to want addresses set on the auth_context, and all the samples show various permutations of this. I'm doing NAT traversal/punchthrough potentially on both sides of the connection, maybe even with a relay server in the middle for really bad cases, so there are a lot of potential addresses in play here. Which addresses do I set in a NAT-heavy environment like this? It looks like the mk versions require a local address set, and the rd versions require the remote address set (presumably to the local address set when the mk is called?). I'm going to be sending safe/priv messages both directions... I'm doing full mutual authentication with subkeys in both directions to avoid the need for a replay cache, if that matters. I found a post[*] that said kerberos was moving away from addresses since they're not very secure, but the current code seems to require them for these functions at least. Thanks, Chris * http://mailman.mit.edu/pipermail/kerberos/2007-December/012743.html Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
Is there a reason you are using mk|rd_priv|safe instead of gss? On 8/3/2011 3:47 AM, Chris Hecker wrote: It almost looks like I can just set 1.2.3.4:5 for the address of any host behind a NAT, since at that point the code doesn't actually talk to the internet. Is there a security implication for doing that, given that tickets have already moved away from containing addresses? Thanks, Chris On 2011/08/03 00:11, Chris Hecker wrote: I'm still in the process of getting my app and server up and running with kerberos, so I can't test this yet, but the code for mk_priv/rd_priv and mk_safe/rd_safe seems to want addresses set on the auth_context, and all the samples show various permutations of this. I'm doing NAT traversal/punchthrough potentially on both sides of the connection, maybe even with a relay server in the middle for really bad cases, so there are a lot of potential addresses in play here. Which addresses do I set in a NAT-heavy environment like this? It looks like the mk versions require a local address set, and the rd versions require the remote address set (presumably to the local address set when the mk is called?). I'm going to be sending safe/priv messages both directions... I'm doing full mutual authentication with subkeys in both directions to avoid the need for a replay cache, if that matters. I found a post[*] that said kerberos was moving away from addresses since they're not very secure, but the current code seems to require them for these functions at least. Thanks, Chris * http://mailman.mit.edu/pipermail/kerberos/2007-December/012743.html Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: problem using disable_last_success
Thanks Greg! I'll try a restart later this evening. Working great now. Thanks again. -ds -- Dave Steiner stei...@rutgers.edu Identity Management, ESS ASB101; 732.445.5433 Rutgers University, Office of Information Technology Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
Thanks for the detailed response! 1. Set fake sender and receiver addresses. You might consider using different fake addresses for the initiator and the receiver, effectively converting the IP addresses into directional addresses. Yeah, I have another channel of information flowing to both parties from the lobby server, so I can actually send them both a mk_priv message from the lobby with the addresses to stuff in the client-client auth_context, which will also help a bit. Reflection isn't a problem in my protocol anyway, I think. the do-sequence auth context flag addresses both concerns, if you're using a sequential transport such as TCP. This brings up the question of what to do in unordered/unreliable situations? I have a UDP stream between clients that's a mix of ordered/reliable pseudo-tcp messages and unordered/unreliable messages. My original plan was to use the pseudo-tcp messages to negotiate the u2u auth_contexts, but I also want to be able to mk_safe/mk_priv on the unreliable messages. Do I need two auth_contexts in that case, one without do-sequence set? Chris On 2011/08/03 08:48, Greg Hudson wrote: On Wed, 2011-08-03 at 03:11 -0400, Chris Hecker wrote: I'm still in the process of getting my app and server up and running with kerberos, so I can't test this yet, but the code for mk_priv/rd_priv and mk_safe/rd_safe seems to want addresses set on the auth_context, and all the samples show various permutations of this. There are basically two concerns with these messages: replays and reflections. Checking sender addresses helps very minimally against replays (in that an attacker might need to forge the sender IP address when replaying the packet) and prevents reflections. I believe setting the do-sequence auth context flag addresses both concerns, if you're using a sequential transport such as TCP. Because of NAT issues, we are probably going to make a change in 1.10 so that acceptors aren't required to set the remote address (in which case it won't be checked). It would then become the responsibility of the caller to prevent reflection attacks, either by setting the do-sequence flag or just using an app protocol where messages from the initiator can't be confused for messages from the acceptor and vice versa. By the time GSSAPI-krb5 rolled around, it was agreed that a wrap token format should not include addresses, but should instead distinguish initiator messages from acceptor messages to prevent reflections. So, GSSAPI-krb5 tokens look that way. There is also text in RFC 4120 for directional addresses in krb-safe and krb-priv messages, but that isn't implemented in MIT krb5 or Heimdal. From your point of view, you have a couple of options: 1. Set fake sender and receiver addresses. You might consider using different fake addresses for the initiator and the receiver, effectively converting the IP addresses into directional addresses. 2. Hack the krb5 code to do what we're likely to do in 1.10, skip address verification, and deal with reflection attacks in your application protocol. Jeff Altman wrote: Is there a reason you are using mk|rd_priv|safe instead of gss? See http://mailman.mit.edu/pipermail/kerberos/2011-July/017444.html and following. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
By default, an auth context will use a replay cache to prevent replays (this is controlled by the do-time flag). Right, but I'm going to force the replay cache off and use subkeys like we discussed in the other thread. I assume I can't use the do-sequence flag on an unordered/unreliable channel? So, if I want to mk_priv/safe on that channel, will I need another auth_context? Not sure if that makes sense? If not, I can try to explain it better. Chris On 2011/08/03 14:39, Greg Hudson wrote: On Wed, 2011-08-03 at 16:56 -0400, Chris Hecker wrote: This brings up the question of what to do in unordered/unreliable situations? I have a UDP stream between clients that's a mix of ordered/reliable pseudo-tcp messages and unordered/unreliable messages. My original plan was to use the pseudo-tcp messages to negotiate the u2u auth_contexts, but I also want to be able to mk_safe/mk_priv on the unreliable messages. Do I need two auth_contexts in that case, one without do-sequence set? By default, an auth context will use a replay cache to prevent replays (this is controlled by the do-time flag). Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
On Wed, 2011-08-03 at 17:47 -0400, Chris Hecker wrote: Right, but I'm going to force the replay cache off and use subkeys like we discussed in the other thread. I assume I can't use the do-sequence flag on an unordered/unreliable channel? So, if I want to mk_priv/safe on that channel, will I need another auth_context? Yes, you will need separate auth contexts if you want to use sequence numbers on some messages but not others. For the unordered messages, since you are using neither sequence numbers nor a replay cache, you'll need to address replays at the application protocol layer. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: (mk|rd)_(priv|safe) and NAT
Yes, you will need separate auth contexts if you want to use sequence numbers on some messages but not others. That's what I figured. I'll have to mk_req/rd_req/mk_rep/rd_rep both on the ordered and unordered channels (which, sadly, are on the same UDP socket, so it's kind of silly...) to generate the auth_contexts correctly, right? Chris On 2011/08/03 15:13, Greg Hudson wrote: On Wed, 2011-08-03 at 17:47 -0400, Chris Hecker wrote: Right, but I'm going to force the replay cache off and use subkeys like we discussed in the other thread. I assume I can't use the do-sequence flag on an unordered/unreliable channel? So, if I want to mk_priv/safe on that channel, will I need another auth_context? Yes, you will need separate auth contexts if you want to use sequence numbers on some messages but not others. For the unordered messages, since you are using neither sequence numbers nor a replay cache, you'll need to address replays at the application protocol layer. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
RFC: krb5 manual pages becoming groff-only?
Upcoming changes to the MIT krb5 documentation could cause our manual pages to become unreadable on Unix systems where the man program uses a Unix (ATT-derived) nroff program instead of the GNU version (groff). We would appreciate some feedback about this possibility. We're soliciting feedback both from people who build our software from source code, and from redistributors who might customize our software. Our existing manual pages are hand-coded nroff in the traditional Unix .man format. As part of an effort to improve our documentation, we are experimenting with consolidating our various documentation sources (including Unix man pages) into Sphinx (http://sphinx.pocoo.org/) reStructuredText format. The following questions are directly primarily at people who deal with Unix systems whose man program runs a Unix nroff rather than groff. More background information follows these questions. 1. How much will you be inconvenienced if the krb5 manual pages became groff-only? 2. If you're a redistributor, would you translate (manually or automatically) our groff-only manual pages into a Unix-compatible nroff format? If not, would you instead be willing to distribute our manual pages in a preformatted (catman) form only? 3. Are you willing to help revise the Docutils manpage writer (used by Sphinx to generate manpages) so that it generates manual pages compatible with Unix nroff? 4. What other alternatives do you think we should consider for this situation? Additional background: Sphinx (in releases 1.0 and later, which are not yet available in some OS distributions) is capable of generating Unix manual pages, but these generated manual pages rely on GNU extensions to nroff. These generated manual pages do not render correctly on a Unix version of nroff. (tested on Solaris 10; some Linux OSes and some BSD derivatives seem to ship with groff) While it's possible that the manual page writer component of Sphinx (actually a Docutils component used by Sphinx) could be changed to generate manual page output that renders correctly under traditional Unix nroff, such changes would take some time to implement and to propagate through their release process. We could develop our own replacement for that component, but that creates more maintenance difficulties for us. It is very likely that we will either generate the manual pages from Sphinx when we build release tarfiles, or periodically check in generated manual pages to the source repository as needed. This avoids requiring casual builders to install the most recent version of Sphinx (which might not be readily available on their OSes), but does not necessarily remove the requirement to have groff available. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
