Date: Thu, 15 May 2014 02:46:04 +0000 (UTC) From: Benjamin Kaduk <bjk@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44840 - head/en_US.ISO8859-1/books/handbook/security Message-ID: <201405150246.s4F2k4vm007732@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bjk Date: Thu May 15 02:46:04 2014 New Revision: 44840 URL: http://svnweb.freebsd.org/changeset/doc/44840 Log: Technical review of the Kerberos chapter Many of the statements in this chapter were just plain wrong. Apply some major modernization, in particular the current Kerberos RFC is 4120, not 1510. Kerberized telnet, rlogin, ftp and similar are no longer recommended -- use ssh and scp instead. The heimdal in base is no longer crippled so as to be a minimal installation; it is fully functional. The heimdal in ports does offer the option to install some additional features such as KCM and PKINIT. Add a bit more introduction to Kerberos terminology and conventions. Make the sample output closer to the current reality. Don't imply that eight characters is a particularly strong password. security/krb5 does not install ktelnetd, klogind, and friends anymore, so there's no need to mention its README.FreeBSD here (especially since these things are disrecommended anyway). www/mod_auth_kerb uses the HTTP/ principal, not the www/ principal. Kerberized ssh uses GSSAPI these days, so the Kerberos-specific options are not worth mentioning. Kerberos works just fine on multiuser machines; the permissions of credentials cache files are set to 0600. Remove the section on access issues with kerberos and ssh; it is very confused. (It seems to be talking about ssh keys and ssh-agent, but in a very unclear and inaccurate fashion.) There is still more to be done here, but this should get us most of the way. Reviewed by: bcr (partial) Approved by: hrs (mentor) Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 15 00:43:23 2014 (r44839) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 15 02:46:04 2014 (r44840) @@ -1095,10 +1095,11 @@ sendmail : PARANOID : deny</programlisti <para><application>Kerberos</application> is a network authentication protocol which was originally created by the Massachusetts Institute of Technology - (<acronym>MIT</acronym>) as a solution to network security - problems. The <application>Kerberos</application> protocol uses + (<acronym>MIT</acronym>) as a way to securely provide authentication + across a potentially hostile network. + The <application>Kerberos</application> protocol uses strong cryptography so that both a client and server can prove - their identity over an insecure network. + their identity without sending any unencrypted secrets over the network. <application>Kerberos</application> can be described as an identity-verifying proxy system and as a trusted third-party authentication system. After a user authenticates with @@ -1106,29 +1107,36 @@ sendmail : PARANOID : deny</programlisti encrypted to assure privacy and data integrity.</para> <para>The only function of <application>Kerberos</application> is - to provide the secure authentication of users on the network. + to provide the secure authentication of users and servers on the network. It does not provide authorization or auditing functions. It is recommended that <application>Kerberos</application> be used with other security methods which provide authorization and audit services.</para> <para>The current version of the protocol is version 5, described - in <acronym>RFC</acronym> 1510. Several free + in <acronym>RFC</acronym> 4120. Several free implementations of this protocol are available, covering a wide range of operating systems. <acronym>MIT</acronym> continues to develop their <application>Kerberos</application> package. It is commonly used in the <acronym>US</acronym> as a cryptography - product, and has historically been affected by + product, and has historically been subject to <acronym>US</acronym> export regulations. In &os;, <acronym>MIT</acronym> <application>Kerberos</application> is available as the <package>security/krb5</package> package or - port. Heimdal <application>Kerberos</application> was + port. The Heimdal <application>Kerberos</application> implementation was explicitly developed outside of the <acronym>US</acronym> to avoid export regulations. The Heimdal - <application>Kerberos</application> distribution is available as - the <package>security/heimdal</package> package or port, and a - minimal installation is included in the base &os; - install.</para> + <application>Kerberos</application> distribution is included in + the base &os; installation, and another distribution with more + configurable options is available as <package>security/heimdal</package> + in the Ports Collection.</para> + + <para>In <application>Kerberos</application> users and services are + identified as <quote>principals</quote> which are contained within + an administrative grouping, called a <quote>realm</quote>. A + typical user principal would be of the form + <literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal> + (realms are traditionally uppercase).</para> <para>This section provides a guide on how to set up <application>Kerberos</application> using the Heimdal @@ -1169,12 +1177,14 @@ sendmail : PARANOID : deny</programlisti <para>The Key Distribution Center (<acronym>KDC</acronym>) is the centralized authentication service that - <application>Kerberos</application> provides. It is the + <application>Kerberos</application> provides, the <quote>trusted + third party</quote> of the system. It is the computer that issues <application>Kerberos</application> - tickets. The <acronym>KDC</acronym> is considered trusted by + tickets, which are used for clients to authenticate to servers. + Because the <acronym>KDC</acronym> is considered trusted by all other computers in the - <application>Kerberos</application> realm, and thus has - heightened security concerns.</para> + <application>Kerberos</application> realm, it has heightened security + concerns. Direct access to the KDC should be limited.</para> <para>While running a <acronym>KDC</acronym> requires few computing resources, a dedicated machine acting only as a @@ -1202,20 +1212,23 @@ kadmind5_server_enable="YES"</programlis <para>In this example, the <acronym>KDC</acronym> will use the fully-qualified hostname <systemitem - class="fqdomainname">kerberos.example.org</systemitem>. Add - a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym> - zone file if the <acronym>KDC</acronym> has a different - hostname than that specified in - <filename>/etc/krb5.conf</filename>.</para> - - <para>For large networks with a properly configured - <acronym>DNS</acronym> server, the above example could be - trimmed to:</para> + class="fqdomainname">kerberos.example.org</systemitem>. The + hostname of the KDC must be resolvable in the + <acronym>DNS</acronym>.</para> + + <para><application>Kerberos</application> can also use the + <acronym>DNS</acronym> to locate KDCs, instead of a + <literal>[realms]</literal> section in + <filename>/etc/krb5.conf</filename>. For large organizations that + have their own <acronym>DNS</acronym> servers, the above example + could be trimmed to:</para> <programlisting>[libdefaults] - default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting> + default_realm = <replaceable>EXAMPLE.ORG</replaceable> +[domain_realm] + <replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting> - <para>With the following lines being appended to the + <para>With the following lines being included in the <systemitem class="fqdomainname">example.org</systemitem> zone file:</para> @@ -1227,8 +1240,8 @@ _kerberos IN TXT <replace <note> <para>In order for clients to be able to find the - <application>Kerberos</application> services, the - <acronym>KDC</acronym> <emphasis>must</emphasis> have either + <application>Kerberos</application> services, they + <emphasis>must</emphasis> have either a fully configured <filename>/etc/krb5.conf</filename> or a minimally configured <filename>/etc/krb5.conf</filename> <emphasis>and</emphasis> a properly configured @@ -1239,20 +1252,22 @@ _kerberos IN TXT <replace database which contains the keys of all principals (users and hosts) encrypted with a master password. It is not required to remember this password as it will be stored in - <filename>/var/heimdal/m-key</filename>. To create the master - key, run <command>kstash</command> and enter a + <filename>/var/heimdal/m-key</filename>; it would be reasonable to + use a 45-character random password for this purpose. To create the + master key, run <command>kstash</command> and enter a password:</para> <screen>&prompt.root; <userinput>kstash</userinput> -Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput> -Verifying password - Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen> +Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput> +Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen> - <para>Once the master key has been created, initialize the - database using <command>kadmin -l</command>. This option - instructs <command>kadmin</command> to modify the local - database files directly rather than going through the - &man.kadmind.8; network service. This handles the - chicken-and-egg problem of trying to connect to the database + <para>Once the master key has been created, the database should be + initialized. The <application>Kerberos</application> administrative + tool &man.kadmin.8; can be used on the KDC in a mode that + operates directly on the database, without using the &man.kadmind.8; + network service, as <command>kadmin -l</command>. + This resolves the chicken-and-egg problem of trying to connect to + the database before it is created. At the <command>kadmin</command> prompt, use <command>init</command> to create the realm's initial database:</para> @@ -1280,21 +1295,22 @@ Verifying password - Password: <userinpu <command>service kadmind start</command>. While there will not be any kerberized daemons running at this point, it is possible to confirm that the <acronym>KDC</acronym> is - functioning by obtaining and listing a ticket for the - principal that was just created from the command-line of the - <acronym>KDC</acronym>:</para> + functioning by obtaining a ticket for the + principal that was just created:</para> <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput> tillman@EXAMPLE.ORG's Password: - -&prompt.user; <userinput>klist</userinput> -Credentials cache: FILE:/tmp/krb5cc_500 +</screen> + <para>Confirm that a ticket was successfully obtained using + <command>klist</command>:</para> + <screen>&prompt.user; <userinput>klist</userinput> +Credentials cache: FILE:/tmp/krb5cc_1001 Principal: tillman@EXAMPLE.ORG - Issued Expires Principal -Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen> + Issued Expires Principal +Aug 27 15:37:58 2013 Aug 28 01:37:58 2013 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen> - <para>The temporary ticket can be revoked when the test is + <para>The temporary ticket can be destroyed when the test is finished:</para> <screen>&prompt.user; <userinput>kdestroy</userinput></screen> @@ -1309,87 +1325,98 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt <secondary>enabling services</secondary> </indexterm> - <para>To configure a server to use - <application>Kerberos</application> authentication, copy - <filename>/etc/krb5.conf</filename> from the - <acronym>KDC</acronym> to the server in a secure fashion, such - as &man.scp.1;, or physically via removable media.</para> + <para>The first step in configuring a server to use + <application>Kerberos</application> authentication is to + ensure that it has the correct configuration in + <filename>/etc/krb5.conf</filename>. The version from the + <acronym>KDC</acronym> can be used as-is, or it can be + regenerated on the new system.</para> <para>Next, create <filename>/etc/krb5.keytab</filename> on the - server. This is the major difference between a server - providing <application>Kerberos</application> enabled daemons - and a workstation: the server must have a - <filename>keytab</filename>. This file contains the server's - host key, which allows it and the <acronym>KDC</acronym> to - verify each others identity. It must be transmitted to the + server. This is the main part of <quote>Kerberizing</quote> a service + — it corresponds to generating a secret shared between the + service and the <acronym>KDC</acronym>. The secret is a cryptographic + key, stored in a <quote>keytab</quote>. The keytab contains + the server's host key, which allows it and the <acronym>KDC</acronym> + to verify each others' identity. It must be transmitted to the server in a secure fashion, as the security of the server can be broken if the key is made public. Typically, the - <filename>keytab</filename> is transferred to the server using - <command>kadmin</command>. This is handy because the host - principal, the <acronym>KDC</acronym> end of the - <filename>krb5.keytab</filename>, is also created using + <filename>keytab</filename> is generated on an administrator's + trusted machine using <command>kadmin</command>, then securely + transferred to the server, e.g., with &man.scp.1;; it can also + be created directly on the server if that is consistent with + the desired security policy. It is very important that the + keytab is transmitted to the server in a secure fashion: if + the key is known by some other party, that party can impersonate + any user to the server! Using <command>kadmin</command> on the + server directly is convenient, because the entry for the host + principal in the <acronym>KDC</acronym> database is also created using <command>kadmin</command>.</para> - <para>A ticket must first be obtained and this ticket must be - allowed to use the <command>kadmin</command> interface in the + <para>Of course, <command>kadmin</command> is a kerberized service; + a <application>Kerberos</application> ticket is needed to authenticate + to the network service, but to ensure that the user running + <command>kadmin</command> is actually present (and their session has + not been hijacked), <command>kadmin</command> will prompt for the + password to get a fresh ticket. The principal authenticating + to the kadmin service must be permitted to use the + <command>kadmin</command> interface, as specified in <filename>kadmind.acl</filename>. See the section titled <quote>Remote administration</quote> in <command>info heimdal</command> for details on designing access control lists. Instead of enabling remote <command>kadmin</command> - access, the administrator can securely connect to the + access, the administrator could securely connect to the <acronym>KDC</acronym> via the local console or &man.ssh.1;, and perform administration locally using <command>kadmin -l</command>.</para> <para>After installing <filename>/etc/krb5.conf</filename>, - use <command>add --random-key</command> from the - <application>Kerberos</application> server. This adds the - server's host principal. Then, use <command>ext</command> to - extract the server's host principal to its own keytab:</para> + use <command>add --random-key</command> in <command>kadmin</command>. + This adds the server's host principal to the database, but does not + extract a copy of the host principal key to a keytab. To generate + the keytab, use <command>ext</command> to extract the server's host + principal key to its own keytab:</para> <screen>&prompt.root; <userinput>kadmin</userinput> kadmin><userinput> add --random-key host/myserver.example.org</userinput> Max ticket life [unlimited]: Max renewable life [unlimited]: +Principal expiration time [never]: +Password expiration time [never]: Attributes []: -kadmin><userinput> ext <replaceable>host/myserver.example.org</replaceable></userinput> +kadmin><userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput> kadmin><userinput> exit</userinput></screen> - <para>Note that <command>ext</command> stores the extracted key - in <filename>/etc/krb5.keytab</filename> by default.</para> - - <para>If &man.kadmind.8; is not running on the - <acronym>KDC</acronym> and there is no access to - &man.kadmin.8; remotely, add the server's host principal - directly on the <acronym>KDC</acronym> and then extract it to - a temporary file to avoid overwriting the - <filename>/etc/krb5.keytab</filename> on the - <acronym>KDC</acronym>:</para> + <para>Note that <command>ext_keytab</command> stores the extracted key + in <filename>/etc/krb5.keytab</filename> by default. This is + good when being run on the server being kerberized, but the + <command>--keytab <replaceable>path/to/file</replaceable></command> + argument should be used when the keytab is being extracted + elsewhere:</para> <screen>&prompt.root; <userinput>kadmin</userinput> -kadmin><userinput> ext --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput> +kadmin><userinput> ext_keytab --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput> kadmin><userinput> exit</userinput></screen> <para>The keytab can then be securely copied to the server using &man.scp.1; or a removable media. Be sure to specify a - non-default keytab name to avoid overwriting the keytab on the - <acronym>KDC</acronym>.</para> + non-default keytab name to avoid inserting unneeded keys into the + system's keytab.</para> - <para>At this point, the server can communicate with the - <acronym>KDC</acronym> using - <filename>krb5.conf</filename> and it can prove its own - identity with <filename>krb5.keytab</filename>. It is now - ready for the <application>Kerberos</application> services to - be enabled. For this example, the &man.telnetd.8; service is - enabled in <filename>/etc/inetd.conf</filename> and - &man.inetd.8; has been restarted with <command>service inetd - restart</command>:</para> - - <programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting> - - <para>The critical change is that the <option>-a</option> - authentication type is set to user. Refer to &man.telnetd.8; - for more details.</para> + <para>At this point, the server can read encrypted messages from the + <acronym>KDC</acronym> using its shared key, stored in + <filename>krb5.keytab</filename>. It is now + ready for the <application>Kerberos</application>-using services to + be enabled. One of the most common such services is &man.sshd.8;, + which supports <application>Kerberos</application> via the + <acronym>GSS-API</acronym>. In + <filename>/etc/ssh/sshd_config</filename>, add the line:</para> + + <programlisting>GSSAPIAuthentication yes</programlisting> + + <para>After making this change, &man.sshd.8; must be restared for + the new configuration to take effect: <command>service sshd + restart</command>.</para> </sect2> <sect2> @@ -1401,36 +1428,34 @@ kadmin><userinput> exit</userinput></ <secondary>configure clients</secondary> </indexterm> - <para>To configure a client to use - <application>Kerberos</application>, securely copy - <filename>/etc/krb5.conf</filename> to the client computer - from the <acronym>KDC</acronym>.</para> + <para>As it was for the server, the client requires configuration in + <filename>/etc/krb5.conf</filename>. Copy the file in place + (securely) or re-enter it as needed.</para> <para>Test the client by using <command>kinit</command>, <command>klist</command>, and <command>kdestroy</command> from - the client to obtain, show, and then delete an existing ticket - for the principal. <application>Kerberos</application> + the client to obtain, show, and then delete a ticket + for an existing principal. <application>Kerberos</application> applications should also be able to connect to <application>Kerberos</application> enabled servers. If that does not work but obtaining a ticket does, the problem is likely with the server and not with the client or the - <acronym>KDC</acronym>.</para> + <acronym>KDC</acronym>. In the case of kerberized &man.ssh.1;, + <acronym>GSS-API</acronym> is disabled by default, so test using + <command>ssh -o GSSAPIAuthentication=yes + <replaceable>hostname</replaceable></command>.</para> <para>When testing a Kerberized application, try using a packet - sniffer such as <command>tcpdump</command> to confirm that the - password is not sent in the clear.</para> + sniffer such as <command>tcpdump</command> to confirm that no + sensitive information is sent in the clear.</para> <para>Various <application>Kerberos</application> client - applications are available. &os; installs - <command>telnetd</command> as the only - <application>Kerberos</application> enabled service. The - Heimdal package or port installs - <application>Kerberos</application> enabled versions of - <command>ftpd</command>, <command>rshd</command>, - <command>rcp</command>, <command>rlogind</command>, and a few - other less common programs. The <acronym>MIT</acronym> port - contains a full suite of <application>Kerberos</application> - client applications.</para> + applications are available. With the advent of a bridge so that + applications using <acronym>SASL</acronym> for authentication can + use <acronym>GSS-API</acronym> mechanisms as well, large classes + of client applications can use <application>Kerberos</application> + for authentication, from Jabber clients to <acronym>IMAP</acronym> + clients.</para> <indexterm> <primary><filename>.k5login</filename></primary> @@ -1489,20 +1514,8 @@ jdoe@example.org</screen> <acronym>MIT</acronym> versions if <envar>PATH</envar> lists the system directories first.</para> - <note> - <para>With the &os; <acronym>MIT</acronym> - <package>security/krb5</package> port, be sure to read - <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename> - installed by the port to understand why logins via - <command>telnetd</command> and <command>klogind</command> - behave somewhat oddly. Correcting the <quote>incorrect - permissions on cache file</quote> behavior requires that - the <command>login.krb5</command> binary be used for - authentication so that it can properly change ownership for - the forwarded credentials.</para> - </note> - - <para>The following edits should also be made to + <para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;, + the following edits should also be made to <filename>rc.conf</filename>:</para> <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc" @@ -1523,9 +1536,8 @@ kadmind5_server_enable="YES"</programlis <itemizedlist> <listitem> <para>When using either Heimdal or <acronym>MIT</acronym> - <application>Kerberos</application>, ensure that the - <envar>PATH</envar> lists the - <application>Kerberos</application> versions of the + <application>Kerberos</application> from ports, ensure that the + <envar>PATH</envar> lists the port's versions of the client applications before the system versions.</para> </listitem> @@ -1541,7 +1553,7 @@ kadmind5_server_enable="YES"</programlis class="username">host/</systemitem> principal must be changed and the keytab updated. This also applies to special keytab entries like the <systemitem - class="username">www/</systemitem> principal used for + class="username">HTTP/</systemitem> principal used for Apache's <package>www/mod_auth_kerb</package>.</para> </listitem> @@ -1570,8 +1582,8 @@ kadmind5_server_enable="YES"</programlis <para>With <acronym>MIT</acronym> <application>Kerberos</application>, to allow a principal to have a ticket life longer than the default - ten hours, use <command>modify_principal</command> at the - &man.kadmin.8; prompt to change the + lifetime of ten hours, use <command>modify_principal</command> + at the &man.kadmin.8; prompt to change the <literal>maxlife</literal> of both the principal in question and the <systemitem class="username">krbtgt</systemitem> principal. The @@ -1607,17 +1619,6 @@ kadmind5_server_enable="YES"</programlis </listitem> <listitem> - <para>To use long ticket lifetimes when using - <application>OpenSSH</application> to connect to the - machine where the ticket is stored, make sure that - <application>Kerberos</application> - <option>TicketCleanup</option> is set to - <literal>no</literal> in - <filename>/etc/ssh/sshd_config</filename>. Otherwise, - tickets will be deleted at log out.</para> - </listitem> - - <listitem> <para>Host principals can have a longer ticket lifetime. If the user principal has a lifetime of a week but the host being connected to has a lifetime of nine hours, the user @@ -1658,20 +1659,6 @@ kadmind5_server_enable="YES"</programlis shells but the non-Kerberized <acronym>POP3</acronym> mail server sends passwords in plain text.</para> - <para><application>Kerberos</application> is intended for - single-user workstations. In a multi-user environment, - <application>Kerberos</application> is less secure as it - stores the tickets in <filename>/tmp</filename>, which is - readable by all users. If a user is sharing a computer, it is - possible that the user's tickets can be stolen or copied by - another user.</para> - - <para>This can be overcome with <command>kinit -c</command> or, - preferably, the <envar>KRB5CCNAME</envar> environment - variable. Storing the ticket in the user's home directory and - using file permissions are commonly used to mitigate this - problem.</para> - <para>The <acronym>KDC</acronym> is a single point of failure. By design, the <acronym>KDC</acronym> must be as secure as its master password database. The <acronym>KDC</acronym> should @@ -1706,45 +1693,6 @@ kadmind5_server_enable="YES"</programlis </sect2> <sect2> - <title>Access Issues with Kerberos and - <command>ssh</command></title> - - <indexterm><primary>&man.ssh.1;</primary></indexterm> - - <para>Kerberos is an excellent authentication protocol, but - there are bugs in the Kerberized versions of - <command>telnet</command> and <command>rlogin</command> that - make them unsuitable for dealing with binary streams. By - default, Kerberos does not encrypt a session unless - <option>-x</option> is used, whereas <command>ssh</command> - encrypts everything.</para> - - <para>While <command>ssh</command> works well, it forwards - encryption keys by default. This introduces a security risk - to a user who uses <command>ssh</command> to access an - insecure machine from a secure workstation. The keys - themselves are not exposed, but <command>ssh</command> - installs a forwarding port for the duration of the login. If - an attacker has broken <systemitem - class="username">root</systemitem> on the insecure machine, - he can utilize that port to gain access to any other machine - that those keys unlock.</para> - - <para>It is recommended that <command>ssh</command> is used in - combination with Kerberos whenever possible for staff logins - as it can be compiled with Kerberos support. This reduces - reliance on potentially exposed <acronym>SSH</acronym> keys - while protecting passwords via Kerberos. Keys should only be - used for automated tasks from secure machines as this is - something that Kerberos is unsuited to. It is recommended to - either turn off key-forwarding in the - <acronym>SSH</acronym> configuration, or to make use of - <literal>from=IP/DOMAIN</literal> in - <filename>authorized_keys</filename> to make the key only - usable to entities logging in from specific machines.</para> - </sect2> - - <sect2> <title>Resources and Further Information</title> <indexterm> @@ -1769,8 +1717,8 @@ kadmind5_server_enable="YES"</programlis <listitem> <para><link - xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC - 1510, The <application>Kerberos</application> Network + xlink:href="http://www.ietf.org/rfc/rfc4120.txt?number=4120">RFC + 4120, The <application>Kerberos</application> Network Authentication Service (V5)</link></para> </listitem>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405150246.s4F2k4vm007732>