Re: [Ietf-krb-wg] Last call issues on naming

[Larry Zhu <[e-mail]>]

* N002 Mar 06 Stephen Hanna <[e-mail]> (for secdir)
  > 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 propose replacing OLD:

   Similarly, the Ticket Granting Service (TGS)
   [RFC4120] MAY reject the authentication attempt if a well-known
   principal name is used as the client principal name but not
   supported, and SHOULD reject the authentication attempt if a well-
   known principal name is used as the server principal name but not
   supported.

With NEW:
   Similarly, the Ticket Granting Service (TGS)
   [RFC4120] MAY reject the authentication attempt if a well-known
   principal name is used as the client principal name but not
   supported, and SHOULD reject the authentication attempt if a well-
   known principal name is used as the server principal name but not
   supported.  These rules were designed to allow incremental updates and
ease migration.
   More specifically, if a well-known principal is accepted in one realm,
   it is desirable to allow the cross-realm TGT to work when not all of the realms
   in the cross-realm authentication path are updated; if the server principal
   with an identically-named well-known name was created before the KDC is updated, it might be acceptable to allow authentication
   to work but with a limited lifetime.

--larry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeffrey Hutzelman
Sent: Tuesday, July 29, 2008 2:39 AM
To: [e-mail]
Cc: [e-mail]
Subject: [Ietf-krb-wg] Last call issues on naming

The following is a summary of issues that have been raised on the naming
document since draft-ietf-krb-wg-naming-04.txt entered IETF Last Call on
Feb 22, 2008.  There are a total of 5 issues, all but one of which I
believe has been resolved as of draft-ietf-krb-wg-naming-06.txt.

The remaining issue, N002, still needs a reply.  However, I suspect that
Larry can compose a reply without additional discussion from the working
group, so unless someone has a comment, I am not planning on discussing
this item at today's meeting.

Participants should feel free to comment during today's meeting on any
of these items or on any issue not previously noticed.  However, please
bear in mind that this document is at a fairly late stage and so we
should not be making significant changes without a strong need.

In the text below, '>' indicates comments from the listed commenter,
'@' indicates comments from the document author(s), and '[[' and ']]'
surround comments from the shepherd.

**********************************************************************
*** OUTSTANDING
**********************************************************************

* N002 Mar 06 Stephen Hanna <[e-mail]> (for secdir)
  > 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.


**********************************************************************
*** RESOLVED
**********************************************************************

* N001 Mar 06 Stephen Hanna <[e-mail]> (for secdir)
  > 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.

  @ Example added in -05
  [[ Example present in -06 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* N003 Mar 06 Stephen Hanna <[e-mail]> (for secdir)
  > 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.
  [[ Corrected in -06 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* N004 Mar 06 Stephen Hanna <[e-mail]> (for secdir)
  > 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".
  [[ Corrected in -06 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* N005 Mar 20 Sam Hartman <[e-mail]>
  > I think there is a minor ambiguity in  the naming draft:
  > >   Consequently, unless otherwise
  > >   specified, a well-known Kerberos realm name MUST NOT be present
  > >   in transited encoding
  >
  > Who enforces this requirement?  That's an important question because
  > it controls who needs to support the specific well known realm in
  > order for it to be used.
  >
  > I'd recommend something like: Unless otherwise specified, parties
checking
  > the transited realm path MUST reject a transited realm path that
includes a
  > well known realm.  In the case of KDCs checking the transited realm
path,
  > this means that the transited policy checked flag MUST NOT be set in the
  > resulting ticket.
  >
  > In particular, that means that a KDC that is not checking transited
  > realm paths is not encouraged to reject a request simply because the
  > realm in an unknown well known realm.

  @ Proposed text looks good
  [[ Included in -06 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

_______________________________________________
ietf-krb-wg mailing list
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

_______________________________________________
ietf-krb-wg mailing list
[e-mail]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg