Talk:Kerberos (protocol)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Release date and version?[edit]

I think the relase date and version should be removed, because it's not the version and release of the protocol, but one (and only one) of the implementations. — Preceding unsigned comment added by Qji (talkcontribs) 09:41, 27 January 2016 (UTC)[reply]

Kerberos 4 vs. Kerberos 5[edit]

According to The Moron's Guide to Kerberos, in Kerberos 5 the final step of authenticating the service to the client does not increment the timestamp. It says:

It used to be the case (in version 4 of Kerberos) that the service would instead add 1 to the timestamp value, and return it, encrypted in the session key. That has been changed in version 5 of Kerberos.

I do not know Kerberos well enough to know whether Wikipedia is right or the Guide (I presume this page wants to be right for Kerberos 5, but I do not think that is stated anywhere).

The guide is right. Kerberos 5 simply sends back a message copying the time from the client to the server. The message is of a different form and an attacker cannot break transform one message into another. See RFC 4120 section 5.5.2.
--SamHartman 16:56, 16 September 2007 (UTC)[reply]

Seeing no disagreement so far, I plan to try and refocus the article on Kerberos 5. I'll try and add a differences from Kerberos 4 section. --SamHartman 14:16, 23 September 2007 (UTC)[reply]

Kerberized NFS[edit]

The article claims that NFSv4 supports kerberos (true), but Solaris has supported kerberized NFS even with the earlier versions of the protocol.


Frodo Looijaard (20051103)


Note too that as of Mac OS X 10.5, Apple are providing Kerberized NFSv3 support, both in OS X Server as a server, and in OS X client as a client.


Anonymous Coward. —Preceding unsigned comment added by 24.6.229.110 (talk) 02:27, 9 December 2007 (UTC)[reply]

"US DoJ finding" on Microsoft breaking Kerberos[edit]

The external link in the article to US DOJ finding that Microsoft purposefully breaks Kerberos interoperability seems to be a submission to the court by Novell, not a finding by the US DoJ. If the DoJ did conclude the same thing as Novell's submission, the external link should point to an article that directly says so, otherwise the link should probably be removed (or at least more appropriately titled). OTOH I might have misinterpreted the contents of the document. I didn't read all of it. —midg3t 04:51, 16 June 2006 (UTC)[reply]

Current versions of Microsoft Kerberos including those in the latest service packs for Windows 2000, 2003, XP and Vista pass interoperability tests against MIT Kerberos and Heimdal. I'd really like to remove the word variant from the article when describing Microsoft Kerberos but I may have a bit of a COI here so I'd like to ask before doing so.
--SamHartman 16:56, 16 September 2007 (UTC)[reply]
I'll go ahead with removing the word variant and will also try and clean up the discussion of the DOJ situation. Review appreciated.
--SamHartman 14:16, 23 September 2007 (UTC)[reply]
Hmm. I see nothing now in the article referring to the long frustrating period of time in which there was not interoperability between Microsoft and open implementations. That seems important to the history and current state of Kerberos and various implementations. --NealMcB (talk) 17:05, 12 May 2009 (UTC)[reply]

"Protocol" and "operation" mismatch[edit]

Currently, the article looks inconsistent because the protocol messages (in "The protocol") don't match up with the operation (given in "Kerberos operation"). Things diverge in step 4 of the operation, where two messages are sent back. Only one message is sent in the protocol. Perhaps someone could fix this? 82.36.100.133 12 Aug 2006

The BAN Logic seems quite broken. As best I can tell it is close to Kerberos 4 but it is even wrong for that. I recommend we remove the protocol section's BAN Logic and then update the remaining text to be consistent with Kerberos 5. I recommend we explicitly mention we're describing Kerberos 5.
--SamHartman 16:56, 16 September 2007 (UTC)[reply]

