Subject: Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)

From: Charles Clancy <[email-masked]>
Date: Fri, 27 Jun 2008 11:05:29 -0400

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-masked]" 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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Jun 2008 12:45:33 -0700 (PDT)

Hi Charles,

On Fri, June 27, 2008 8:05 am, Charles Clancy wrote:
[snip]
> lengths of your ciphersuite must be equal.

  CMAC is defined in NIST SP 800-38B and section D.3 deals with the
instance of CMAC-AES-256 (with test vectors!). It takes a 256-bit key
and, like all AES-based MACs, produces a 128-bit digest.

  regards,

  Dan.