My general feeling is that the document is close to being done, modulo
some XXX-style comments in several places.
Some specific comments (mostly nits) below.
General comment: the document is using terminology for multiple technologies
(EAP, GSS-API and even SASL). While I think the document is correct and
it explains most of the terms used, some additional references on first
use would be very helpful in order to improve readability.
In particular I am thinking about Section 1 and its subsections, e.g.
Section 1.2.
In Section 1, 5th paragraph:
The goal of this specification is to combine GSS-API's support for
application protocols with EAP/AAA's support for common credential
types and for authenticating to a server without requiring that
server to specifically support the authentication method in use. In
addition, this specification supports thearchitecture goal of
Missing space, should be "the architecture".
transporting attributes about subjects to relying parties. Together
this combination will provide federated authentication and
authorisation for GSS-API applications.
3. EAP Channel Binding and Naming
EAP authenticates a realm.
The whole realm? I thought a realm is a collection of user and service
accounts.
The peer knows that it has exchanged
authentication with an EAP server in a given realm.
3.1. Mechanism Name Format
The string representation of the GSS-EAP mechanism name has the
following ABNF [RFC5234] representation:
; Define name-string to handle escaping and prevent / and @
I was about to ask where is it defined.
empty =
This is going to fail ABNF validation. Use something like 0"blah".
user-or-service = name-string
host = empty/name-string
Can host really be empty? If yes, this can result in the following name:
user-or-service "/" "@" realm
Is it going to be valid?
If not, you might be missing an extra pair of [] in the definition
of <name> below:
realm = name-string
service-specific = name-string
service-specifics = service-specific 0*('/' service-specifics)
name = user-or-service '/' host [ '/' service-specifics] [ '@'
realm ]
Also change a single quote to double quote, otherwise this is not a
correct ABNF.
The user-or-service component is the portion of a network access
identifier (NAI) before the '@' symbol for initiator names
NAI syntax needs a reference.
and the
service name from the registry of GSS-API host-based services in the
case of acceptor names [GSS-IANA].
If the null name type or the GSS_EAP_NT_EAP_NAME (oid XXX) is
Yes, this needs to be defined :-).
imported, then the string representation above should be directly
imported. Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME
name form with the OID {iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}.
3.4. Proxy Verification of Acceptor Name
This section is empty.
5.1. Mechanisms and Encryption Types
This mechanism family uses the security services of the Kerberos
cryptographic framework [RFC3961]. As such, a particular encryption
type needs to be chosen. By convention, there is a single object
identifier arc for the EAP family of GSS-API mechanisms. A specific
mechanism is chosen by adding the numeric Kerberos encryption type
number to the root of this arc. However, in order to register the
SASL name, the specific usage with a given encryption type needs to
be registered. This document defines the eap-aes128-cts-hmac-sha1-96
GSS-API mechanism. XXX define an OID for that and use the right
language to get that into the appropriate SASL registry.
Yes :-).
5.2. Processing received tokens
Implementations of this mechanism maintain a state machine for the
context establishment process. Both the initiator and acceptor start
out in the initial state; see Section 5.4 for a description of this
state. Associated with each state are a set of subtoken types that
are processed in that state and rules for processing these subtoken
types. The reciever examines the subtokens in order, processing any
that are appropriate for the current state.
What happens to the subtokens which are not appropriate for the current
state?
5.4.2. Acceptor Name Request
The acceptor name request token is sent from the initiator to the
acceptor indicating that the initiator wishes a particular acceptor
name. This is similar to TLS Server Name Indication.
This needs an Informative Reference.
In Section 5.5:
o If the acceptor receives an EAP failure, then the acceptor sends
this in the Eap Request subtoken type. If the initiator receives
an EAP Failure, it returns GSS failure.
Can you expand on what you mean here. "receive" doesn't mean receive
over the wire here, right?
Also, what does it mean to return a "GSS failure"?
5.6.2. Channel Bindings Subtoken
Again, only the application data is sent in the channel binding. The
initiator and acceptor addresses are ignored.
I am not entirely clear on what you mean here by "addresses are ignored".
In 5.6.3:
The input to GSS_GetMIC is as follows:
1. The DER-encoded object identifier of the mechanism in use; this
value starts with 0x06 (the tag for object identifier). When
encoded in an RFC 2743 context token, the object identifier is
preceeded by the tag and length for [Application 0] SEQUENCE.
This tag and the length of the overall token is not inclded; only
the tag, length and value of the object identifier itself.
2. A 16-bit token type in network byte order of the RFC 4121 token
identifier (0x0601 for initiator, 0x0602 for acceptor).
3. For each subtoken other than the MIC subtoken itself:
What is the order of subtokens?
Does this cover all subtokens sent during the extension phase?
Does this cover only subtokens sent by the initiator/acceptor respectively?
1. A four octet subtoken type in network byte order
2. A four byte length in network byte order
3. Length octets of value from that subtoken
6. Acceptor Services
The CRK is derived from the GMSK using the following procedur
Typo: procedure
Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap")
How is "n" respresented, in particular how many bytes are used to
represent it?
CRK = truncate(L, T1 || T2 || .. || Tn)
L = output RFC 3961 key size
In Section 6.1:
In this mechanism an extension option of type 0 with the critical bit
I am a bit confused here: what is "an extension option".
set is sent from the initiator to the acceptor. This option contains
a GSS_Wrap token of the channel binding data passed into
GSS_Init_sec_context.
8.1. RFC 4121 Token Identifiers
A new top level registry titled "Kerberos GSS-API Mechanism
Parameters," should be created. This registry should be separate
from the existing "Kerberos Parameters" registry.
In this registry is a subregistry called "Kerberos GSS-API Token
Identifiers"; the overall reference for this subregistry is section
4.1 of RFC 4121.
What is the IANA registration procedure here?
8.4. GSS EAP Errors
A new subregistry is created in the GSS EAP parameters registry
titled "Error Codes". XXX fill in minor statuses.
What is the IANA registration procedure here?
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