I'm going to implement removing the BAN logic. The more I think about it the more I'm unhappy with it. Getting something like a formal description of a protocol right is very tricky and is something that should be peer reviewed by professionals in the field. So, it should not be original wikipedia work. It also happens to be clearly wrong for both versions of Kerberos. SamHartman 14:16, 23 September 2007 (UTC)[reply]

Move to Kerberos (protocol)?[edit]

I think that the article should be moved to Kerberos (protocol) because it would be more consistent with Wikipedia naming conventions. Note that the topic is identified as only "Kerberos" both generally and in the title restatement. Thoughts? ENeville 17:02, 20 October 2006 (UTC)[reply]

Agreed. -- intgr 22:55, 17 January 2007 (UTC)[reply]

Missing info.[edit]

I recommend that in the article there should be a paragraph on comparison of Kerberos and RADIUS protocols. —The preceding unsigned comment was added by 195.70.32.136 (talk) 13:07, 2 January 2007 (UTC).[reply]

Why?
--SamHartman 16:56, 16 September 2007 (UTC)[reply]

Found this paragraphs really funny[edit]

There is a version of Kerberos called Bones, which is exactly like Kerberos, except that Bones doesn't encrypt any of the messages. So what is it good for? The U.S. restricts export of cryptography; if it's sufficiently advanced, it qualifies as munitions, in fact. At one time, it was extraordinarily difficult to get crypto software out of the U.S. On the other hand, there is a wide variety of legitimate software that is exported (or created outside the U.S. altogether), and expects Kerberos to be there. Such software can be shipped with Bones instead of Kerberos, tricking them into thinking that Kerberos is there.

Doug Rickard wrote to explain how Bones got its name. In 1988, he was working at MIT, with the Project Athena group. He was trying to get permission from the State Department to export Kerberos to Bond University in Australia. The State Department wouldn't allow it--not with DES included. To get it out of the country, they had to not only remove all calls to DES routines, but all comments and textual references to them as well, so that (superficially, at least) it was non-trivial to determine where the calls were originally placed.

To strip out all the DES calls and garbage, John Kohl wrote a program called piranha. At one of their progress meetings, Doug jokingly said, "And we are left with nothing but the Bones." For lack of a better term, he then used the word "Bones" and "boned" in the meeting minutes to distinguish between the DES and non-DES versions of Kerberos. "It somehow stuck," he says, "and I have been ashamed of it ever since."

Back at Bond University, Errol Young then put encryption back into Bones, thus creating Encrypted Bones, or E-Bones.

Its from Moron's guide to Kerberos —The preceding unsigned comment was added by Wk muriithi (talkcontribs) 06:45, 13 January 2007 (UTC).[reply]

Reply attack to described protocol?[edit]

I'm new to Kerberos, but the described protocol seems vulnerable to a reply-attack: if an intruder records message 3 and resend it soon, detects it as host . The problem is that don't authenticates to . This should be done with something as:

4:

5: —The preceding unsigned comment was added by 213.140.6.116 (talk) 00:28, 8 April 2007 (UTC).[reply]

Missing Software?[edit]

Should not Microsoft Office SharePoint Server 2007 be added to the list of software that supports Kerberos authentication? —Preceding unsigned comment added by 81.144.188.98 (talk) 15:21, 15 November 2007 (UTC)[reply]

Kerberos Pronunciation[edit]

I don't know the IPA but could someone add something about how to pronounce this? It's something like Kerb-er-ross 202.160.118.227 05:02, 2 December 2007 (UTC)[reply]

Drawbacks[edit]

This phrase: A compromised client will compromise the user's password - seems absurd, since the compromised client of any system can compromise a user's password. This is not a drawback of Kerberos. Brutforzz (talk) —Preceding undated comment was added on 09:23, 24 February 2009 (UTC).[reply]

Notation[edit]

