Subject: Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 28 May 2009 22:22:04 -0700

Hi Glen,

Thanks for the review.  I've incorporated most of the suggestions into a
new revision.  I have a question for you below.  

<snip>

> Same section, last paragraph, says:
> 
>    Since EAP authentication occurs before network access is 
> granted the
>    tunnel method SHOULD enable an inner exchange to provide 
> support for
>    minimal password management tasks including password 
> change, "new PIN
>    mode", and "next token mode" required by some systems.
> 
> "New token mode" and "new PIN mode" refer to the proprietary 
> SecureID system
> from RSA.  I don't know why we should be giving RSA free 
> advertising ;-),
> nor why their system deserves explicit mention.  Suggestion:
> 
> CHANGE:
> change, "new PIN mode", and "next token mode" required by 
> some systems.
> TO
> change and other "housekeeping" functions required by some systems.
> 
> This might also be a good place to mention that certain data 
> related to
> authorization may need to be communicated to the peer; it is 
> forbidden to do
> this in an EAP Success message, but there is no such 
> constraint (yet) upon
> the TLS tunnel.
> 
[Joe] I think this information would go in section 3.8 Extensibility.
Do you have specific text that you think should go there.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 28 May 2009 22:22:04 -0700

Hi Glen,

<snip>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 28 May 2009 22:28:11 -0700

Below, Glen suggests that it would be better to list specific
requirements from RFC 5247 and RFC 4962 to avoid later confusion.  This
sounds like a good idea, is someone willing to contribute some text on
this?  I think it would be a distilled list of requirements from the two
drafts normalized so they don't conflict. 

Thanks,

Joe

> 
> Section 4.1.1, third paragraph says:
> 
>    The tunnel method MUST meet all the EAP method 
> requirements contained
>    in the EAP Key Management Framework [RFC5247] or its 
> successor.  The
>    tunnel method MUST include MSK and EMSK generation.  This 
> will enable
>    the tunnel method to properly fit into the EAP key management
>    framework, maintaining all of the security properties and 
> guarantees
>    of that framework.
> 
> While it is undoubtedly tempting to simply require compliance 
> with RFC 5247,
> given the rather incredible amount of drivel and nonsense 
> present in that
> RFC, it might be a better idea to be specific about precisely what
> requirements need to be satisfied.
> 
> Same section, last paragraph: same comment as the last, but 
> in spades.  Just
> one example that leaps out: Section 4.1.1, 4th paragraph of 
> the draft in
> question says "The tunnel method MUST NOT be tied to any single
> cryptographic algorithm." and the last paragraph says "The 
> tunnel method
> MUST meet requirements pertinent to EAP method contained in 
> Section 3 of RFC
> 4962 [RFC4962].  This includes: cryptographic algorithm 
> independence..." but
> the subsection on algorithm independence in Section 3 of RFC 4962 says
> "...an EAP method MAY depend on a specific cryptographic 
> algorithm."  While
> this specific contradiction might be addressed by adding a 
> sentence stating
> that conflicts are resolved in favor of this draft other, more subtle
> problems might not.
> 
> 
> ~gwz
> 
> Play assigns meaning to human activity--work erases it.
>   -- P.L. Wilson
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>