2 Mar 2007 13:39
RE: Comments on draft-ietf-krb-wg-naming-01.txt
Liqiang(Larry) Zhu <lzhu <at> windows.microsoft.com>
2007-03-02 12:39:41 GMT
2007-03-02 12:39:41 GMT
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!
RSS Feed