I think it's a good idea to have this article written using the Security protocol notation like other protocols have. For example Wide Mouth Frog protocol. I'll do it when I finish my exams and I get some free time but feel free to do it before if you want. --PabloCastellano (talk) 20:05, 27 June 2009 (UTC)[reply]

Client Service Authorization section[edit]

comment added by 118.100.85.128 (talk) 11:34, 29 December 2010 (UTC)[reply]

In the Client Service Authorization section:

When requesting services, the client sends the following two messages to the TGS:

Message C: Composed of the TGT from message B and the ID of the requested service.
Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.

I believe message C also includes the Client/TGS session key encrypted using TGS private key. — Preceding unsigned comment added by Jarv (talkcontribs) 16:49, 23 July 2011 (UTC)[reply]

Russian Image Not Helpful[edit]

There is a image with all Russian (or some other Cryillic language) captions on it. This isn't useful on english language wikipedia. — Preceding unsigned comment added by 207.126.248.6 (talk) 21:42, 16 February 2012 (UTC)[reply]

Agreed, I've removed it. Without knowing the terms the diagram is not helpful.--Flexdream (talk) 16:28, 4 March 2012 (UTC)[reply]


Authentication in Description[edit]

After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a Ticket and session keys, which are returned to the client.

I think, that authorization is not part of the Kerberos Protocol. RFC4120 states: „Possession of a client ticket for a service provides only for authentication of the client to that service, and in the absence of a separate authorization procedure, an application should not consider it to authorize the use of that service.“
There are more details about Authorization in the RFC (chap 1.4) which might be added here. — Preceding unsigned comment added by 195.13.41.220 (talk) 13:30, 18 December 2012 (UTC)[reply]

Single point of failure?[edit]

One of the drawbacks listed in the article says:

Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms.

This point makes no sense as written. Surely having multiple servers would eliminate any single point of failure (and thus this isn't a drawback of Kerberos at all). This point could use some expansion. Draconx (talk) 21:01, 10 January 2013 (UTC)[reply]

I agree with your point. The only way this makes sense is that by making a group of workstations dependent on Kerberos for login, if Kerberos is down, you can't login to any of these workstations. Without network authentication at all, you could still login to a workstation regardless of other systems being down.
So in comparison to no network authentication at all, there's the potential of a single point of failure. The sentence as currently written does not capture the real state of kerberos failures. It says 'mitigated' for exmple, when it means 'eliminated'. Having two servers eliminates a single point of failure. —fudoreaper (talk) 21:19, 13 January 2013 (UTC)[reply]

Drawbacks and Limitations: Trust requirement[edit]

Kerberos cannot be used in scenarios where users want to connect to services from unknown/untrusted clients [..]

As far as I have used Kerberos to access some AFS shares at my university I didn't have to "register" my home machine anywhere. I only had to edit my configuration to point proper servers. —Stlman (talk) 11:09, 26 October 2014 (UTC)[reply]

You are right Stlman, this is just wrong. The client does not have to register if the user authenticates. A machine certificate can be issued if you want machine-to-machine authentication it might be some confusion around that. For a typical "Oauth" workflow Kerberos would work just fine. — Preceding unsigned comment added by 212.107.141.174 (talk) 11:27, 9 November 2019 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on Kerberos (protocol). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 02:10, 9 December 2017 (UTC)[reply]

Graphics: Client Service Authentication and Client Service Request[edit]

Comments on graphics https://en.wikipedia.org/wiki/File:Kerberos_protocol.svg.

Corrections needed:

  • Msg C now contains TGT only, but should contain TGT + service ID. (TGT = KC-TGS + client + address + validity)
  • Msg E occurs twice. The second Msg E (in Client Service Request) should be named Msg F.

Suggested enhancement:

  • Remove label "Requested service" from the two arrows with different msg sets, namely C+D and F+G. I find it confusing that they are labeled the same but have different meaning.
  • If labeling is desired, I propose to change the labels to "Request service ticket" for msg C+D and "Request service" for msg F+G.