Liqiang(Larry) Zhu | 2 Mar 2007 13:39
Picon
Favicon

RE: Comments on draft-ietf-krb-wg-naming-01.txt

Jeffrey Hutzelman wrote:

> + Make it clear that all principal names involving a reserved realm
name
>  are reserved.

Done.

   Unless otherwise specified, all principal names involving a well-
   known realm name are reserved, and if a reserved principal name is
   used but not supported, authentication MUST fail with the code
   KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN.

            KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN          TBA
                 -- A reserved Kerberos principal name is used but not
                 -- supported.

   There is no accompanying error data defined in this document for this
   error.

>+ Clarify what it means for reserved names to be critical...
>  - Must the TGS reject requests where the client principal is
reserved?
>  - Must application servers reject AP-REQ's where the client principal
>    is reserved?
>  - What is the handling of reserved service principal names?

   The AS and the application server MUST reject the authentication
   attempt if a well-known realm name is used as the client realm or the
   server realm but not supported.  The TGS [RFC4120] MAY reject the
   authentication attempt if a well-known realm name is used as the
   client realm but not supported, and SHOULD reject the authentication
   attempt is a well-known realm name is used as the server realm but
   not supported.  Unless otherwise specified, if a well-known realm
   name is used but not supported in any other places of Kerberos
   messages, authentication MUST fail.  The error code is
   KRB_AP_ERR_WELLKNOWN_REALM_NAME_NOT_SUPPORTED, and there is no
   accompanying error data for this error.

            KRB_AP_ERR_WELLKNOWN_REALM_NAME_NOT_SUPPORTED       TBA
                 -- A well-known Kerberos realm name is used but not
                 -- supported.

> + The sentents "All reserved names... are critical..." does not belong
in
>  the abstract - it is not part of a condensed description of what the
>  document is about.

Removed

> [RFC2246] is not referenced at all

Removed

> + [ANON] is not used normatively.

Changed to be informative

>+ Name types and error codes to be assigned by Tom Yu

Just sent Tom a request for allocations.

>+ Spell checking!

Done

>+ The IANA considerations requires the creation of a new registry, but
>  does not fully describe what information the registry contains and
does
>  not set an assignment policy.  See RFC2434.

I added the following: the evaluation policy is "Specification
Required". Is this sufficient, do you have a good example? Thanks,

-----Original Message-----
From: owner-ietf-krb-wg <at> mailhost.anl.gov
[mailto:owner-ietf-krb-wg <at> mailhost.anl.gov] On Behalf Of Jeffrey
Hutzelman
Sent: Wednesday, February 28, 2007 9:30 AM
To: ietf-krb-wg <at> anl.gov
Cc: Jeffrey Hutzelman
Subject: Comments on draft-ietf-krb-wg-naming-01.txt

+ Make it clear that all principal names involving a reserved realm name
  are reserved.

+ Clarify what it means for reserved names to be critical...
  - Must the TGS reject requests where the client principal is reserved?
  - Must application servers reject AP-REQ's where the client principal
    is reserved?
  - What is the handling of reserved service principal names?

+ The sentents "All reserved names... are critical..." does not belong
in
  the abstract - it is not part of a condensed description of what the
  document is about.

+ The IANA considerations requires the creation of a new registry, but
  does not fully describe what information the registry contains and
does
  not set an assignment policy.  See RFC2434.

+ [ANON] is not used normatively.

+ [RFC2246] is not referenced at all

+ Name types and error codes to be assigned by Tom Yu

+ Spell checking!


Gmane