Hi Stephen, thanks for the review comments. -05 has fixed the typoes and it
provides an example using the anonymous well-known names as requested.
Here is the relevant text in -05.
It is possible to have name collision with well-known names because
Kerberos as defined in [RFC4120] does not reserve names that have
special meanings, consequently care MUST be taken to avoid accidental
reuse of names. If a well-known name is not supported,
authentication MUST fail as specified in Section 3. Otherwise,
access can be granted unintentionally, resulting in a security
weakness. Consider for example, a KDC that supports this
specification but not the anonymous authentication described in
[ANON]. Assume further that the KDC allows a principal to be created
named identically to the anonymous principal. If that principal were
created and given access to resources, then anonymous users might
inadvertently gain access to those resources if the KDC supports
anonymous authentication at some future time. Similar issues may
occur with other well-known names. By requiring KDCs reject
authentication with unknown well-known names, we minimize these
concerns.
Let me know if you have further comments.
--larry
________________________________________
From: Stephen Hanna [shanna(_at_)juniper(_dot_)net]
Sent: Thursday, March 06, 2008 11:41 PM
To: Larry Zhu; Jeffrey Hutzelman
Cc: ietf(_at_)ietf(_dot_)org; secdir(_at_)mit(_dot_)edu
Subject: secdir review of draft-ietf-krb-wg-naming-04.txt
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors should treat these comments just like any
other comments.
This document defines conventions for well-known Kerberos principal
names and well-known Kerberos realm names.
While the document seems to be pretty thorough, the Security
Considerations section is too brief. This is especially true
for a document whose main purpose is to modify a criticial
security protocol such as Kerberos. The Security Considerations
section could provide an example of how unintended access
could be granted if an authentication with an unsupported
well-known name is allowed to succeed. More important, it
should explain why it is permissible for the TGS to allow
an authentication to succeed even if the client and/or
server principal name is an unsupported well-known name.
The reasoning for allowing this is not clear to me but
perhaps it is that the TGS can assume that the AS must
have supported the client name or it would have failed the
authentication. I'm not sure how this helps to address the
case where the server name is an unsupported well-known
name. I would like to see that explained, preferably
in the document.
I also noticed a few typos:
At the end of section 1, "remedy these" should be "remedy these
issues" or something similar. Otherwise, it's not clear what is
to be remedied.
In the last paragraph of section 3.1, the first word "is" in the
phrase "is a well-known principal name is used" should be "if".
Similarly, in the second paragraph of section 3.2, the first word
"is" should be "if" in the phrase "is a well-known realm name is used".
Other than these issues, the document seems to be OK.
Thanks,
Steve
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg(_at_)lists(_dot_)anl(_dot_)gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf