Pasi,
See comments inline. An updated draft will be released shortly. Also
note that the new draft addresses Dan's comments about resistance to
dictionary attack.
Cover page: suggest adding word "method" to end of document title
Done.
S4, "EAP_Method_Type refers to the integer value of the IANA allocated
EAP Type code", "...to the EAP type code (1 byte), specified in
Section XX"?
I don't think it's ever been clear how to reference the IANA allocated
EAP type code in an I-D before it's been allocated. These are things
that would be fixed by the RFC Editor or in AUTH48, once IANA has
allocated the type code.
S5/S8.2: reference RFC3232 doesn't seem right here. RFC 3748 didn't
have any reference, but if you want one, perhaps the registry
itself (name+URL) would be better.
Replaced references with references to IANA's enterprise number registry.
S5: does not say that enterprise code 0 means IETF/IANA managed registry
Fixed.
S5, "is mandatory to implement" and "its support is optional",
should use RFC2119 keywords?
Fixed.
S6 and elsewhere: Several places in the document assume that KS (key
size of the ciphersuite) is always the same as the MAC output length.
This would make it difficult to define ciphersuites based on
e.g. AES-CMAC-256. If this restriction is intentional (and WG is happy
with it), at the very least it needs to be emphasized much more.
I'm not sure what AES-CMAC-256 means. RFC 4493 defines CMAC
specifically for 128 length AES, so if you wanted to something involving
256, you'd need to define exactly what AES-CMAC-256 was, and I imagine
it would have a 256-bit input and a 256-bit output. Regardless, I added
a statement in the key derivation section saying the input and output
lengths of your ciphersuite must be equal.
S7.1.2, "where Input refers to [..] Value of SEC_SK(Value)" this
can be interpreted in two ways
Fixed.
S7.1.3 and S7.2.3, these sections seem to be redundant (don't contain
anything that isn't already said in S4?)
Removed sections.
S5 and S8.2 are not consistent about ciphersuite formatting (is
enterprise number 3 or 4 octets; if you're not sure, suggest
doing what RFC3748 did)
Fixed (should be 4).
S5/S8.2/S8.4, terminology: in this context, OID would usually mean the
whole OID (e.g., "1.3.6.1.4.1.1080"); here we want just the enterprise
code (e.g., 1080)
Replaced references to "OID" with "enterprise number".
S8.3, should specify exactly which octets are used when
calculating MACs.
Fixed.
S8.4, text and bit diagram are not consistent about whether
enterprise code is 3 or 4 bytes
Text consistent with length 4 enterprise code.
S8.4, it seems that here you borrowed text from IKEv2. That's good...
except that IKEv2 didn't get this quite right (it assumed CBC mode
without saying so). In draft-hoffman-ikev2bis-03 say so explicitly
(and add that other modes can be specified in the future).
>
S8.4, the part IKEv2 got really wrong was the text about IVs (the
text suggests violating important security requirements from the
actual CBC mode spec, NIST 800-38A). See draft-hoffman-ikev2bis-03
for an attempt to fix it.
Added a bit more flexibility -- optional/arbitrary-length IV, and
optional/arbitrary-length padding. This would make the formatting
compatible with stream-based modes like CCM, or self-contained modes
like AEAD.
S8.4, adding zero padding length byte when not doing encryption is
confusing -- consider removing (or at least explaining much more
clearly).
Allows for more modular implementations -- separate protocol processing
from crypto processing. Added text.
S8.4.1, it seems that we have two different ways to send protected
failure indication (GPSK-Protected-Fail opcode and protected result
indication)? some change or explanation is needed.
Removed 8.4.1.
S9, text seems to confuse mandatory-to-implement and mandatory-to-use.
Making some crypto algorithm mandatory-to-use is extremely rare in
IETF specs, and I can't recall any instance where this was done if
the protocol had a working negotiation mechanism.
Removed the mandatory to use language.
S9, "EAP peer should respond with an EAP-NAK". Is this a SHOULD?
(and if it is, the reasons for not making it MUST should be explained)
Fixed.
S9, "If the MAC validation fails, the server MUST transmit a GPSK-Fail
message specifying "Authentication Failure" and discard the received
packet." Not quite sure what "discard the received packet" here
exactly means in the context of EAP state machine (If the server
sends a reply, it's not discarding the packet as such).
Fixed.
S11.6, "(PSK) that MUST be based on at least 16 octets of entropy" An
implementor of EAP-GPSK cannot implement this MUST. If it's intended
for administrator/user deploying this, it needs significantly more
detailed instructions.
Changed to SHOULD.
S11.8, 1st para: third form of DoS that should be relevant is
preventing valid peer and authenticator from communicating (and
there's plenty of text about silently discarding things etc. that
attempts to address this)
Added.
S11.8, the description about client not having to keep state seems
wrong -- client needs to keep state to verify that RAND_Peer is
fresh (i.e. RAND_Peer in GPSK-1 and GPSK-3 are the same), right?
This analysis was added after some reviews from Mitchell's group at
Stanford. This text actually could introduce vulnerability to a replay
attack.
S11.10, perhaps some other word than "Exposition" would be
better here?
Replaced with "Compromise".
S11.10, "In particular, this PSK must not be shared by a group of
peers communicating with the same server." One literal interpretation
of this sentence would be that ID_Peer can't identify a user account
if the user can have multiple devices (EAP Peers). That's probably
not exactly what was intended.
Addressed.
S11.11, should explain what limitations this brings (since in theory
EAP-GPSK packets can be longer than minimum EAP MTU)
Fixed.
S11.16, "Although EAP-GPSK provides confidentiality in its protected
data
payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]".
Better explanation needed.
Fixed.
S11 should include a "security claims" summary (see other EAP method
RFCs for examples)
Added.
S11 does not discuss key strenth (required by RFC 3748)
Added.
S12 needs to give names for the new registries to be created
(e.g. "EAP-GPSK Ciphersuite Registry" , etc.)
Added.
S12, "IANA is furthermore instructed to add the specified
ciphersuites, protected data types, failure codes and op-codes to
these registries as defined in this document." -> "The initial contents
of these registries are specified below" ?
Fixed.
S12, "Values can be added or modified with informational RFCs..."
Strongly suggest using one of the policies defined in RFC2434.
(For example, current text prevents Standards Track RFCs from
defining new values!)
Swithced to "IETF CONSENSUS".
S12, needs some paragraph breaks (e.g. "The Failure-Code field is 32
bits long and all other values are available via IANA registration.
The following layout represents the initial OP-Code registry setup:"
is very confusing).
Fixed.
S15, there are several references that should be normative. At the
very least: RFC4634, AES, CMAC, CBC. Possibly also eap-keying (as the
concepts of EAP "Method-ID", "Session-ID", etc. are not defined
anywhere else).
Done.
Interoperability requires the ability to enter same PSK in both client
and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4 for examples of
management interface requirements.
Added.
The OP-Code field is not included in the MAC; if you're sure this
is OK, perhaps slightly better explanation in e.g. S11.5. would
be good to convince others about this.
Added.
Defining ID_Server just as an "opaque blob" does not really allow
interoperability -- and the spec doesn't really forbit using it in
non-opaque ways. Even if we specified that ID_Server MUST NOT be
processed in any other way than bytewise comparison, interoperability
still requires entering the same ID_Server in both ends (and thus
similar management interface requirements as PSK). And e.g. picking
client identity "[EMAIL PROTECTED]" when seeing ID_Server
"aaa.example.com" wouldn't mean opaque any more. I'm open to
suggestions how to handle this, and there probably isn't just one
right alternative. Specifying that ID_Server is a domain name, and
some kind of simple rules how it could be processed, is one
option. Explicitly forbidding any kind of non-opaque processing
(i.e. requiring that the client MUST know ID_Server beforehand, and
MUST reject GPSK-1 if it does not contain identical ID_Server) would
be another.
ID_Server and ID_Peer must all be provisioned simultaneous to the PSK.
The formatting doesn't matter too much other than to perhaps help the
parties efficiently search a list of PSKs. I've added text in the
management interface section (see "Key Management") to discuss this.
Document needs more text about leaking information via different
failures codes (this is sort of implied in S9 when talking about
"depending on its policy", but what exactly the policy and its
implications are is not described).
Added text to section 11.2.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
