Subject: [Emu] AD review of draft-ietf-emu-crypto-bind-03.txt

From: Sean Turner <[email-masked]>
Date: Tue, 04 Jun 2013 06:51:45 -0400

I've got no problem initiating an IETF LC on this document, but I do 
have some nits that need to be fixed before I'll add it to the IESG 
telechat.  Authors please let me know whether you'd like me to initiate 
the IETF LC now or whether you'd like to submit a revised ID.  I only do 
this because these are minor but will no doubt be called out by somebody 
on the IESG as a comment and I rather avoid that.

0) abstract: r/[RFC 3748]/RFC 3748

RFC editor would remove the references from the abstract so it's better 
to do it now or have it pointed out by the gen-art reviewer.

1) move keys words to section 1.1 or make a new section 2.

RFC editor will move it so it's better to do it now or else have it 
pointed out by the gen-art reviewer.

2) s1: r/The Extensible Authentication Protocol [RFC3748]
         /The Extensible Authentication Protocol (EAP) [RFC3748]

Need to re-expand EAP in s1.

3) s3.2.2: delete:Please view in a fixed-width font such as Courier.

4) s3.2.2: The formatting here seems a little off:

  An attacker can convert an inner authentication using an EAP method
  to a inner authentication that does not use EAP in some cases.  This
  may avoid cryptographic binding.

               Converting EAP Inner Authentication

  An attacker may contact another authentication resource to gain a
  challenge useful for an inner authentication.

               Non-EAP Sources of Inner Authentication

5) s3.2.2: r/. a tunnel t2/. A tunnel t2

6) s3.2.4: r/IntroducingEMSK-based Cryptographic Binding
             /Introducing EMSK-based Cryptographic Binding

7) s7: r/margaret/Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jun 2013 16:04:42 -0400

I'll send in a new draft.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 23 Jun 2013 14:50:36 -0400

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    Sean> 1) move keys words to section 1.1 or make a new section 2.

    Sean> RFC editor will move it so it's better to do it now or else
    Sean> have it pointed out by the gen-art reviewer.

I thought this was why the note element was introduced into the xml2rfc
DTD.  I'm kind of tempted to let the RFC editor and xml2rfc authors
fight about style and leave as-is.
I'm fairly sure I've seen note elements make their way into RFCs.
    Sean> 4) s3.2.2: The formatting here seems a little off:

    Sean>  An attacker can convert an inner authentication using an EAP
    Sean> method to a inner authentication that does not use EAP in some
    Sean> cases.  This may avoid cryptographic binding.

    Sean>               Converting EAP Inner Authentication

    Sean>  An attacker may contact another authentication resource to
    Sean> gain a challenge useful for an inner authentication.

    Sean>               Non-EAP Sources of Inner Authentication

This is kind of amusing.  Apparently, there are two figures that we
never produced artwork for, and you're seeing formatting lossage from
that.

So, does someone want to volunteer to produce artwork for these figures
or shall I remove them and let the text stand on its own?

I propose giving the WG a week for someone to step forward.

---

From: Sean Turner <[email-masked]>
Date: Mon, 24 Jun 2013 08:42:20 -0400

> I'm fairly sure I've seen note elements make their way into RFCs.

Ah so this is an xml2rfc thing.  Then I'd leave it alone.

> I propose giving the WG a week for someone to step forward.

ack