Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Bernard Aboba]

I think the note in eid6259 is now superfluous.  Can we remove it?

On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot
Lear)  wrote:

> Corrected URLs below:
>
> On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote:
> > Ok.
> >
> > I have edited – but not yet verified – the two errata accordingly.
> > Please see:
> >
> > https://www.rfc-editor.org/errata/eid6154
> > https://www.rfc-editor.org/errata/eid6259
> >
> > Are there any further edits that are required?
> >
> > Eliot (ISE)
> >
> > On 01.04.22 00:52, Alan DeKok wrote:
> >> On Mar 31, 2022, at 4:40 PM, Bernard Aboba 
> >> wrote:
> >>> Alan suggested:
> >>> "   EAP-Start is indicated by sending an EAP-Message attribute with a
> >>> length of 3.  The single byte of data SHOULD be set to zero on
> >>> transmission and MUST be ignored on receipt.  RADIUS clients
> >>> MUST NOT
> >>> send EAP-Message attributes of length 2, as attributes with no
> >>> value
> >>> are not permitted in RADIUS.  However, for historical reasons
> >>> and for
> >>> compatibility with existing practice, RADIUS servers MUST accept
> >>> EAP-Messages
> >>> of length 2, and treat them as EAP-Start.
> >>>
> >>>Just checking the source I have locally, the server accepts
> >>> zero-length EAP-Message (or any other text/string attribute, for
> >>> that matter).  So that's fine."
> >>>
> >>> [BA] This suggested errata text looks good.
> >>Thanks.
> >>
> >>> [BA] This text is better. The implicit assumption here is that the
> >>> NAS is sending an EAP-Request with a locally implemented EAP type,
> >>> without talking to the RADIUS server.  Of course, the same thing
> >>> could happen if the RADIUS server uses an inappropriate default
> >>> type.  So perhaps this might work:
> >>>
> >>> "  Where the initial EAP-Request sent by the NAS is for an
> >>>authentication Type (4 or greater), the peer MAY respond with a Nak
> >>>indicating that it would prefer another authentication method. In
> >>> this
> >>>   case, the NAS should send an Access-Request encapsulating the
> >>>   received EAP-Response/Nak.  This allows a peer to suggest another
> >>>   EAP method where the NAS is configured to send a default EAP
> >>>type (such as MD5-Challenge) which may not be appropriate."
> >>That looks good to me, thanks.
> >>
> >>Alan DeKok.
> >>
> >
> > ___
> > Emu mailing list
> > Emu@ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
> >
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Bernard Aboba]

Alan suggested:
"   EAP-Start is indicated by sending an EAP-Message attribute with a
   length of 3.  The single byte of data SHOULD be set to zero on
   transmission and MUST be ignored on receipt.  RADIUS clients MUST NOT
   send EAP-Message attributes of length 2, as attributes with no value
   are not permitted in RADIUS.  However, for historical reasons and for
   compatibility with existing practice, RADIUS servers MUST accept
EAP-Messages
   of length 2, and treat them as EAP-Start.

  Just checking the source I have locally, the server accepts zero-length
EAP-Message (or any other text/string attribute, for that matter).  So
that's fine."

[BA] This suggested errata text looks good.

Alan said:

"  Then the text needs more work, I think.  A naive reading of the text is
that the peer is NAKing type A, and asking for type B, which it doesn't
implement.  That doesn't make much sense.  And the NAK is also sent by EAP
servers, when the peer requests a type that the server does not respond."

[BA]  "not implemented locally" means "not implemented locally on the NAS".

The use case is: "a NAS suggests EAP-MD5 by default and the peer wants to
use a key-generating EAP method instead (like EAP-TLS or TTLS), so it sends
a Nak."

Suggestion:

"  Where the initial EAP-Request sent by the NAS is for an
  authentication Type (4 or greater), the peer MAY respond with a Nak
  indicating that it would prefer another authentication method that is
  implemented by the RADIUS server, and not by the NAS. In this case,
  the NAS SHOULD send an Access-Request encapsulating the received
  EAP-Response/Nak."

[BA] This text is better. The implicit assumption here is that the NAS is
sending an EAP-Request with a locally implemented EAP type, without talking
to the RADIUS server.  Of course, the same thing could happen if the RADIUS
server uses an inappropriate default type.  So perhaps this might work:

"  Where the initial EAP-Request sent by the NAS is for an
  authentication Type (4 or greater), the peer MAY respond with a Nak
  indicating that it would prefer another authentication method. In this
 case, the NAS should send an Access-Request encapsulating the
 received EAP-Response/Nak.  This allows a peer to suggest another
 EAP method where the NAS is configured to send a default EAP
  type (such as MD5-Challenge) which may not be appropriate."

On Thu, Mar 31, 2022 at 7:59 AM Alan DeKok 
wrote:

> On Mar 31, 2022, at 10:29 AM, Bernard Aboba 
> wrote:
> >
> >  I am CC'ing the RADEXT WG mailing list, since the errata relates to a
> widely implemented RADIUS specification.
> >
> > Errata 6154:
> >
> > While Alan is correct that a RADIUS attribute with no data is not
> permitted by RFC 2865, and RFC 3579 is ambiguous about the length, I am
> concerned about the potential backward compatibility impact of this
> change.  In practice, is the EAP-Start being sent with a length of 2 or 3?
> Suggesting it be sent with a length of 3 is fine, but I'd suggest adding
> language stating that RADIUS servers should be aware of existing practice
> (e.g. be able to deal with a length of 2 if it is received).  We want to be
> careful not to break existing RADIUS clients.
>
>   Existing practice is all over the place.  I agree that the text should
> be clear that the RADIUS server should accept whatever is sent.  But also
> state that sending EAP-Message of zero length is not allowed.
>
>   Perhaps the new text should say:
>
>EAP-Start is indicated by sending an EAP-Message attribute with a
>length of 3.  The single byte of data SHOULD be set to zero on
>transmission and MUST be ignored on receipt.  RADIUS clients MUST NOT
>send EAP-Message attributes of length 2, as attributes with no value
>are not permitted in RADIUS.  However, for historical reasons and for
>compatibility with existing practice, RADIUS servers MUST accept
> EAP-Messages
>of length 2, and treat them as EAP-Start.
>
>   Just checking the source I have locally, the server accepts zero-length
> EAP-Message (or any other text/string attribute, for that matter).  So
> that's fine.
>
>   However, it won't encode zero-length EAP-Message.  So if the server is
> asked to proxy zero-length EAP-Message attributes, that attribute will get
> silently dropped from the proxied packet.
>
>   Looking at the code, that encoding limit has been there since 2005.
> I've never heard anyone complaining about it.  So I think it's safe to say
> that there are few, if any, RADIUS clients which send EAP-Message with
> length==2.
>
> > Errata 6259:
> >
> > I believe the original text is correct here.  EAP method types 1-3
> (Identity, Notification, Nak) are typically implemented locally on the NAS,
> so that the device 

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Bernard Aboba]

 I am CC'ing the RADEXT WG mailing list, since the errata relates to a
widely implemented RADIUS specification.

Errata 6154:

While Alan is correct that a RADIUS attribute with no data is not permitted
by RFC 2865, and RFC 3579 is ambiguous about the length, I am concerned
about the potential backward compatibility impact of this change.  In
practice, is the EAP-Start being sent with a length of 2 or 3?  Suggesting
it be sent with a length of 3 is fine, but I'd suggest adding language
stating that RADIUS servers should be aware of existing practice (e.g. be
able to deal with a length of 2 if it is received).  We want to be careful
not to break existing RADIUS clients.

Errata 6259:

I believe the original text is correct here.  EAP method types 1-3
(Identity, Notification, Nak) are typically implemented locally on the NAS,
so that the device (e.g. an 802.11 access point) can handle these methods
without interacting with the RADIUS server.  In some cases, an EAP Type of
4 (MD5-Challenge) was also implemented on the NAS (e.g. for 802.1X on
Ethernet) and would be set as the default method.  If the peer did not wish
to use the default method, it would need to send a NAK.



On Thu, Mar 31, 2022 at 2:08 AM Independent Submissions Editor (Eliot Lear)
 wrote:

> Dear EMU working group,
>
> Alan Dekok has reported two errata[1,2] against RFC 3579.  RFC 3579 is
> classed an independent submission, and thus falls under the purview of
> the Independent Submissions Editor (ISE).  The ISE is inclined to verify
> both errata, and will do so in the next two months unless this group
> advises otherwise.
>
> Eliot Lear (ISE)
>
> [1] https://www.rfc-editor.org/errata/eid6154
> [2] https://www.rfc-editor.org/errata/eid6259
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

[Bernard Aboba]

I still find the proposed Section 2.1 confusing.  How about this?

"If the TLS implementation correctly implements TLS version negotiation,
EAP-TLS will automatically leverage that capability.
The EAP-TLS implementation needs to know which version of TLS was
negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward
compatibility with EAP-TLS 1.2.

TLS 1.3 changes both the message flow and the handshake messages compared
to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216]
does not apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document
applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then
[RFC5216] applies."






On Fri, Jun 18, 2021 at 10:15 PM John Mattsson 
wrote:

> Hi Bernard,
>
>
>
> Thanks for your comments on backward compatibility. I think PR #83
> addresses your comments. I did not write anything about TLS 1.0 and TLS 1.1
> as RFC 8996 (which updates RFC 5216) formally forbids support and
> negotiation of these weak versions.
>
>
>
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files
>
>
>
> Below is how the two related paragraphs would look after merging #83.
>
>
>
>
>
> 1.  Introduction:
>
>
>
> This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3.
> When older TLS versions are negotiated, RFC 5216 applies to maintain
> backwards compatibility. However, this document does provide additional
> guidance on authentication, authorization, and resumption for EAP-TLS
> regardless of the underlying TLS version used. This document only describes
> differences compared to [RFC5216]. All message flow are example message
> flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS
> couples the TLS handshake state machine with the EAP state machine it is
> possible that new versions of TLS will cause incompatibilities that
> introduce failures or security issues if they are not carefully integrated
> into the EAP-TLS protocol. Therefore, implementations MUST limit the
> maximum TLS version they use to 1.3, unless later versions are explicitly
> enabled by the administrator.
>
>
>
> 2.1  Overview of the EAP-TLS Conversation:
>
>
>
> TLS 1.3 changes both the message flow and the handshake messages compared
> to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216]
> does not apply for TLS 1.3. EAP-TLS 1.3 remains backwards compatible with
> EAP-TLS 1.2 [RFC5216] . TLS version negotiation is handled by the TLS
> layer, and thus outside of the scope of EAP-TLS. Therefore so long as the
> underlying TLS implementation correctly implements TLS version negotiation,
> EAP-TLS will automatically leverage that capability. Except for Sections
> 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS
> 1.2 is negotiated, then [RFC5216] applies. The EAP-TLS implementation needs
> to know which version of TLS that was negotiated.
>
>
>
> Cheers,
>
> John
>
>
>
>
>
> *From: *Emu  on behalf of Joseph Salowey <
> j...@salowey.net>
> *Date: *Monday, 14 June 2021 at 01:54
> *To: *Bernard Aboba 
> *Cc: *EMU WG 
> *Subject: *Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
>
>
>
>
>
> On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba 
> wrote:
>
> draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:
>
>
>
>EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS 
> version
>
>negotiation is handled by the TLS layer, and thus outside of the
>
>scope of EAP-TLS.  Therefore so long as the underlying TLS
>
>implementation correctly implements TLS version negotiation, EAP-TLS
>
>will automatically leverage that capability.
>
>
>
> I am concerned that this statement is potentially misleading. An
> implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key
> hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an
> implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and
> utilizes the key hierarchy defined in Section 2.3 of that document.
>
>
>
> So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?
>
>
>
> The only way this makes sense to me is if it is stated that
> draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that
> if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.
>
>
>
>
>
> [Joe] Good point.  I think this is missing from the draft.  The EAP-TLS
> implementation does need to know which version of TLS is negotiated.   I
> agree that this draft applies to when TLS 1.3 is negotiated and not
> previous versions of TLS.
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP TLS 1.3 backward compatibility with RFC 5216

[Bernard Aboba]

draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:

   EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216]
. TLS version
   negotiation is handled by the TLS layer, and thus outside of the
   scope of EAP-TLS.  Therefore so long as the underlying TLS
   implementation correctly implements TLS version negotiation, EAP-TLS
   will automatically leverage that capability.


I am concerned that this statement is potentially misleading. An
implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key
hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an
implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and
utilizes the key hierarchy defined in Section 2.3 of that document.

So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?

The only way this makes sense to me is if it is stated that
draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that
if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Review of draft-ietf-emu-eap-tls13

[Bernard Aboba]

Alan --

Thanks for the very thorough review comments.

"Implementations should not make the same mistake with TLS 1.4 as was

done with TLS 1.3.  Therefore, this document should explicitly call
out this issue, and suggest a path for implementations to follow."

[BA] Agree, particularly given that other TLS changes could be coming
in future (e.g. post-quantum support).

"   The EAP-TLS
   server always commits to not send any more handshake messages by
   sending a TLS close_notify alert."

[BA] From the interop testing, it seems that application data is more
implementable.

"e.g. The "no peer authentication" situation MUST NOT be used to give
normal network access to EAP peers.  Instead, deployments SHOULD
provide access which is limited in both time, and in capability.
Usually this means a "quarantine" network, or "walled garden", which
has only limited capability.

Also, the Security Considerations section has no discussion of the
security impact of not authenticating the peer.  As Section 2.1.5 is
new, it has major impacts on security, and thus needs to be discussed."

[BA] Agree, especially due to security vulnerabilities that have
arisen in this area.

"NIT: the exporters were first defined in TLS 1.2, and have been widely
available in TLS library implementations.  Using master secret,
etc. has not been necessary for a while.  Further, the "non-standard"
use of Master Secret, etc. was first done in the original EAP-TLS RFC
[2716], in 1999.  The TLS WG later defined and stanardized the
exporters in order to meet the needs of EAP-TLS."

[BA] Agree. RFC 2716 defined the original TLS exporter, so calling it
"non-standard" is wrong.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

>
>
>
> The -13 commitment message verifies that both sides are in possession of a
> derived key. But the server finished already does that. As you state, the
> -13 commitment message is not an alternative success indication. I think it
> would be easy to make it an alternative success indication be mandating
> that the EAP-TLS server must only send it after verifying the client
> finished. I do not think defining a new exporter is needed.
>
>
>
> The -14 close_notify is also not an alternative success indication and can
> not be made into one either.
>
>
>
> If the requirement is that an alternative authenticated success indication
> is needed. Then I think:
>
>
>
> - We need to have an extra roundtrip.
>
> - close_notify does not work and cannot be made to work
>
> - Application data commit message could work as an alternative success
> indication. TLS would have to be profiled so the alternative success is
> only send be EAP-TLS server after client finished processed successfully.
>
>
>
> 2. At what point should keys be pushed down to the lower layer?
>
>
>
> What is the exact requirement for eapKeyAvailable = TRUE to be set?
>
>
>
> My understanding reading RFC 4137 (correct me if I am wrong) is that it is
> not enough that the other party is authenticated, but that an alternative
> success indication has been sent/received. If that is correct the EAP-TLS
> server would set eapKeyAvailable = TRUE after sendign the alternative
> success indication and the EAP-TLS client would set eapKeyAvailable = TRUE
> after receiving the alternative success indication.
>
>
>
> 3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?
>
>
>
> Yes, I agree, receipt of TLS Alert messages should be considered an
> alternative failure mechanism.
>
>
>
> 4. What is the purpose of the commitment message?
>
>
>
> The -01 to -13 purpose was to indicate in an authenticated way that the
> EAP-TLS method would not continue and that only success or failure could
> follow.
>
>
>
> If an alternative success indication is required. Which it seems to be
> according to your mail. I think the alternative success indication would
> replace the old commitment message.
>
>
>
> I think
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Emu   on behalf of
> Bernard Aboba  
> *Date: *Tuesday, 2 February 2021 at 16:25
> *To: *"emu@ietf.org"   
> *Subject: *[Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
> The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
> interacts with the EAP state machine as specified in RFC 4137.  It appears
> to me that this under-specification is at the root of the questions about
> the commitment message.
>
>
>
> Historically, under-specification of the EAP-TLS state machine has been a
> source of potential security vulnerabilities by enabling packet injection
> attacks [1][2], including attacks involving the injection of EAP-Success
> and EAP-Failure mechanisms.
>
>
>
> RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:
>
>
>
>altAccept (boolean)
>
>
>
>   Alternate indication of success, as described in [RFC3748 
> <https://tools.ietf.org/html/rfc3748>].
>
>
>
>altReject (boolean)
>
>
>
>   Alternate indication of failure, as described in [RFC3748 
> <https://tools.ietf.org/html/rfc3748>].
>
>
>
>eapKeyData (EAP key)
>
>
>
>   Set in peer state machine when keying material becomes available.
>
>   Set during the METHOD state.  Note that this document does not
>
>   define the structure of the type "EAP key".  We expect that it
>
>   will be defined in [Keying 
> <https://tools.ietf.org/html/rfc4137#ref-Keying>].
>
>
>
>eapKeyAvailable (boolean)
>
>
>
>   Set to TRUE in the SUCCESS state if keying material is available.
>
>   The actual key is stored in eapKeyData.
>
>
>
> The issue in the EAP-TLS 1.3 specification is that the interlock with these 
> variables is not defined.
>
>
>
> For example, it appears to me that the commitment message verifies that both 
> sides are in possession of a derived key,
>
> allowing the eapKeyData variables to be set.  However, it does not appear to 
> me that the successful validation of the commitment message is
>
> sufficient to allow keys to be pushed down to the lower layer, allowing data 
> to flow.
>
> Therefore the eapKeyAvailable variable should not yet be set to TRUE.
>
>
>
> Also, the commitment message does not constitute an

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

John said:


"Based on your comments it seems like protected success indication is not
needed in IEEE 802 for security reasons."


[BA] As described in RFC 4137, protected success indications prevent
attacks involving injection of unprotected EAP-Failure indications, as well
as enabling key synchronization.  So yes, they do serve a purpose.


Would also be good to conclude that other methods do not need an alternate
success indication.


[BA] That would not be good, because it would be an incorrect conclusion.



Note that RFC 4137 is informal and not mandatory to follow.


[BA] Every EAP implementation I am aware of supports RFC 4137.  It was
specifically developed to address security vulnerabilities that were
considered serious enough to block deployment of EAP.  So you can say it is
"informal", "not required", etc. but in practice it is implemented and
necessary.


Similarly a implementation can ignore the alternative success indication
unless EAP-TLS 1.3 makes it mandatory.


[BA] Implementers are going to support alt success and alt failure
indications, as they indicated on the mailing list, because those
indications have been supported by EAP-TLS and other secure EAP methods for
more than a decade. It's not productive to re-introduce security
vulnerabilities into EAP after years of work to remove them.

On Sun, Feb 7, 2021 at 10:39 PM John Mattsson 
wrote:

> Thanks Mohit,
>
>
>
> Based on your comments it seems like protected success indication is not
> needed in IEEE 802 for security reasons. Would be good with more feedback
> on this. EAP-TLS 1.3 might get a protected success indication anyway, but
> the draft should have a few sentences about what the alternate success
> indication is good for. Would also be good to conclude that other methods
> do not need an alternate success indication. Seems like e.g. RFC 5448
> removed the optional result indications from RFC 4187, probably after an
> agreement that they were not needed.
>
>
>
> Note that RFC 4137 is informal and not mandatory to follow. Similarly a
> implementation can ignore the alternative success indication unless EAP-TLS
> 1.3 makes it mandatory. In RFC 5216 it is to my understanding up to the
> implementation if it wants to use server Finished as a alternate success
> indication.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Mohit Sethi M 
> *Date: *Monday, 8 February 2021 at 06:33
> *To: *John Mattsson , Bernard Aboba <
> bernard.ab...@gmail.com>, "emu@ietf.org" , "t...@ietf.org" <
> t...@ietf.org>
> *Subject: *Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
> Hi all,
>
> I have now read both the papers. I am not sure the attacks in [2] are
> anymore possible:
>
> - The first attack described in section 4.1.1 shows that an EAP-Success
> leads to an unconditional transition to the Authenticated state
> irrespective of the current state. However, I am not sure this is the case
> anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1)
> now says :
>
>  |+--
>
>  |  rxSuccess &&  |
>
>  |  (reqId == lastId) &&  |   SUCCESS
>
>  |   (decision != FAIL)   |
>
>  |+--
>
> The peer cannot simply transition to SUCCESS state as the decision is
> initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only
> after the peer decides that the server has sufficiently been authenticated
> (for EAP methods with mutual authentication).
>
> - The second attack described in section 4.2 relies on the adversary
> sending a disassociate management frame and then uses the MAC address of
> the authenticated supplicant to gain network access. This again should not
> work as a) 802.11w-2009 protects disassociate management frame, and b)
> EAP-Success is followed by 4-way handshake after which there is per packet
> authenticity and integrity (with Key Confirmation Key). The attacker cannot
> gain network access without knowing the PMK (derived from the MSK) and
> performing the 4-way handshake.
>
> The attacks in [1] are not specific to EAP. The attacks relate to Denial
> of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the
> following text for the draft (which I think is sufficient):
>
> Protected TLS Error alerts are protected failure result indications and
> enables the EAP-TLS peer and EAP-TLS server to determine that the failure
> result was not spoofed by an attacker. Protected failure result indications
> provide integrity protection and replay but MAY 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

John said:

"The keying material becomes available in the EAP-TLS server after the

   server Finished has been sent.  The keying material becomes available
   in the EAP-TLS peer after the server Finished has been received."

[BA]  There is a distinction between when keys are available on the EAP
server,  and when they are transmitted by the EAP Server to the
authenticator (after an EAP-Success is sent).  Also, there is a distinction
between when the EAP peer derives the keys and when they are to be pushed
down to the lower layer (this should only happen after an alternative
success indication is received). The state machine is more driven by the
transmission/push-down of keys than by their mere derivation.

I'll let the implementers comment on the practicality of a close_notify as
an alternative success indication, as opposed to other potential solutions.





I'll let the implementers comment on the practicality of what you are
proposing.

On Thu, Feb 4, 2021 at 3:14 PM John Mattsson 
wrote:

> Hi Bernard,
>
>
>
> 802.11 is a very important use case for EAP-TLS so if an authenticated
> alternate success indication is needed there, it absolutely needs to be
> supported by EAP-TLS 1.3
>
>
>
> I updated the EAP state machine chapter based on your comments.
>
>
>
> ---
>
> 2.5.  EAP State Machines
>
>
>
>This is a new section when compared to [RFC5216] and only applies to
>
>TLS 1.3 (or higher).  [RFC4137] offers a proposed state machine for
>
>EAP
>
>
>
>TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
>
>Handshake messages use the handshake content type and can be sent
>
>after the main handshake.  Examples of Post-Handshake messages are
>
>NewSessionTicket, which is used for resumption and KeyUpdate, which
>
>is not useful and not expected in EAP-TLS.  After sending TLS
>
>Finished, the EAP-TLS server may send any number of Post-Handshake
>
>messages in separate EAP-Requests.
>
>
>
>To provide an authenticated success result indication and to decrease
>
>the uncertainty for the EAP-TLS peer, the following procedure MUST be
>
>followed:
>
>
>
>When an EAP-TLS server has successfully processed the TLS client
>
>Finished and sent its last handshake message (Finished or a Post-
>
>Handshake), it commits to not sending any more handshake messages by
>
>sending a TLS close_notify alert.  The TLS close_notify alert is an
>
>authenticated success result indication, as defined in [RFC3748].
>
>After sending the TLS close_notify alert, the EAP-TLS server may only
>
>send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS
>
>close_notify alert before it has successfully processed the client
>
>finished and sent its last handshake message.
>
>
>
>Receipt of any TLS Error alert SHOULD be considered a failure result
>
>indication, as defined in [RFC3748].  After sending or receiving a
>
>TLS Error alert, the EAP-TLS server may only send an EAP-Failure.
>
>
>
>The keying material becomes available in the EAP-TLS server after the
>
>server Finished has been sent.  The keying material becomes available
>
>in the EAP-TLS peer after the server Finished has been received.
>
> ---
>
>
>
> I used RFC 3748 terminology as RFC 4237 is an informal draft.
>
>
>
> close_notify is now an authenticated success result indication (close_notify
> could be replaced by TLS application data).
>
>
>
> My undertstanding from RFC 4137 is that eapKeyAvailable and
> aaaEapKeyAvailable seems
>
> to be automatically set at success if eapKeyData and aaaEapKeyData are set.
>
>
>
> if (eapKeyData != NONE)
>
>   eapKeyAvailable = TRUE
>
>
>
> if (aaaEapKeyData != NONE)
>
>   aaaEapKeyAvailable = TRUE
>
>
>
> I therefore only described when the "keying material becomes available"
> which is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.
>
>
>
> Open question if Section 2.5 should say something about TLS 1.2.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *John Mattsson 
> *Date: *Thursday, 4 February 2021 at 15:22
> *To: *Bernard Aboba , "emu@ietf.org" <
> emu@ietf.org>, "t...@ietf.org" 
> *Subject: *Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
>
>
> I think the major decision for the EMU WG to make going forward is to
> agree if EAP-TLS 1.3 MUST have an alternative success

Re: [Emu] EAP-TLS protected result indications

[Bernard Aboba]

The discussion largely happened in 802.11 since that was where the
vulnerability vulnerability was discovered (by Bill Arbaugh at UMD).
Documentation of the required signals was in RFC 4137, tests on the fixed
implementations were done by UMD and subsequent analysis and security
proofs were done by the Mitchell group at Stanford.

On Tue, Feb 2, 2021 at 15:53 Joseph Salowey  wrote:

>
> [Joe] Aha, It's coming back to me now and it does seem that
> implementations do this.  Do you know if the implementation requirements
> were documented anywhere?
>
>
>
>> ___
>> Emu mailing list
>> Emu@ietf.org
>> https://www.ietf.org/mailman/listinfo/emu
>>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP-TLS protected result indications

[Bernard Aboba]

Joe Salowey said:

"[Joe] Based on RFC 5216 the server could fail the finished message or as

section 2.1.3 shows it could send the finish and then it can send an
Alert and result in EAP-Failure.  In this case it would be possible
for an attacker to remove the Alert and send a success.  Whether your
implementation ends up in this scenario or not probably depends upon why
the auth failed and the behavior of your TLS library.

I do not believe that RFC 5216 provides protected result indications.
 It would be a fine thing to add, but it is new to the specification
and I'm not sure that is why the commitment message was added to begin
with."

[BA] EAP-TLS implementations do provide protected result indications.
Due to injection attacks, implementations were modified to support RFC
4137 so as to protect against spoofed EAP-Success and EAP-Failure
messages.  For example, implementations of the EAP-TLS state machine
should not be driven by EAP-Success and EAP-Failure messages, which
are unprotected. This ensures that an Alert sent after Finish will be
correctly recognized as an alternate failure indication, regardless of
whether an attacker injected an EAP-Success message in between.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

[Bernard Aboba]

Alan DeKok said:

"The way forward is to resolve open issues. Publishing the current draft
would be premature.

IMHO we are still nowhere near agreement. There are many open questions
which have not been resolved."

[BA] Agreed. The recently published draft does not resolve the open issues
or bring the specification closer to being ready for publication.

At this point, it would be best for the implementers to work through the
issues at the Hackathon (or before) and report back to the WG at IETF 110
as to the solutions they have found and the level of interoperability
achieved.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
interacts with the EAP state machine as specified in RFC 4137.  It appears
to me that this under-specification is at the root of the questions about
the commitment message.

Historically, under-specification of the EAP-TLS state machine has been a
source of potential security vulnerabilities by enabling packet injection
attacks [1][2], including attacks involving the injection of EAP-Success
and EAP-Failure mechanisms.

RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:

   altAccept (boolean)

  Alternate indication of success, as described in [RFC3748
].

   altReject (boolean)

  Alternate indication of failure, as described in [RFC3748
].


   eapKeyData (EAP key)

  Set in peer state machine when keying material becomes available.
  Set during the METHOD state.  Note that this document does not
  define the structure of the type "EAP key".  We expect that it
  will be defined in [Keying
].

   eapKeyAvailable (boolean)

  Set to TRUE in the SUCCESS state if keying material is available.
  The actual key is stored in eapKeyData.


The issue in the EAP-TLS 1.3 specification is that the interlock with
these variables is not defined.


For example, it appears to me that the commitment message verifies
that both sides are in possession of a derived key,

allowing the eapKeyData variables to be set.  However, it does not
appear to me that the successful validation of the commitment message
is

sufficient to allow keys to be pushed down to the lower layer,
allowing data to flow.

Therefore the eapKeyAvailable variable should not yet be set to TRUE.


Also, the commitment message does not constitute an alternative
success indication because it is possible for an

alternative failure indication (e.g. a TLS alert) to be sent after the
commitment message.

If the commitment message did constitute an alternative success
mechanism, then an attacker injecting an

EAP-Success message would be able to cause the peer to believe that
authentication

had succeeded even though it had actually failed (e.g. TLS alert sent
after the commitment message).


Given these issues, I believe the specification needs to answer
several questions:


1. What constitutes an "alternative success" indication in the EAP-TLS
1.3 protocol?

2. At what point should keys be pushed down to the lower layer?

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

4. What is the purpose of the commitment message?


Only question 3 looks straight forward to me: receipt of TLS Alert
messages should be considered an alternative failure mechanism,

although perhaps some caveats need to be applied to address the
injection attacks described in [1].


[1] EAP Vulnerabilities and Improvements, Extensible Authentication
Protocol Vulnerabilities and Improvements (sjsu.edu)


[2] An Analysis of the IEEE 802.1X Standard, An Initial Security
Analysis of the IEEE 802.1X Standard | Request PDF (researchgate.net)

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP-TLS 1.3 Hackathon at IETF 110

[Bernard Aboba]

In order to better validate existing implementations of EAP-TLS 1.3, we
will be organizing an EAP-TLS 1.3 Hackathon at IETF 110.

The goal of the hackathon is to test operating system client
implementations (Android, iOS, Mac OS X, Windows) with server
implementations over the Internet.

If you are interested in participating in the Hackathon, please contact
Alan and myself.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP - TLS 1.3

[Bernard Aboba]

The big question is "Why not create a new EAP method"?

The overall intent seems to be to create an pre-shared key EAP method
optimized for 5G, based on EAP-TLS v1.3.

Since the protocol described will not interoperate with any of the existing
2+ billion EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS
name?   What has been described is an entirely distinct authentication
method, not a "clarification" to an existing specification.

In fact, from how it has been described, it would appear that the new
protocol is only for use with new devices supporting 5G and new 5G servers
supporting the new method.  In which case, if the new method is not for
general use on the Internet, why can't 3GPP just define the method
themselves and allocate their own private EAP type code?

On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko  wrote:

> I don’t want to push the decision in either direction without looking into
> the details.
>
> But I wanted to point out that there’s usually a third alternative between
> “no need for new documents” and “need a new RFC to describe the new
> version”. Explaining that the old protocol can be used and what the
> implications are may by itself be a useful document. In the specific
> example, is not immediately obvious to me for instance if the security
> consideration would somehow change, or if 0-RTT can or can not be used, etc.
>
> Jari
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Reap] EAP - TLS 1.3

[Bernard Aboba]

Alan said:

"That's good.  But as Bernard points out, there's no need to change
EAP-TLS.  You can just use TLS 1.3."

[BA] Existing implementations enable organizations to impose TLS version
and ciphersuite requirements on *their* devices.  For example, I have
worked with organizations that require FIPS 140-3 support, who impose those
cryptographic requirements through policy. Of course, such a constraint may
bring with it the need to upgrade EAP-TLS clients and AAA servers - but
that cost is imposed *only* on the organization imposing the policy.

 "I think one of the concerns here is the procedural aspect.  Your proposal
was to forbid everyone *else* from using TLS 1.0 because your requirements
were for TLS 1.3.  That's not the way to gain support."

[BA] The proposal would force the replacement of 2+ billion EAP
implementations along with millions of smartcards and other hardware that
is incompatible with TLS 1.3.  It would also make every EAP-TLS
implementation subject to patent declarations on later TLS versions.  A
search through the IPR declaration database discloses a horrifying number
of declarations that would apply as a result.

A proposal imposing such extraordinary costs requires extraordinary
justification.  So far, I am not aware of a declaration from any standards
organization or authority that versions of TLS prior to 1.3 need to be
phased out.

"In addition, your other arguments are hand-waving, and don't provide
concrete details to back up your position.  Having concrete details would
help."

[BA] So far, I read the argument as "Someone implementing EAP-TLS from
scratch with TLS 1.3 might not get it right."  But given the *huge* number
of deployed devices out there, we need something much more concrete - like
test data demonstrating a real interoperability problem.

On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok 
wrote:

> On Nov 16, 2017, at 12:16 AM, Mohit Sethi 
> wrote:
> >
> > Coming back to our motivation for this draft. 3GPP has decided that
> authentication in 5G can be done with any type of credential that the
> operator accepts and that EAP will be used for authentication. The working
> assumption is that EAP-TLS will be used for mutual authentication with
> certificates. 3GPP would likely want to use TLS 1.3 as much as possible,
> especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in
> EAP-TLS as well as providing encryption of the handshake including the
> certificates.
>
>   That's good.  But as Bernard points out, there's no need to change
> EAP-TLS.  You can just use TLS 1.3.
>
>   I think one of the concerns here is the procedural aspect.  Your
> proposal was to forbid everyone *else* from using TLS 1.0 because your
> requirements were for TLS 1.3.  That's not the way to gain support.
>
>   In addition, your other arguments are hand-waving, and don't provide
> concrete details to back up your position.  Having concrete details would
> help.
>
> > If the EAP community decides that RFC5216 adequately describes how to
> use TLS 1.3 and does not need an update we can live with that. Our
> conclusion is however that an update of RFC2516 is needed for several
> reasons:
> >   • RFC5216 is very much tied to the message flows and message
> formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3
> is very different. While a developer could theoretically figure out how to
> use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216
>
>   How so?  5216 says (essentially) "encapsulate TLS within EAP".  How,
> exactly, does this change with TLS 1.3?
>
> > and in the worst case, implementations would not even be compatible.
> >   • TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS
> 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update
> defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is
> done in draft-ietf-quic-tls) is needed.
>
>   Implementations of EAP-TLS do need to change when the key derivation
> changes.  Such as for TLS 1.2.  However, those changes are largely limited
> to the TLS library, not the EAP-TLS code.
>
> >   • RFC5216 specifies that "EAP-TLS implementations MUST support TLS
> v1.0".
>
>   You're free to deprecate TLS 1.0 in documents which update RFC5216... if
> you have IETF consensus.
>
>   Further, you're free to mandate use of TLS 1.3 in 5G specifications.
> They're your specifications, and you're free to ignore IETF requirements if
> you so choose.
>
> >   • RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC,
> and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS
> version).
>
>   The same comment as above applies here.
>
> >  If IETF does not provide new message flow diagrams for EAP-TLS with TLS
> 1.3, it is likely that 3GPP will do that, we would much rather see an IETF
> RFC that 3GPP and other can refer to.
>
>   What, exactly is different with 

Re: [Emu] RFC 5216 updates, backwards compatibility and open source

[Bernard Aboba]

Alan said:

"  I concur.

  Not only because I'm an open source implementer.  But also because that
software supports networks encompassing hundreds of millions of devices.
Software which is used by all network equipment vendors.  It is just
infeasible to mandate that all devices upgrade to TLS 1.3."

[BA] The scale of EAP implementation is truly sobering - billions of
devices. Not only does this involve software, but also hardware such as
badges that may not support new ciphersuites (e.g. elliptic curves).  Given
that support for RFC 5216 may be required due to security policies or
regulatory mandates, requiring those organizations to throw away all those
badges and replace them requires serious justification, and concurrence
from respected organizations known for their cryptographic and security
expertise, such as NIST.

Without a *serious* justification (such as an unpatchable vulnerability),
attempting to impose a "forced migration" is not just practically
infeasible - it is deeply irresponsible, and would expose the IETF to very
well deserved ridicule.

Alan also said:

"For me, it's 2017.  Any proposal that does not address existing
deployments is one that should be ignored, as being out of touch with
real-world use-cases."

[BA] I fully agree.

On Thu, Oct 26, 2017 at 5:57 PM, Alan DeKok <al...@deployingradius.com>
wrote:

> On Oct 26, 2017, at 8:24 PM, Bernard Aboba <bernard.ab...@gmail.com>
> wrote:
> > To provide backwards as well as forwards compatibility, EAP-TLS was
> designed to to support new versions of TLS, including versions introducing
> new ciphersuites.
> > So while RFC 5216 mandates support for TLS 1.0 to preserve backwards
> compatibility, it does not mandate the use of TLS 1.0 or any other version
> in a given installation.  This allows organizations to manage their
> deployments (and required ciphersuites) as they see fit.  For example, an
> organization wiling to take on the costs of migrating all of their devices
> and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated
> ciphersuites is fully able to do so within the framework laid out by RFC
> 5216. \
>
>   Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.  Not
> because TLS1.2 is bad, but because in some cases, the upgrade was
> *mandated* by the OS vendor.  This forced upgrade caused massive
> incompatibilities.  Which led the OS vendors to back off on their
> requirements.
>
>   i.e. with billions of devices supporting EAP-TLS, there are hundreds of
> millions which support only old versions of TLS.  Devices which cannot
> realistically be upgraded.
>
>   Moving to newer versions of TLS is a decision best left to site
> administrators.  They should be *strongly recommended* to use the best
> available crypto.  But mandating it is counter-productive.  Such mandates
> cause administrators to stick with older server software that is compatible
> with older systems.
>
> > However, what RFC 5216 does NOT attempt to do is to mandate a world-wide
> non-backward compatible "forklift" upgrade for TLS versions of
> ciphersuites.  Such a non-backward compatible "forklift" update would be
> extra-ordinarily costly, requiring the upgrading of every device
> implementing EAP-TLS, including devices that do not use the protocol
> regularly, if ever.
> >
> > Despite this lack of "central management" imposed by the IETF, the
> record of EAP-TLS forward compatibility appears to be pretty good. At this
> point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am
> aware of several implementations of EAP-TLS now testing support for TLS
> 1.3, without any changes to the protocol.
>
>   That has been my experience, too.
>
> > I was therefore surprised to come across draft-mattsson-eap-tls13 which:
> >
> > 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.  As
> noted earlier, organizations requiring support for TLS 1.3 can easily
> impose such a requirement on their EAP-TLS devices, if the cost and
> security benefits justify it.  However, since RFC 5216 is referenced in
> many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without
> extraordinary justification (such as discovery of a critical security flaw
> that cannot be patched in previous versions) would impose enormous costs.
> >
> > 2. Invalidates the existing security proofs of EAP-TLS by introducing
> new authentication modes (such as EAP PSK) that were specifically rejected
> by the EMU WG so to ensure that high-security installations could ensure
> that certificate-based authentication, and only cert-based authentication
> was provided by their EAP-TLS implementations.
> >
> > This reversal of an EMU WG decision is very 

Re: [Emu] RFC 5216 updates, backwards compatibility and open source

[Bernard Aboba]

With implementations shipping on virtually every major platform (e.g.
Android, iOS, Mac OS X, Windows, Linux ,etc.) EAP-TLS (RFC 5216) is now
supported on  2+ billion devices worldwide. This includes numerous open
source implementations for both the EAP client and server.

In particular, EAP-TLS, due to its focus on certificate-authentication, has
been deployed widely in environments requiring the highest levels of
security, such as critical infrastructure, and military/national security
installations.  In these environments, EAP-TLS's provable security
properties are considered critical, as is backward compatibility with the
hardware ecosystem that has grown up around EAP-TLS, providing addons such
as employee smartcard badges, or hardware-based certificate storage.

Given the enormous number of deployed devices, the widespread
implementation in open source, and the potential impact on national
security and critical infrastructure, it is very important that updates to
EAP-TLS consider backwards compatibility, retain the provable security, and
avoid introduction of royalty-bearing IPR and the introduction of security
vulnerabilities.

To provide backwards as well as forwards compatibility, EAP-TLS was
designed to to support new versions of TLS, including versions introducing
new ciphersuites.
So while RFC 5216 mandates support for TLS 1.0 to preserve backwards
compatibility, it does not mandate the use of TLS 1.0 or any other version
in a given installation.  This allows organizations to manage their
deployments (and required ciphersuites) as they see fit.  For example, an
organization wiling to take on the costs of migrating all of their devices
and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated
ciphersuites is fully able to do so within the framework laid out by RFC
5216.

However, what RFC 5216 does NOT attempt to do is to mandate a world-wide
non-backward compatible "forklift" upgrade for TLS versions of
ciphersuites.  Such a non-backward compatible "forklift" update would be
extra-ordinarily costly, requiring the upgrading of every device
implementing EAP-TLS, including devices that do not use the protocol
regularly, if ever.

Despite this lack of "central management" imposed by the IETF, the record
of EAP-TLS forward compatibility appears to be pretty good. At this point
support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am aware
of several implementations of EAP-TLS now testing support for TLS 1.3,
without any changes to the protocol.

I was therefore surprised to come across draft-mattsson-eap-tls13 which:

1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.  As
noted earlier, organizations requiring support for TLS 1.3 can easily
impose such a requirement on their EAP-TLS devices, if the cost and
security benefits justify it.  However, since RFC 5216 is referenced in
many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without
extraordinary justification (such as discovery of a critical security flaw
that cannot be patched in previous versions) would impose enormous costs.

2. Invalidates the existing security proofs of EAP-TLS by introducing new
authentication modes (such as EAP PSK) that were specifically rejected by
the EMU WG so to ensure that high-security installations could ensure that
certificate-based authentication, and only cert-based authentication was
provided by their EAP-TLS implementations.

This reversal of an EMU WG decision is very unwise since it has the
potential to introduce new security vulnerabilities into the systems
protecting some of the world's most sensitive data.

3. Removes much of the security guidance of RFC 5216 addressing known
interoperability and security issues.

4. Does not discuss the potential IPR implications of introducing a TLS 1.3
requirement into a protocol that is widely implemented in open source.





--

Although I see that the EMU WG concluded earlier this year, I’d like to ask
those on this mail list to consider whether an update to RFC 5216 may be
worth pursuing.


Wireless LAN deployments commonly leverage the EAP-TLS standard. The IEEE
took steps earlier this year to raise the bar for wireless security through
publishing the new 802.11ac standard.


RFC 5216 currently requires TLS 1.0, and the only mandatory cipher suite
specified is TLS_RSA_WITH_3DES_EDE_CBC_SHA. I’d like to suggest updating
the standard in a manner that also requires mandatory support for TLS 1.2
and ECDHE_ECDSA AEAD cipher suites.



Best regards,

Clint



Clint McKay

NSA Information Assurance
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Question about EAP Session-Id in EAP SIM and AKA

[Bernard Aboba]

Since the EAP Session-Id is utilized in EAP lower layers such as IEEE 
802.1X-2010, the interoperability of an EAP method implementations can be 
affected by the definition of the Session-Id.   One important requirement for 
the Session-Id is that it be unique for each EAP session.  That is, a fast 
reauthentication should produce a new Session-Id.  Recently, some questions 
have arisen about the Session-Id specified in EAP SIM, AKA and AKA'.  

As per RFC 5247, the Session-Id is (0x12 | RAND | NONCE_MT) in EAP SIM.  
However, when fast re-authentication happens these attributes are not 
exchanged. There is another unique attribute NONCE_S sent from server to 
client. So the question has arisen as to whether the Session-Id should it be 
(0x12 | NONCE_S) when fast re-authentication happens. The same question arises 
in EAP AKA/AKA' as well.
  ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] security paper on tunneled authentication

[Bernard Aboba]

Katrina Hoeper said:

Unfortunately, it seems to be too late to reference the analysis in the
tunnel requirement draft, but I hope that some people still might find it
interesting.

[BA] The paper represents the most comprehensive analysis of tunneled
authentication security to date, and brings into question a number of
assumptions that have been made as to how MITM in the middle attacks can be
mitigated. In looking over the tunnel requirements document,  there are
only a few places where the issue of MITM attacks is discussed, so if you
believe there are changes that need to be made, you should go ahead and
propose them.  

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

[Bernard Aboba]

Part of the confusion here may be that we're talking about unauthenticated at 
multiple layers.  There is unauthenticated network access, and then there is 
unauthenticated VOIP signaling.  

These are two orthogonal things.  The VOIP signaling should not change 
regardless of whether the network access is authenticated or unauthenticated. 

Similarly, it's possible to use authenticated or unauthenticated VOIP signaling 
over authenticated or unauthenticated access.  

Focusing solely on how to obtain unauthenticated access, the question is how 
the client signals that it is interested in unauthenticated access.  This is 
important, because otherwise the server might request client authentication 
(e.g. a client certificate request).  Essentially the sos NAI is functioning 
similar to the anonymous NAI in that this results in special processing on 
the AAA server side.



Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks 
on the emergency.com domain)
Date: Mon, 22 Mar 2010 18:14:59 -0700
From: jsalo...@cisco.com
To: dirk.kroeselb...@nsn.com; h...@cs.columbia.edu; bernard_ab...@hotmail.com
CC: ec...@ietf.org




















I do not think EAP or NAI should be used as a signaling mechanism
for emergency.These mechanisms are ways to obtain network access
when you cannot in some other way.  Once you have network access it seems
that the emergency procedures should be the same whether you authenticated to
get network access or you gained access though another mechanism. 

 

I am probably missing some ECRIT specific nuances here, but I feel
that tying emergency procedures at higher layers to EAP usage will be fraught
with problems. 

 

Joe

 

 





From:
ecrit-boun...@ietf.org [mailto:ecrit-boun...@ietf.org] On Behalf Of Kroeselberg,
Dirk (NSN - DE/Munich)

Sent: Monday, March 22, 2010 5:26 PM

To: ext Henning Schulzrinne; Bernard Aboba

Cc: ec...@ietf.org

Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of
serviceattacks on the emergency.com domain)





 



yes, fixing the NAI to a simple string is simple (this would
basically be a NAI that is username only, correct?).





 





However, let me repeat my question from the other thread: How to
handle the 'authenticated' emergency case where the NAI carries the regular
username? The draft may be about unauthenticated, but just covering
unauthenticated and leaving the authenticated case open
seems less useful to me.





 





Dirk





 







From: ext Henning
Schulzrinne [mailto:h...@cs.columbia.edu] 

Sent: Tuesday, March 23, 2010 1:02 AM

To: Bernard Aboba

Cc: Kroeselberg, Dirk (NSN - DE/Munich); ec...@ietf.org

Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service
attacks on the emergency.com domain)



The sos name seems to be a reasonable approach
that's simple and easy. 





 





Longer term, I think a better option is to have a
semi-authenticated mode: Imagine a setup where VSPs or other trustable bodies
hand out tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. The
ISP is given the right to monitor the usage of 'sos' sessions and can hand the
token to the appropriate authorities for prosecution in case of abuse. That
way, you get emergency access, but make it unlikely that the system will be
abused on a large scale. In some countries, you might get such a token from
your local public authority when you're registering your residence.





 





Henning



 





On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote:











If all you want to do is to gain emergency
access to the local network, you don't need to discover the domain.  You
can just use an NAI of sos.   That will be more
convenient in situations where the local access mechanism (e.g. 802.1X) doesn't
permit IP packets (including DHCP) to pass prior to completing authentication,
so that domain discovery couldn't occur until afterwards. 





 



  ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

[Bernard Aboba]

Yes, there is an anonymous NAI, but the goal of that is to hide the  
identity from the NAS and eavesdroppers, not to enable client  
unauthenticated access.


On Mar 22, 2010, at 10:23 PM, Richard Barnes rbar...@bbn.com wrote:

In particular, providing unauthenticated *network* access is a  
prerequisite for providing unauthenticated *VoIP* access.


Also, Bernard: Does your below mention of anonymous NAI indicate  
that there is actually a reserved NAI anonymous?  If so, then I  
don't really see the use for a separate sos NAI -- you can just  
provide ECRIT access to anonymous.


--Richard



On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote:

Part of the confusion here may be that we're talking about  
unauthenticated at multiple layers.  There is unauthenticated  
network access, and then there is unauthenticated VOIP signaling.


These are two orthogonal things.  The VOIP signaling should not  
change regardless of whether the network access is authenticated or  
unauthenticated.


Similarly, it's possible to use authenticated or unauthenticated  
VOIP signaling over authenticated or unauthenticated access.


Focusing solely on how to obtain unauthenticated access, the  
question is how the client signals that it is interested in  
unauthenticated access.  This is important, because otherwise the  
server might request client authentication (e.g. a client  
certificate request).  Essentially the sos NAI is functioning  
similar to the anonymous NAI in that this results in special  
processing on the AAA server side.




Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of  
serviceattacks on the emergency.com domain)

Date: Mon, 22 Mar 2010 18:14:59 -0700
From: jsalo...@cisco.com
To: dirk.kroeselb...@nsn.com; h...@cs.columbia.edu; bernard_ab...@hotmail.com
CC: ec...@ietf.org

I do not think EAP or NAI should be used as a signaling mechanism  
for emergency.These mechanisms are ways to obtain network  
access when you cannot in some other way.  Once you have network  
access it seems that the emergency procedures should be the same  
whether you authenticated to get network access or you gained  
access though another mechanism.


I am probably missing some ECRIT specific nuances here, but I feel  
that tying emergency procedures at higher layers to EAP usage will  
be fraught with problems.


Joe


From: ecrit-boun...@ietf.org [mailto:ecrit-boun...@ietf.org] On  
Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)

Sent: Monday, March 22, 2010 5:26 PM
To: ext Henning Schulzrinne; Bernard Aboba
Cc: ec...@ietf.org
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of  
serviceattacks on the emergency.com domain)


yes, fixing the NAI to a simple string is simple (this would  
basically be a NAI that is username only, correct?).


However, let me repeat my question from the other thread: How to  
handle the 'authenticated' emergency case where the NAI carries the  
regular username? The draft may be about unauthenticated, but just  
covering unauthenticated and leaving the authenticated case open  
seems less useful to me.


Dirk

From: ext Henning Schulzrinne [mailto:h...@cs.columbia.edu]
Sent: Tuesday, March 23, 2010 1:02 AM
To: Bernard Aboba
Cc: Kroeselberg, Dirk (NSN - DE/Munich); ec...@ietf.org
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of  
service attacks on the emergency.com domain)


The sos name seems to be a reasonable approach that's simple and  
easy.


Longer term, I think a better option is to have a semi- 
authenticated mode: Imagine a setup where VSPs or other trustable  
bodies hand out tokens (e.g., using the OAuth-WARP work) that the  
ISP recognizes. The ISP is given the right to monitor the usage of  
'sos' sessions and can hand the token to the appropriate  
authorities for prosecution in case of abuse. That way, you get  
emergency access, but make it unlikely that the system will be  
abused on a large scale. In some countries, you might get such a  
token from your local public authority when you're registering your  
residence.


Henning

On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote:


If all you want to do is to gain emergency access to the local  
network, you don't need to discover the domain.  You can just use  
an NAI of sos.   That will be more convenient in situations where  
the local access mechanism (e.g. 802.1X) doesn't permit IP packets  
(including DHCP) to pass prior to completing authentication, so  
that domain discovery couldn't occur until afterwards.



___
Ecrit mailing list
ec...@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit




___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Liaison Statement, Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authentication and key management in a data communication network

[Bernard Aboba]

This is a review of ITU Study Group 17, TD 0495, which represents a revision
of ITU-T X.1034.  For details, see:

https://datatracker.ietf.org/documents/LIAISON/file714.pdf

 

General Observations

 

Looking at this document, I don't see much evidence that the ITU-T has made
an effort to incorporate the

feedback that EMU provided during the last review:

https://datatracker.ietf.org/liaison/470/

 

 

This document is out of date, given that it doesn't reflect EAP developments
over the last 5+ years.  Looking

through the reference section, there are still references to RFC 2284
(instead of RFC 3748),  and no references to later

EAP-related documents including RFC 4851,  RFC 5247, RFC 5296, etc.Those
references that are provided are frequently

out of date, represent expired or incorrect versions, etc.   Even the
references to IEEE 802.11 are years out of date. 

 

The problem goes deeper than just the references, though.  In the past 5
years, we have seen development of quite a 

few new EAP methods, new approaches to key management, new applications
lower layers incorporating EAP, etc. 

We have also see organizations such as NIST (with 800-120) providing
in-depth security analyses.  

 

Given all of this new activity, the most basic question that this document
raises for me is What unique value is this

document attempting to provide above and beyond what the IETF, IEEE 802,
NIST and other groups are already

doing?

 

After reading this document, I still didn't have a clear idea of the goals
and objectives. 

 

One possible answer to the question lies in Table 1, which attempts to
classify EAP methods in terms of their levels of security 

(fundamental, middle-level, high-level).  

 

However, I'm not clear what value this table adds beyond what is already in
NIST 800-120, RFC 4017 or other documents. 

In fact, one might argue that it muddies the waters since a number of
fundamental security properties such as Authorization 

and Unique Naming are not listed as only recommended or optional, whereas
these are treated as not as method properties 

but as fundamental properties of the EAP/AAA system as described in RFC
3748, 4296 and RFC 5247.   

 

Another possibility lies in the general description of the security
properties of EAP.  However, in the last five years we have

seen many, many studies of this published none of which are referenced in
the document.  This includes formal analyses

(e.g. The Stanford analysis of IEEE 802.11 security, by John Mitchell's
team, work in Bill Arbaugh's group, etc.),  NIST

800-120, RFC 4296, 5247, etc.  

 

Of course, we have also seen extensions to the EAP model introduced in RFC
5296.  This is also not described in the

document. 

 

Not only are all these aspects not referenced or described, but in numerous
places the document uses terminology

specific to IEEE 802.   For example, the document discusses types of PTK,
and group key handshake.Non-IEEE 802

technologies typically don't use the term PTK, and IEEE 802.1X-REV does
not include a group key handshake. 

Moreover the general flow of key management described in Section 8.4 is
not general at all, since this does not

describe the lower layer key management used in IKEv2 or IEEE 802.16. 

 

Moving on to Table I.1, the document evaluates EAP MD5 (does anyone care
about this anymore?),  EAP SRP (long abandoned)

against a series of critieria.  If this table is worth including at all,
it's worth making the effort to bring it up to date.  

 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt (part 2)

[Bernard Aboba]

Section 5.1

   The local database is perhaps the most important part of this system.
   In order for the EAP server or AAA server to know whether i1 and i2
   are correct, they need access to trustworthy information, since an
   authenticator could include false information in both i1 and i2.
   Additional reasons why such a database is necessary for channel
   bindings to work are discussed in the next subsection.  The
   information contained within the database could involve wildcards.
   For example, this could be used to check whether WiFi access points
   on a particular IP subnet all use a specific SSID.  The exact IP
   address is immaterial, provided it is on the correct subnet.

[BA] Is it really true that the IP address of the NAS is always immaterial?  
For example, couldn't a 
NAS lie about its IP address in order to impersonate another NAS? 

   During an EAP method execution with channel bindings, the goal is to
   transport i1 from the peer to the EAP server, and allow the system to
   verify the consistency of i1 provided by the peer, i2 provided by the
   authenticator, and the information in the local database.  Upon the
   check, the EAP server sends a message to the peer indicating whether
   the channel binding validation check succeeded or failed and
   optionally includes all or some of the information that was used in
   the check.  The message flow is illustrated in Figure 1.

[BA] Is it always necessary for the EAP server to provide information to the 
peer 
about why the channel binding check succeeded or failed?  While this info might 
be helpful for
debugging, it seems like there could be situations in which the AAA server just 
returns an
Accept/Reject indication. 

   If the compliance of i1 or i2 information with the authoritative
   policy source is mandatory and a consistency check failed, then after
   sending a protected indication of failed consistency, the EAP server
   MUST send an EAP-Failure message to terminate the session.  If the
   EAP server is otherwise configured, it MUST allow the EAP session to
   complete normally, and leave the decision about network access up to
   the peer's policy.

[BA] I would suggest that normative language is not appropriate here.  For one 
thing, an EAP-Failure
does not actually result in the host being denied access to the network -- an 
Access-Reject is what
accomplishes this.  Also, since an EAP-Failure (or EAP-Success) may not be 
delivered, it doesn't make
sense to rely on it.  Furthermore, couldn't there be situations where rather 
than denying access 
some other action is taken, such as putting up a warning message, isolating the 
host in some way
(e.g. filters or VLAN setting, etc.)?  

Section 5.2

   These checks enable the EAP server to detect lying NAS/authenticator
   in enterprise networks and lying providers in service provider

[BA] As noted in the previous message, these checks do not actually enable the 
determination of whether
a provider is lying. 

   Checking the consistency of i1 and i2 is nontrivial, as has been
   pointed out already in [HC07].  First, i1 can contain any type of
   information propagated by the authenticator, whereas i2 is restricted
   to information that can be carried in AAA attributes.  

[BA] Actually, i1 can only contain information that is both propagated by the 
authenticator *and*
passed up by the host in the proper format.  This requires coordination between 
the
driver implemented on the host and the EAP method.   In practice, this has been 
a major impediment
to implementation of Channel Bindings, because without driver changes, many of 
the parameters desired
by channel binding implementations will not be available. 

Similarly, the database referred to in this section also requires a non-trivial 
effort to put together,
comparable to the wire map required to support geographic location or 
emergency services calling. 

   For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as
   the authentication method, and maximal-length identities are used, a
   maximum of 384 octets are available for conveying channel binding.

[BA] This is an important point -- and one that indicates that the ability to 
implement channel
bindings is limited on EAP methods that don't support fragmentation.  

Section 6.3

   If transporting data within a lower-layer's secure association
   protocol (SAP), this protocol MUST support transport of integrity
   protected data using a key known only by the EAP peer and EAP server,
   and not known to the authenticator.  There must be mechanism whereby
   the authenticator can transport the protected payloads to the EAP
   server, either via a AAA protocol or some other means, and receive a
   protected result.

[BA] This paragraph does not make sense, because by definition the SAP
exchange occurs between the authenticator and the peer, and therefore
any keys derived in the process need to be known by the authenticator
and the peer.  In a 

Re: [Emu] Working Group Last Call for draft-ietf-emu -chbind-04.txt (part 3)‏

[Bernard Aboba]

Section 9.2
 

   Additional network entities (such as proxies) might be on the
   communication path between peer and server and may attempt to
   manipulate the channel binding protocol.  If these entities do not
   possess the keying material used for integrity protection of the
   channel binding messages, the same threat analysis applies as for the
   dishonest authenticators.  Hence, such entities can neither
   manipulate single channel binding messages nor the outcome.  On the
   other hand, entities with access to the keying material must be
   treated like a server in a threat analysis.  Hence such entities are
   able to manipulate the channel binding protocol without being
   detected.  However, the required knowledge of keying material is
   unlikely since channel binding is executed before the EAP method is
   completed, and thus before keying material is typically transported
   to other entities.

[BA] Unless the transient EAP keys used for integrity protection are derivable 
from the 
MSK, possession of the MSK would not be sufficient to enable an authenticator 
to modify 
the channel bindings.  As a result, the only entities relevant to the threat 
analysis 
are those that possess the TEKs, not just those that possess the MSK or other 
derived keys.  




  ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access

[Bernard Aboba]

Section 6
 
   signalling allows an IEEE 802.1X to occur without exchanging

   cryptogrpahic keys

 

[BA] Not sure what this is saying.  In IEEE 802.1X-2004, there is no
encryption supported.  However, EAP is still run.  This can include methods
that don't generate keys (e.g. EAP-MD5).  But the issue here is client
unauthenticated access, not key generation, right? 

 

Section 6.1

 

   In general, link layer emergency indications provide good integration
   into the actual network access procedure regarding the enabling of
   means to recognize and prioritize an emergency service request from
   an end host at a very early stage of the network attachment
   procedure.  However, support in end hosts for such methods cannot be
   considered to be commonly available.



 

[BA] I'm not sure what this is referring to.  If it's referring to QoS,
those mechanisms are independent of emergency indications (e.g. WFA WMM).
If it's talking about higher layer emergency service prioritization, that's
also independent of the lower layer.  So what exactly is a host expected to
do at the lower layer to distinguish an emergency call?  

 

Section 6.2

 

In normal operation, EAP related
   information will only be recognized in the NAS.  Any entity residing
   between end host and NAS should not be expected to understand/parse
   EAP messages.



 

[BA] The EAP architecture requires the NAS to be EAP-method agnostic if it's
acting as a pass-through.  So even the NAS can't be depended upon to
understand/parse EAP methods.  But why would it need to? 

 

   1.b) Emergency NAI: The NAI comes with a realm or username part
   indicating emergency (e.g. 'emerge...@emergency.com').  An advantage
   of this method for NAA cases is that no new requirements are put on
   the involved signaling procedures.  Only the identity used for
   network entry is impacted.  Potential disadvantages include that
   different methods to indicate emergency for NAA cases and standard
   emergency network attachments may be required.  Also, modifying the
   NAI itself (the usern...@realm part) may conflict with network
   selection and network entry procedures, depending on the actual
   access network.



 

[BA] There are two distinct ideas being presented here.  One is to define an
emergency user name (e.g. emergency); another is to define an emergency
domain (e.g. emergency.com).  The former concept may make sense, but the
latter one is dangerous since existing systems not including the emergency
realm in their routing tables may just return an error.  So the question is
what realm should be used, if any.  The problem with including any realm is
that it assumes realm reachability.  If reachability doesn't exist, then the
host will get an error.  If there is no realm, then the local realm needs to
recognize the emergency username, and utilize an appropriate EAP method that
allows client unauthenticated access. 

 

   2) Emergency EAP method
 
   An emergency indication can be given by using a dedicated EAP method
   that is reserved for emergency network attachment only.



 

[BA] Why is a dedicated EAP method needed for emergency access?  EMU WG has
already discussed this and come up with mechanisms that would allow client
unauthenticated access from any TLS-based method (e.g. server side either
doesn't ask for a client cert, or accepts the client not providing one).
That mechanism is supported in RFC 5216, and can also be applied to existing
methods such as EAP FAST, EAP TTLSv0, PEAP, etc. 

 

In effect, the only real constraint here is that a local network advertising
support for emergency calling needs to support one or more of these methods.


 

   2.a) Existing EAP method with new type: An existing EAP method may be
   used.  EAP methods themselves typically do not support emergency
   indication.  One option would be to pick a common EAP method like
   EAP-TLS and allocate a new method type for the same method that is
   exclusively reserved to emergency use.  Such EAP method should be
   chosen in a way that the same method can support NAA cases as well as
   standard emergency network attachment.
 



 

Given that RFC 5216 already supports client-unauthenticated anonymous access
(see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a
new method type? 

 

   2.b) Existing EAP method: Same as 2a), but without assigning a new
   EAP method type for emergency.  In this case some implicit indication
   must be used.  For example, in cases where EAP-TLS is used in network
   attachment in combination with client certificates, the absence of a
   client certificate could be interpreted by the network as a request
   for emergency network attachment.



 

[BA] The combination of an emergency NAI *and* the absence of a client
certificate would be considered a request for emergency attachment.  If an
NAI corresponding to an existing account is used, then normal policies will
apply (which would probably require 

Re: [Emu] #18 Internationalization of error messages

[Bernard Aboba]

Yes, this makes more sense. 

 
 Subject: RE: [Emu] #18 Internationalization of error messages
 Date: Tue, 8 Sep 2009 19:26:20 -0700
 From: jsalo...@cisco.com
 To: bernard_ab...@hotmail.com; emu@ietf.org
 
 OK, makes sense. How about we make the language tags specific to text
 sent from the server to the peer that is intended to be displayed to a
 user. We can also specifically state that it is also acceptable to send
 numeric codes that can be mapped to a specific representation by the
 client to meet the internationalization requirement. These codes would
 not be internationalized even if they were in ASCII/UTE-8 format. 
 
 Does this make sense?
 
 Thanks,
 
 Joe
 
  -Original Message-
  From: Bernard Aboba [mailto:bernard_ab...@hotmail.com] 
  Sent: Tuesday, September 08, 2009 7:09 PM
  To: Joseph Salowey (jsalowey); emu@ietf.org
  Subject: RE: [Emu] #18 Internationalization of error messages
  
  I don't have a problem with requiring support for UTF-8 in 
  usernames and passwords within authentication mechanisms 
  native to the tunnel method. However, I do have an issue 
  with requiring internationalization of error message text. 
  
  One of the principles of good protocol design is to *avoid* 
  internationalization problems within error messages by use of 
  error numbers (e.g. 404 in HTTP and SIP). This makes it 
  possible for client software to display localized versions of 
  error messages without requiring the server to support 
  internationalization.
  
  If the tunnel protocol incorporates error numbers, it should 
  therefore not be necessary for the server to send 
  internationalized error text. 
  
  Adding requirements for internationalization of error text or 
  negotiation of language tags for error messages is not only 
  unnecessary, it is actually enforcing a requirement for a 
  *bad design*. 
  
  
  
  
  
  
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP and authorization

[Bernard Aboba]

Steve Hanna said:

 

However, I agree that it would be better to get IESG clarification

that carrying authorization data in EAP is permissible. As Alan

suggested, the first step is probably to have a WG consensus

check to verify that we have rough consensus that this should

be permitted. After that, maybe we would ask the IESG for a

clarification of the applicability statement for EAP.

 

I will note that the IESG has already approved a change to the

EMU charter to add a work item for channel bindings. So they

have already indicated their support for that effort.

 

Do we really need IESG clarification or a consensus check to verify that


IESG approval of a work item for channel bindings should be

interpreted as approval to actually work on channel bindings???

 

Given that Channel Bindings is discussed in both RFC 3748 and 5247,  I

think we can say definitively that regardless of whether Channel Bindings

are actually useful (personally, I have doubts) that they are within the

the scope of applicability of RFC 3748.  

 

However, since those documents make it clear that Channel Bindings were 

not intended as a generic authorization exchange (despite the confusion on 

that point within the Channel Bindings document).   Therefore IESG approval
of 

a Channel Bindings work item should not be construed as a license to change 

the definition of Channel Bindings to satisfy another distinct need.   Doing

so would require updating of RFC 3748 and 5247, which is not within the EMU

WG charter. 

 

 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP and authorization

[Bernard Aboba]

   The discussion here is (a) if we can get *some* generic authorization
 passed via methods used for Channel Bindings, and (b) is that a good idea.
 
   I think that the answer to (a) is yes, and (b) is some say yes,
 some say no.

Existing RFCs are clear that Channel Bindings have a specific purpose and 
are not a generic authorization mechanism.  For example, RFC 3748 
Section 7.15 states:

   In order to address this vulnerability, EAP methods may support a
   protected exchange of channel properties such as endpoint
   identifiers, including (but not limited to): Called-Station-Id
   [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address
   [RFC3162].

   Using such a protected exchange, it is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  Where discrepancies
   are found, these SHOULD be logged; additional actions MAY also be
   taken, such as denying access.


Given the above (and similar material in RFC 5247),  it would seem (surprise!) 
that channel bindings relate to properties of the channel.   Despite the 
confusion 
introduced by Section 1 of the Channel Bindings document, the parameters 
actually discussed in the Channel Bindings document generally appear consistent 
with existing work.  

I say generally because the document does appear to need an update or two.
For example,  Section 7.3.2 of the Channel Bindings document
introduces the Mesh-Key-Distributor-Domain-Id.  My understanding is that
this parameter has been removed from 11s, so this section is now out of date.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Impersonation and Lying NAS problem: two distinctissues (with different solutions)

[Bernard Aboba]

Qin said:

Based on this, impersonation issue seems to overlap with channel binding or 
lying NAS issue.

RFC 3748 Section 7.15 describes the distinction between the two problems:

   Section 4.3.7 of [RFC3579] describes how an EAP pass-through
   authenticator acting as a AAA client can be detected if it attempts
   to impersonate another authenticator (such by sending incorrect NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
   [RFC3162] attributes via the AAA protocol).  However, it is possible
   for a pass-through authenticator acting as a AAA client to provide
   correct information to the AAA server while communicating misleading
   information to the EAP peer via a lower layer protocol.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Channel Bindings and Authorization

[Bernard Aboba]

Dan Harkins stated:

 

  I don't think what you're talking about falls into the definition

of channel binding, at least not the one I have, and I wouldn't be

surprised if others (like maybe people on the IESG) agree. And I

agree with Dave, and Glen, that this isn't authentication either.

 

RFC 3748 and RFC 5247 define Channel Bindings as well as describing their
use within the

EAP architecture.   For example, RFC 5247 Section 1.4 defines discusses
potential uses of 

Channel Bindings by EAP methods:

 

   Channel Binding

 

  Channel binding is the process by which lower-layer parameters are

  verified for consistency between the EAP peer and server.  In

  order to avoid introducing media dependencies, EAP methods that

  transport channel binding parameters MUST treat this data as opaque
octets.

 

 

Given that Channel Bindings are to be treated as opaque octets by the EAP
method,  and that they are

Intended for use in encoding lower layer parameters, it's hard to see how
Channel Bindings could be 

construed as a general authorization mechanism.  

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] AAA and EAP

[Bernard Aboba]

Glen Zorn said:

 

Yes, it is, but it doesn't have to be.  In IEEE 802.1X-2004, for example,
the transition from the Authenticating state to the Authenticated state
in the PAE machine is triggered by the reception of an Accept message from
the Back-end authentication server, not by EAP-Success.  In fact, great
pains are taken to ensure that the correct EAP message (Success or
Failure) is sent to the supplicant, the correctness being based not on the
actual result of the EAP authentication but on the decision of the AAA
server.



 

RFC 3579 makes it clear that the Accept/Reject sent by the AAA server 

controls the behavior of the AAA client, not the encapsulated EAP packet. 

This clarification was made in response to interoperability issues that

arose in situations where Access-Reject/EAP-Success or

Access-Accept/EAP-Failure packets were sent.  While RFC 3579 does not

forbid these packets, it does recommend against their use, since

they can result in inconsistent interpretations of the authentication

exchange between the EAP peer and authenticator. 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions)

[Bernard Aboba]

Dan Harkins said:

When there are 3 parties involved in this 2 party protocol it is
justified by saying that the EAP server trusts the NAS so there is no
security issue when MSK is disclosed to it. But what NAS identity does
the EAP server trust? The peer and EAP server derive a shared key and
for the key to be disclosed to another entity the peer and EAP server
must have a consistent view of the identity of that entity. If they cannot
arrive at a consistent view of all identities then the protocol deriving
the key fails. That is not an authorization issue, it's an authentication
issue.

RFC 5247 Section 5.3.2 describes problems that can result from a NAS 
impersonating another NAS.   Section 5.3.3 describes the Channel
Binding problem, which is logically distinct. 

As noted in Section 5.3.2, it is not possible for a AAA server more
than one hop from the NAS to verify the NAS Identity.  This verification
must be handled at the first hop proxy. 

Given this, it will typically be outside the scope of a Channel Binding
Implementation to address the impersonation issue.  

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] #18 Internationalization

[Bernard Aboba]

Joe Salowey said:

#18: Internationalization

 Is the use of UTF-8 sufficient or is other tagging necessary.  The
 following cases need to be considered:

 1. Usernames and passwords
 2. Prompts and error associated with username and password
authentication
 3. Other textual data


It's important to keep in mind that this is a tunnel method requirements 
document.  The tunnel method will use TLS, so as far as bringing up the tunnel 
is concerned, it is TLS internationalization that is relevant here.  With 
respect to inner authentication methods, it is the internationalization support 
of the inner method that matters. 

Given this, what exactly is within the purview of the tunnel method with 
respect to internationalization?  Clearly, the EMU WG is not chartered to 
change EAP itself, TLS or existing EAP methods.  

Given that, what *exactly* does this requirement refer to?   While it's 
certainly possible for a tunnel method to do language negotiation, given that 
such a negotiation wouldn't affect most of what goes on in the method (e.g. TLS 
or the inner method), I don't see what good it would do. 




___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] RFC 2759 Issue

[Bernard Aboba]

RFC 2759 Section 4 states:

 

   The Name field is a string of 0 to (theoretically) 256 case-sensitive ASCII 
characters which identifies the peer's user account name.

This text, if taken literally, would imply that the name field cannot natively 
support international character sets.  

 

Yet tests show that 8-bit characters can be (and are) sent.  From a 
cryptographic point of view, the Name field appears to be treated as opaque 
octets.   While existing Windows implementations appear to encoding the Name 
field using ANSI code pages,  from a protocol point of view it would appear 
that a peer and server configured with a Name field encoded in UTF-8 should be 
able to communicate.   

 

Therefore, a potential correction to this sentence is the following:

 

The Name field is a string of 0 to (theoretically) 256 octets identifying the 
peer's user account name.  Implementations SHOULD treat the Name field as 
opaque octets. 





 EMAILING FOR THE LESSER EVIL
Join me___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Key derivation differences

[Bernard Aboba]

  RFC 5216 describes the relationship between the MSK and the receive
  and send keys (which was how the MSK was originally defined
  in RFC 2716):
 
  Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
  (MS-MPPE-Recv-Key in [RFC2548]). Also known as the
  PMK in [IEEE-802.11].
  Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
  (MS-MPPE-Send-Key in [RFC2548]
 
 Right, but this formula assumes that MS-MPPE-Recv-Key and -Send-Key
 are 32 bytes (256 bits). The keys produced by RFC 3079 Section 3.3
 are only 128 bits, so concatenating any two of them (in any order)
 doesn't produce an EAP MSK (which is at least 64 octets).


Does the following more accurately describe what you are seeing?

 

At the end of successful authentication, EAP-MSCHAPv2 derives two 16-byte

MPPE keys as specified in [RFC3079] Section 3.3.  The Master Session Key 
([RFC3748])

is derived from the two MPPE keys as follows:

 

MSK = 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte 
MPPE-Receive-Key + 16 bytes zeroes (padding)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Key derivation differences

[Bernard Aboba]

 But Section 3.3 of RFC 3079 is not about EAP. It does specify how to
 calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit
 MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit
 ReceiveSessionKey. But how to get an EAP MSK from those is not
 specified.

RFC 5216 describes the relationship between the MSK and the receive
and send keys (which was how the MSK was originally defined in RFC 2716):

   Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
  (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
  PMK in [IEEE-802.11].
   Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
  (MS-MPPE-Send-Key in [RFC2548]
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Notes in EAP-FAST Documents

[Bernard Aboba]

Tim --

This works for me. 

Thanks (to you and other members of the IESG) for putting in the time to get 
this right. 


===
Folks,

As the AD that sponsored publication of the EAP-FAST documents under  
discussion,
I have been trying to find the best way forward.  I believe that the  
best course of action
involves some clarifications to draft-cam-winget-eap-fast- 
provisioning to distinguish
the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to  
ensure these
publications do not establish precedent for future reuse of EAP type  
codes with
different semantics.
First, I support revising draft-cam-winget-eap-fast-provisioning so  
that the modified
form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST- 
MSCHAPv2.  The
authors offered to make this change earlier in the thread, and I have  
seen some
support and no opposition to this suggestion.
Second, I will be offering the following text for IESG notes on both  
documents.  The
notes clearly state the drawbacks for EAP type code reuse and define  
an acceptable path for future protocol developers.
-- draft-cam-winget-eap-fast-provisioning -

EAP-FAST has been implemented by many vendors and it is used in the
Internet.  Publication of this specification is intended to promote
interoperability by documenting current use of existing EAP methods
within EAP-FAST.

The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code  
assigned to
EAP-MSCHAPv2 (26) for authentication within an anonymous TLS  
tunnel.  In
order to minimize the risk associated with an anonymous tunnel,  
changes
to the method were made that are not interoperable with EAP- 
MSCHAPv2.
Since EAP-MSCHAPv2 does not support method-specific version  
negotiation,
the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous
EAP-FAST tunnel.  This behavior may cause problems in  
implementations
where the use of unaltered EAP-MSCHAPv2 is needed inside an  
anonymous
EAP-FAST tunnel.  Since such support requires special case  
execution of
a method within a  tunnel, it also complicates implementations  
that use
the same method code both within and outside of the tunnel  
method. If
EAP-FAST  were to be designed today, these difficulties could be  
avoided
by utilization of unique EAP Type codes. Given these issues,  
assigned
method types must not be re-used with different meaning inside  
tunneled
methods in the future.

  draft-zhou-emu-fast-gtc  --

EAP-FAST has been implemented by many vendors and it is used in the
Internet.  Publication of this specification is intended to promote
interoperability by documenting current use of existing EAP methods
within EAP-FAST.

The EAP method EAP-FAST-GTC reuses the EAP type code assigned to
EAP-GTC (6).  The reuse of previously assigned EAP Type Codes is
incompatible with EAP method negotiation as defined in RFC  
3748.  Since
EAP-GTC does not support method-specific version negotiation,   
the use of
EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during
authentication. This behavior may cause problems in  
implementations where
the use of another vendor's EAP-GTC is required.  Since such  
support requires
special case execution of a method within a tunnel, it also  
complicates
implementations that use the same method code both within and  
outside of
the tunnel method. If EAP-FAST were to be designed today, these
difficulties could be avoided by utilization of unique EAP Type  
codes.
Given these issues, assigned method types must not be re-used with
different meaning inside tunneled methods in the future.

I am not under the illusion that this text will be entirely  
satisfactory to anyone,
but I believe that it is an *appropriate* resolution to the problem.

Thanks,

Tim Polk

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Key derivation differences

[Bernard Aboba]

Jouni Malinen said:

This looks like an appropriate text to add. However, I would request a
small clarification on the exact scope of the different EAP-MSCHAPv2 and
EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is
concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both
for unauthenticated (anonymous) and server-authenticated provisioning
while the proposed note seemed to indicate that the different behavior
is implied by the use of an anonymous tunnel. See below for suggested
changes to resolve this.

I'm assuming that the implicit challenges derived from the TLS handshake
are not used in the EAP-FAST authentication, i.e., normal authentication
would be using something that is closer to EAP-MSCHAPv2, not
EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2
differs a bit from the way it is used in other protocols, e.g., as far
as key derivation is concerned, but this would have been more of a
comment for RFC 4851 than these two drafts that are now discussed.
Anyway, since the key derivation from inner method is used also during
provisioning, it would be useful to specify the exact process used to
derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv
MS-MPPE keys which seems to differ from the way this is used in PEAPv0
with cryptobinding).


Are you suggesting that the version of EAP-MSCHAPv2 described in the document 
differs in terms
of the MSK/EMSK derivation?  Or are you suggesting that further details are 
needed on how padding
is accomplished with respect to ISK derivation?  

In general, ISK derivation doesn't relate to an EAP method so much as the 
tunneling method that
utilizes the keys exported by the inner method.  So if the issue is purely in 
the ISKs, then this
doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to 
EAP-FAST
provisioning mechanism. 
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Key derivation differences

[Bernard Aboba]

Just to make sure I understand this:

You are saying that in addition to the interoperability issues described in
Tim's note with respect to the EAP-FAST-MSCHAPv2, that this document
also does not conform to the key derivation specified in EAP MS-CHAPv2, 
and that as a result it can't interoperate with existing implementations of
EAP MS-CHAPv2, for regular non-provisioning uses?  


 Date: Wed, 11 Feb 2009 22:58:11 +
 From: da...@mitton.com
 To: j...@w1.fi
 CC: bernard_ab...@hotmail.com; emu@ietf.org
 Subject: Re: Re: [Emu] Key derivation differences

 Earlier, I felt like asking if there were any independently developed 
 implementations of EAP-FAST, now I see one.


 And we see what gets discovered when you attempt interoperabilty testing with 
 real running code.

 Dave.


 Feb 11, 2009 05:13:19 PM, j...@w1.fi wrote:

 On Wed, Feb 11, 2009 at 01:29:34PM -0800, Bernard Aboba wrote:

 Are you suggesting that the version of EAP-MSCHAPv2 described in the 
 document differs in terms
 of the MSK/EMSK derivation? Or are you suggesting that further details are 
 needed on how padding
 is accomplished with respect to ISK derivation?

 Former (for MSK part) as far as using EAP-MSCHAPv2 inside EAP-FAST is
 concerned (the document itself does not describe EAP-MSCHAPv2 MSK
 derivation).

 In general, ISK derivation doesn't relate to an EAP method so much as the 
 tunneling method that
 utilizes the keys exported by the inner method. So if the issue is purely in 
 the ISKs, then this
 doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to 
 EAP-FAST
 provisioning mechanism.

 What I noticed when implementing EAP-FAST and cryptobinding support for
 EAP-PEAPv0 is that I have to swap the order of MS-MPPE send/recv keys
 (i.e., swap octets 0..15 with 16..31) of the MSK from EAP-MSCHAPv2
 between PEAPv0 and EAP-FAST uses in order to interoperate with other
 implementations.

 In other words, EAP-FAST and EAP-PEAPv0(with cryptobinding) seem to use
 different derivation of ISK when using EAP-MSCHAPv2 as the inner method.
 I do not see need for similar swapping of the ISK octets with EAP-TLS as
 the inner method, so I would assume the difference is indeed in how the
 EAP-MSCHAPv2 MSK derivation is defined. After reviewing the description
 of the MS-CHAPv2 key derivation, I think I ended up agreeing with the
 way this is done in PEAPv0+cryptobinding and the order used in deployed
 EAP-FAST implementations would thus not match with the EAP-MSCHAPv2
 definition for MSK derivation.

 --
 Jouni Malinen PGP id EFC895FA
 ___
 Emu mailing list
 Emu@ietf.org
 https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] IANA allocation issue in EAP-FAST Documents

[Bernard Aboba]

Dan Harkins said:

 draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
 but nowhere in that RFC can I find description of the following label
 for an initial assignment of repository values:

 allocated for management by Cisco

 yet the draft instructs IANA to set aside values 11-63 for just that
 purpose. I think that's very inappropriate. Not only is it telling IANA
 to cede some of its authority to a large multinational corporation but
 it is decidedly *NOT* documenting existing use! If this whole exercise
 is to document existing use then where are the specifications for these
 PAC attribute types?

It would appear that the registry of EAP-FAST PAC Attribute Types relates
to a Standard Track document, RFC 4507, although the document itself
doesn't indicate that it updates RFC 4507.

RFC 5226 does permit vendor-specific registries, although it is somewhat odd to
enable vendor extensions for only one vendor, particularly if this does relate 
to
an IETF standards track document (which would imply IETF change control, no?)


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Potential Notes in EAP-FAST Documents

[Bernard Aboba]

IESG Note: EAP-FAST has been implemented by many vendors and it is
used in the Internet.  Publication of this is intended to promote
interoperability, even though the use of the EAP-MSCHAPv2 and
EAP-FAST-GTC EAP methods might be difficult in some software
environments.  If EAP-FAST were to be designed today, these
difficulties could be avoided by the assignment of new EAP Type
codes.

Although I concur with the assessments of Glen Zorn, Dan Harkins,
David Mitton and Dorothy Stanley in many respects, I would suggest that
those concerns are outweighed by the IETF's mission to make information
on deployed protocols available to the community.  As a result, I 
believe that the documents should be published, provided that the
following concerns can be addressed:

a. Name confusion.  The use of the term EAP-FAST-GTC instead of
EAP-GTC helps clarify that the two protocols are significantly
different.  Similarly, the use of the term EAP-FAST-MS-CHAPv2
would help clarify differences between the implementations of
EAP MS-CHAPv2, which I believe go beyond just the use of the
challenge field (e.g. internationalization support). 

b. EAP architecture changes.  Suggesting that EAP methods behave
differently when run within a TLS tunnel negotiating a particular
ciphersuite represents a major change to the EAP architecture
as well as to tunneling methods other than EAP-FAST.  This 
suggestion, if made at all, needs to be restricted solely to
use within EAP-FAST. 

c. EAP negotiation issues.  Neither the IESG note nor the
text explicitly states what is wrong with using an EAP Type 
Code for incompatible versions of an EAP method that does not
support version negotiation.  Indeed, it would appear that some
members of the IESG think that method overloading is required
by EAP tunneling methods desiring to incorporate support for
cryptographic binding.  Saying that this might be difficult
in some software environments isn't a good characterization. 
Would the IESG use the same words to describe the reuse of
IP protocol numbers within an IP tunnel?  I doubt it. 

Glen Zorn said:
I am strongly opposed to the publication of these documents as RFCs in their
current form.  Not only is the fast provisioning for EAP-FAST what can
only be characterized as a security disaster, but EAP-FAST-GTC has nothing
whatsoever to do with the EAP-GTC type.  EAP-GTC was defined for use with
various Token Card implementations which require user input but
EAP-FAST-GTC is used solely to transfer a username/password combination, the
password in plaintext.  It's hard to see what this has to do with actual
token cards  appears to be a lazy misuse of an existing type.  Furthermore,
it's even harder to see how rewarding this kind of nonsense with publication
will serve as a warning of any kind; I would expect that the action of
publication (with or without IESG note) would be more likely taken as notice
that one can do whatever one please without fear

David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on 
with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly
shocked by the nature of the changes, and how poorly they technically
met their own rationale.
Encoding the REQ= and RESP= into Request and Response text, is
absolutely useless, since the data flow is unidirectional and known to
the requester/responder peers.
And then claiming that is more efficent because the username and OTP
are combined in one response, really ignores the issue that GTC doesn't
define what the appropriate response is.  And they did nothing to clue
the client as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and
continue with the normal GTC state machine which is let the user type
something in and send it.
A more robust OTP implementation may have several different inputs
that it wants from the user besides for username and OTP.  (BTW;
username could be derived from the EAP Identity)   There are possible
next token challenges,  new PIN assignment (user or system generated) 
and followup re-authentications.   Their protocol did nothing to codify
a standard for interoperation where a sequence of requests were
enumerated or named, and response items were described.  
I'm all for documenting practice, but this design/implementation
doesn't really seem to solve anything and just creates more confusion.
Dave Mitton
Dan Harkins said:

  I strongly recommend against publication of these two documents.
They represent essentially proprietary hacks on established protocols.
The benefit in documenting use of EAP in the Internet today is far
outweighed by the damage done to existing protocol specification and
implementations. They will serve only to create spagetti code and
unnecessary complexity.

  In addition to the issues noted by others I will also point out that
information is being extracted from TLS for use in 

Re: [Emu] IANA allocation issue in EAP-FAST Documents

[Bernard Aboba]

Dan Harkins said:  draft-cam-winget-eap-fast-provisioning claims a reference 
to RFC 5226 but nowhere in that RFC can I find description of the following 
label for an initial assignment of repository values: allocated for 
management by Cisco yet the draft instructs IANA to set aside values 11-63 
for just that purpose. I think that's very inappropriate. Not only is it 
telling IANA to cede some of its authority to a large multinational 
corporation but it is decidedly *NOT* documenting existing use! If this whole 
exercise is to document existing use then where are the specifications for 
these PAC attribute types?Are you saying that the registry of EAP-FAST PAC 
Attribute Types also 
relates to RFC 4507, which is a standards track document?
 
If so, then I may see your point.  RFC 5226 does permit vendor-specific 
registries.  However, if the registry relates to a Standards Track protocol 
under
IETF change control, then restricting vendor-specific extensions to only one
vendor would be highly unusual.  ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP channel bindings and emergency services

[Bernard Aboba]

The IETF emergency services architecture depends on the ability to determine 
user location
so that it can be transmitted to the Public Service Access Point (PSAP).  
 
In a number of situations, user location is determined based on information 
provided by
network access infrastructure.  For example, the Location Information Server 
(LIS) might
determine the user location based on information provided by the NAS, such as 
the
NAS-IP-Address/NAS-IPv6-Address/NAS-Identifier attributes.  
 
In such situations, the consequences of a Lying or misconfigured NAS may be 
quite serious.  
For example, a NAS which is misconfigured or falsifying its identity within an 
Access-Request 
could lead to the PSAP sending emergency services personnel to the wrong 
location.
 
In situations where NAS attributes are being used for emergency service 
dispatch, 
checking the validity of those attributes seems like it would be quite 
important.  
For example, it would be useful not only to determine whether:
 
a. The NAS identification attributes sent in the Access-Request corresponds to 
the 
AAA credentials provided by the NAS; 
b. The NAS is advertising the same identity to the user as to the AAA 
infrastructure; 
c. The actual NAS location is consistent with the location assumed by the LIS; 
 
Issue a) should be detectable by a first hop AAA server checking the NAS 
identification
attributes against the source address of the AAA Request. 
 
Issue b) can be detected by checking the channel binding info provided by the 
peer
against the info provided by the AAA server
 
Issue c) can be detected by looking at accounting records to determine whether 
the
NAS location data is consistent with the observed handoff patterns.  For 
example,
one would not expect handoffs to occur regularly between a NAS located in New
York and one located in Pennsylvania.  
 ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Review of draft-clancy-emu-chbind-03.txt

[Bernard Aboba]

 
 describing how channel bindings addresses a number of specific attacks, 
 and a cost-benefit analysis.
 
 Can you be more specific about the cost-benefit analysis?  Do you mean a 
 monetary one?  Cost to operators or cost to equipment providers?
 
 --
 t. charles clancy, ph.d. eng.umd.edu/~tcc
 electrical  computer engineering, university of maryland
 
 
 Bernard Aboba wrote:
  Overview:  This version of the document still has some issues remaining.
   
  Section 1
   
 The so-called lying NAS problem is a well-documented problem with
 the current Extensible Authentication Protocol (EAP) architecture
 [RFC3748] when used in pass-through authenticator mode.  Here, a
 Network Access Server (NAS), or pass-through authenticator, may
 represent one set of information (e.g. identity, capabilities,
 configuration, etc) to the backend Authentication, Authorization, and
 Accounting (AAA) infrastructure, while representing contrary
 information to EAP clients.
  
  [BA] As noted in the review of -00, the issue isn't just whether the
  NAS is sending different information to the EAP peer and
  AAA server.  It also is possible that the NAS will send the same
  information to the peer and AAA server, but that both could be
  wrong.
   
  Section 3
   
 There are two different types of networks to consider: enterprise
 networks and service provider networks.  In enterprise networks, we
 assume a single administrative domain, making it feasible for an EAP
 server to have information about all the authenticators in the
 network.  In service provider networks, global knowledge is
 infeasible due to indirection via roaming.  When a client is outside
 its home administrative domain, the goal is to ensure that the level
 of service received by the client is consistent with the contractual
 agreement between the two service providers.
   
  [BA] While the AAA server might have information about all the 
  authenticators
  in the enterprise case, if it is more than one hop removed from the NAS, 
  then
  it might not be able to check the validity of the AAA attributes.  For 
  example,
  a first hop AAA server can check if the NAS-IP-Address/NAS-IPv6-Address
  attributes match the IP source address corresponding to the shared secret.
  A AAA server multiple hops away cannot verify this.
   
 o  Service Provider Network: An EAP-enabled mobile phone provider
operating along a geo-political boundary could boost their cell
towers' transmission power and advertise the network identity of
the neighboring country's indigenous provider.  This would cause
unknowing handsets to associate with an unintended operator, and
consequently be subject to high roaming fees without realizing
they had roamed off their home provider's network.
  
  [BA]  This seems like a good example.  My understanding is that
  power boosting actually does occur.  It might be worthwhile to consider
  adding an Appendix to talk about how channel bindings might address
  this or other potential examples. 
   
 o  It allows for fuzzy comparisons of network properties, rather than
requiring absolute comparisons.  This allows for a broader
definition of consistency, rather than bitwise equality.
  
  [BA] As discussed during the EMU WG meeting, a term other than fuzzy
  would probably be better.  Also, there probably needs to be more discussion
  on why enabling bit-by-bit comparisons is undesirable or not important.
   
  Section 4
   
 o  Given it doesn't affect the key derivation, exact use of the
results can be subject to policy, to facilitate debugging,
incremental deployment, and backward compatibility.
  
  [BA] I think the major issue with the key derivation approach is that in
  practice, canonicalization and formatting issues are highly likely in
  a channel bindings implementation, even if formats are well specified.
  The implication of this is that requiring enforcement may not be 
  practical; rather
  logging, or evidence gathering may be all that can be achieved.  The key
  derivation approach can't support such a logging only mode; enforcement
  is required.
   
 The scope of EAP channel bindings differs somewhat depending on the
 type of deployment in which they are being used.  In enterprise
 networks, they can be used to authenticate very specific properties
 of the authenticator (e.g.  MAC address, supported link types and
 data rates, etc), while in service provider networks they can
 generally only authenticate broader information about a roaming
 partner's network (e.g. network name, roaming information, link
 security requirements, etc).  The reason for the difference has to do
 with the amount of information you expect your home EAP server to
 know about the authenticator and/or network to which you are
 connected.  In roaming

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

[Bernard Aboba]

Alan DeKok said:

  Or, it was easier to say 'ASCII', and to avoid any unknowns that might
occur of 8-bit data is used.

  Given Stefan's test of MS-CHAP  ISO-8895-15 encodings, I think the
ASCII limitation in the spec is not matched by any similar limitations
in the code.

Unfortunately, in at least some implementations, this is not the case. 
However, I'd be interested if there exist implementations that handle
UTF-8 usernames.  That would provide a reference to test a fix against.  

  The CUI is often created as [EMAIL PROTECTED].  i.e. based off of the
User-Name.  So it's worth double-checking the effects of changing
User-Name on all down-stream uses.

Presumably the hash can be calculated on UTF-8 as well as ASCII, no? 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

[Bernard Aboba]

Alan DeKok said:

 [BA] RFC 4282 actually proposes that the realm portion of the NAI be
 encoded in punycode, not UTF-8.

  That's just wrong.

[BA] I agree.  I don't know of any EAP peers that encode the NAI this way
(although, based on Stefan's tests, they may not use UTF-8 either). 


 ...it is hard for me tosee how the NAI in EAP or
 RADIUS could be encoded in anything other than UTF-8. 

  I agree.  RFC 5335 Section 4.4 defines a utf8-addr-spec, which is:

utf8-local-part @ utf8-domain

  That's probably a good start for this document.

[BA] Interesting.  NAIs and e-mail addresses are similar; one of the reasons

that we got in trouble with RFC 4282 was perhaps that we didn't wait until
the EAI discussion was further along.  At this point, in 8-bit clean
situations,
my understanding is that EAI utilizes UTF-8 for both the username and realm
portion.  Since both EAP Identity and RADIUS User-Name are 8-bit clean, the
same logic (and probably, much of the ABNF) would seem to apply here. 


Stefan Winter said:

Windows built-in supplicant
---
 * User-Name in GUI: @müller.de
 * encoded on wire: ü ::= 0xFC (ISO-8859-15/Windows-1252 of ü)

 * User-Name in GUI: some cyrillic letters
 * encoded on wire: all transcribed to the same symbol ? in
ISO-8859-15 or similar encoding (which is not very helpful!)

To get to the cyrillic letters, I installed multi-language support and
complex IMEs, i.e. everything I could find in System Settings, thinking
that it may help the system to move to UTF-8 encodings.

[BA] What version of Windows was this?  XP?  Vista? 

Stefan Winter said:

So... if for MS-CHAPv2, the behaviour for non-ASCII is unspecified, then
it's alright for it to transscribe unexpected input to whatever
character it likes. So not the supplicant is to blame, but rather the
fact of life that MS-CHAPv2 lives in an ASCII world.

Hmmm... is an update to 2759 in any way feasible? Considering its
deployed base that appears difficult at best.

[BA] I'm trying to understand why the ASCII limitation exists in the first
place. 
Presumably there are security protocols out there that utilize UTF-8 encoded
usernames 
or  NAIs (perhaps after some normalization procedure), right? 

Potentially anywhere a user identifier is used.  User-Name, CUI, and
other protocols such as Kerberos.

RFC 4372 (CUI) Section 2.2 doesn't say anything at all about
internationalization:

   String:

  The string identifies the CUI of the end-user.  This string value
  is a reference to a particular user.  The format and content of
  the string value are determined by the Home RADIUS server.  The
  binding lifetime of the reference to the user is determined based
  on business agreements.  For example, the lifetime can be set to
  one billing period.  RADIUS entities other than the Home RADIUS
  server MUST treat the CUI content as an opaque token, and SHOULD
  NOT perform operations on its content other than a binary equality
  comparison test, between two instances of CUI.  In cases where the
  attribute is used to indicate the NAS support for the CUI, the
  string value contains a nul character.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

[Bernard Aboba]

I think we’ve got a problem here :( 

 

Stefan Winter said:

 

“I'm currently trying to figure out what would happen if a AAA roaming 
consortium (802.1X based, using EAP and RADIUS) were to use IDNs in its NAIs, 
i.e. a user name like lieschen at müller.de. I was kind of expecting to see 
UTF-8 encoded User-Name attributes showing up at the RADIUS server, since 
RFC2865 defines User-Name to be UTF-8. I got an encoding of ü ::= 0xfc, which 
hinted that the supplicant was not using UTF-8 but some locale (I expect it to 
be either ISO-8859-15 or Windows-1252, not that this matters).” 

[BA] Can you provide more details on the EAP
implementation/operating system on which the test was conducted? 

 

Stefan Winter also said:

 

“It struck me that according to this clause, the supplicant in principle has 
the option of encoding the EAP-Response/Identity to its liking, since this 
clause only defines displayable messages in EAP-*Request*/Identity to be UTF-8 
encoded.” [BA] Yes, I believe that this is an unfortunate oversight; the 
EAP-Response/Identityshould also be UTF-8 encoded. 

 

Glen Zorn said:

 

“I suppose that we could also propose new RFC boilerplate saying something

like
IF YOU ARE A MORON DON'T IMPLEMENT THIS SPECIFICATION. but I don't

think
it would do much good.  RFC 4282 already allows UTF-8 for NAIs that

cannot
be represented in ASCII.  If a supplicant doesn't use it, it's a bug

in
the supplicant implementation, not in the NAI specification, let alone

EAP
or .1X.”

 

[BA] RFC 4282 actually proposes that the realm portion of
the NAI be encoded in punycode, not UTF-8. 

RFC 2865 talks about the User-Name being encoded in UTF-8,
 and RFC 3748 also talks

about UTF-8 (albeit for the EAP-Request/Identity).
 With RFC 3759 requiring the EAP-Response/Identity

to be placed into the RADIUS User-Name attribute, it is hard
for me to see how the NAI in EAP or

RADIUS could be encoded in anything other than UTF-8.  

 

Since the EAP Identity Request  Response are 8-bit
clean, and RADIUS explicitly enables carriage of

UTF-8 in the User-Name Attribute, there is no reason for a
conversion to punycode to occur for the 

realm portion of the NAI.It *is*
reasonable to say that if and when the realm is included in a DNS

query that it should be converted to punycode (e.g. an
A-label) beforehand. 

 

Stefan Winter also said:

 

“I seriously hope that I overlooked something,” [BA] The more I’ve looked into 
this, the more likely it seems that this problemis real and potentially wide in 
scope, affecting not only EAP, RADIUS, Diameter but also EAP methods.  For 
example, RFC 2759 (MS-CHAPv2) Section 4 states: “The Name field is a string of 
0 to (theoretically) 256 case-sensitiveASCII characters which identifies the 
peer's user account name.” Yup.  ASCII, *not* UTF-8!  This actually can cause 
an authentication failurefor a user with an NAI of [EMAIL PROTECTED]  Section 5 
states:The message quantity is human-readable text in the appropriate   
charset and language.  Note: no reference to UTF-8.   It gets better.  RFC 3748 
Section 5 says: “  EAP methods MAY support authentication based on shared 
secrets.  If   the shared secret is a passphrase entered by the user,   
implementations MAY support entering passphrases with non-ASCII   characters.  
In this case, the input should be processed using an   appropriate stringprep 
[RFC3454] profile, and encoded in octets using   UTF-8 encoding [RFC2279].  A 
preliminary version of a possible   stringprep profile is described in 
[SASLPREP].” Not only is support for non-ASCII characters in passwords 
optional,but that stringprep is referred to as a “possible” scheme, without 
normativelanguage.   If we created a username and password combination 
including UTF-8 non-ASCIIcharacters in both, what do you think the odds of 
interoperating are? Not good,I’d wager.   

[BA] So what do we do about this? 

 

Some of the following may be needed to fix the problem:

 

a.  
A document on NAI internationalization, updating
RFC 4282.  This would address the (IMHO incorrect) punycode encoding of
the realm portion. 

b. 
A document on EAP internationalization, updating
RFC 3748.  This would cover the EAP-Response/Identity as well as
potentially giving advice on issues such as password internationalization and
internationalization of the EAP Peer-Id and Server-Ids. 

 

 

 

 

 

 


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Requirements for Channel Binding in the Tunnel Method Requirements document

[Bernard Aboba]

Section 4.1.1 of the Tunnel Method Requirements document includes the following 
statement:

   In addition, the tunnel method MUST support EAP channel bindings to
   enable a system based on EAP to meet the additional requirements in
   Section 3 of RFC 4962.
While I have no problem with including support for channel bindings within the 
EMU tunnel method,
I do not believe that any requirement for EAP Channel Bindings can be inferred 
from Section 3 of RFC 4962. 
Here is what Section 3 says: 
 The context will include the peer and NAS identities in more
 than one form.  One (or more) name form is needed to identify
 these parties in the authentication exchange and the AAA
 protocol.  Another name form may be needed to identify these
 parties within the lower layer that will employ the session
 key.
Notice that neither this paragraph nor the ones surrounding it mention exported 
EAP keying material
specifically.  This omission was intentional -- the intent was to enable the 
requirement to be met by
subsequent cryptographic binding operations operating within lower layers.  As 
an example, 
IEEE 802.11r's PMK-R0 and PMK-R1 cryptographically bind the PMK/MSK to channel 
properties,
satisfying this requirement. 

Part of the reason that EAP channel bindings were not mandatory to implement is 
that they were (and remain)
undeployed, so that their practicality remains unproven.  For this reason, 
despite considerable
IESG pressure, RFC 4017 included EAP channel bindings only as an optional 
feature within 
Section 2.4, rather than promoting it to required or even recommended to 
implement. 

Between the publication of RFC 4017 and 4962, many aspects of EAP, including 
new methods,
RFC 3748 implementations, etc. moved ahead, but progress in the channel binding 
area
remained slow, so that the case for requiring EAP channel binding did not grow 
stronger.

As proof that EAP channel binding is NOT required by RFC 4962 Section 3, RFC 
5247 
which was chartered to demonstrate how RFC 4962 requirements can met by
EAP/Secure Association/AAA systems does not mention EAP channel bindings at all 
in 
Section 5.4, which discussed how the RFC 4962 key binding requirements from 
Section 3 
can be met.  Rather, RFC 5247 Section 2.3 which discussed authenticator 
identification, mentions both
EAP channel binding and lower layer bindings in points (f) through (k), albeit 
without
normative language. 

Given the extensive discussion of RFC 4017 and 4962 on the IETF mailing list 
and various
other mailing lists, including the EAP WG list, it is therefore somewhat 
disappointing to see
something which could only garner IETF consensus as an optional capability 
promoted to 
mandatory, purely due to IESG re-interpretation of a BCP after publication. 

Given that the EMU WG has as a work item for development of an Internet Draft 
on EAP channel
binding, my advice is for the WG, through its analysis of the problem and the 
potential solutions,
to develop its own consensus as to the value and practicality of channel 
bindings, rather than 
allowing an opinion to be imposed upon it from the IESG.  


As a first step toward that, a concise statement of the problem is very 
important. 
Section 4.4 of the Tunnel Method Requirements document includes the following 
statement
of the Channel Binding problem:
   The so-called lying NAS problem is a well-documented problem with
   the current Extensible Authentication Protocol (EAP) architecture
   [RFC3748] when used with pass-through authenticators.  Here, a
   Network Access Server (NAS), or pass-through authenticator, may
   authenticate to the backend AAA infrastructure using one set of
   credentials, while representing contrary information to EAP peers.
The issue is not just whether the information presented to
the peer and server are contradictory, but also whether the information is 
correct. 
To make this clear, RFC 5247 Section 5.3.3 included additional text beyond
what was present in RFC 3748 Section 7.15:

   While the verification [of channel bindings] can be done
   either by the peer or the server, typically only the server has the
   knowledge to determine the correctness of the values, as opposed to
   merely verifying their equality.  


The use of the term credentials in the short problem description is somewhat 
odd, since in 
AAA protocols, the credentials used for mutual authentication between the AAA 
client and server 
do not relate to channel binding parameters such as the NAS-Identifier.  For 
example, a AAA client 
can use a certificate containing a subjectAltName field of 
aaaclient.example.com to authenticate to the AAA server, 
whereas the enclosed NAS-Identifier attribute could contain a the R0KH-ID from 
IEEE 802.11r.
Such an Access-Request would be completely valid, and RFC 5247 Section 2.5 
notes some of
the issues that can arise:

   It is possible for problems to arise in situations where the EAP
   server 

[Emu] Review of draft-clancy-emu-chbind-00

[Bernard Aboba]

Overview I have read this document and have found several major issues with it. 
 As a result,I don't think it is currently suitable for adoption of an EMU WG 
work item.  Issues:  a. Mistatement of the 'Lying NAS' problem.   The 'Lying 
NAS' problem does not just concern the issue of whether the authenticatorgives 
different information to the peer and the server;  it also relates to the 
ability of the server to verify that the information is actually correct.  The 
document does not refer to the necessity of first-hop verification of the 
information provided by the authenticator, such as the mapping between 
theNAS-Identification attributes and the source address.   The need for 
verification impacts the trust model in some major ways, sincenot only does the 
authentication server need to trust that the authenticatorattributes have not 
been modified along the path -- it also needs to trust thatthe first hop was 
configured to check the validity of attributes that only it cancheck.   For 
example, it's not much help for the AAA Server to verify that the RSN 
IEprovided to the STA is the same one it got from the AP if there is no way 
ofverifying whether the AP actually was configured to emit that RSN IE.  b. 
Lack of applicability to the roaming case.  The document states that Channel 
Bindings only apply to the non-roaming case. I'm not sure why this restriction 
is mentioned because the issue of verificationis present even within a single 
domain.   c. Discussion of 'fuzzy' comparisions.  By their nature, Channel 
Bindings may includeinformation that may be opaque to the AAA server, such as 
the RSN IE.  Given thatthe AAA server may not be capable of understanding the 
contents of the attributes,I question whether the concept of 'fuzzy 
comparisons' makes sense.  Rather, I thinkwe need to assume that a AAA server 
will probably only be capable of 'byte by byte'comparisons in most cases.  This 
is an important issue, because it affects the structureof data that needs to be 
provided by the client, and avoid potential 'canonicalization'issues that could 
greatly complicate the successful implementation of channel bindings.  d. 
Discussion of lower layer channel bindings.  The document does not discuss the 
potential use of channel bindings in lower layers suchas IEEE 802.11r.  I think 
that this is important since lower layers such as 11r do bind EAPkeying 
material to lower layer parameters (such as the peer and authenticator MAC 
address). Thus, lower layer channel bindings is an alternative that should be 
discussed.  e. Development of requirements.  If this document is going to 
include an evaluation ofalternative approaches, then it needs to clearly 
articulate the requirements for such anevaluation.  f. Clear distinction 
between RFC 5056 and 3748 channel binding concepts.  The currentdocument is not 
as clear as it could be on this.  The RFC 5056 channel binding conceptis closer 
to that of 'cryptographic binding' than it is to EAP channel bindings.  This 
shouldbe made clear.  g. Exploration of operations implications.  There are a 
number of barriers to successfulimplementation of channel bindings that need to 
be explored, including: 1. Required configuration for first-hop AAA clients. 2. 
Potential changes to drivers and AAA servers. 3. Potential impacts on 
authentication reliability.  h. Motivation.  Why should we care about Channel 
Bindings?  Given the operational costsI'd suggest that the document needs to 
make a case that there is a potentially serioussecurity vulnerability here.  
Such a case probably involves some kind of financial fraudissue which is most 
likely in a roaming situation - which is unfortunately a scenario that 
thedocument rules out of scope.   Some specific comments.  
 Abstract   This document defines how to implement 
channel bindings for   Extensible Authentication Protocol (EAP) methods. [BA] 
I'd add a definition of the problem to the abstract goals.  Section 1   A 
well-documented problem with the current Extensible Authentication   Protocol 
(EAP) architecture [RFC3748] when used in pass-through   authenticator mode is 
the so-called 'lying NAS' problem.  Here, a   Network Access Server (NAS), or 
pass-through authenticator, may   authenticate to the backend AAA 
infrastructure using one set of   credentials, while representing contrary 
information to EAP clients. [BA] The 'lying NAS' problem is not really about 
credentials, since in RADIUS the identity of a RADIUS client is defined by its 
IP address.Rather, the issue is providing different *information* 
(e.g.Called-Station-Id, NAS-Identifier, etc.) to the peer and AAA server. A 
concrete example of this may be an IEEE 802.11 access point with a   security 
association to a particular AAA server.  While there may be   some identity 
tied to that security association, there's no reason   the access point need 
advertise the same identity to clients.   [BA] The identity 

Re: [Emu] EMU charter revision,

[Bernard Aboba]

[Joe] Jari had asked to keep this open to TLS.  I think he was
suggesting it could be done as a TLS extension and would not require
tunneling.  I agree that we do not want to extend EAP-TLS to do
tunneling. 

How about:

- Enable a TLS-based EAP method to support channel bindings. This item
will not generate a new method, rather it will focus on supporting EAP 
channel bindings within the tunnel method.  The possiblity of adding
channel bindings to EAP-TLS through a TLS extension or other standard
TLS mechanism may also be investigated.  

[BA] I think we only want one mechanism for support of channel bindings
in TLS-based methods.  So it's ok to investigate a TLS extension vs.
other mechanisms for supporting channel bindings, but I'd suggest we
only want to choose one path.  So my suggestion would be to modify
the text as follows:

- Enable a TLS-based EAP method to support channel bindings.  This item
will not generate a new method, rather it will focus on adding support for
EAP channel bindings.  Potential mechanisms for addition of support for
channel bindings will be investigated, including tunneling of channel
binding parameters, or a TLS extension or other standard TLS mechanism.   
 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EMU charter revision,

[Bernard Aboba]

In re-reading this charter, I still don't think we're quite there:
 
a.  Why is there still a charter item for EAP-TLS?  This work hasbeen 
completed, no? 
 
b. Attempting to extend EAP-TLS to support tunneling or channel bindings 
is not appropriate. EAP-TLS already widely deployed, with large investments 
in conformance tests.  Given the number of existing TLS-based tunneling 
protocols, such a work item would serve no useful purpose.  Let's focus on 
adding
channel binding support to tunnel methods. 
 
c. To some extent, I agree with Dan and Yoav with respect to the need for 
password-based methods.  Had such methods been availableearlier, it's 
questionable whether TLS tunneling would have takenoff to the extent that it 
has.  Also, I think that such methods, if specified
in the IETF, would be likely to be widely deployed.  However, on the other
hand I think that this is really an issue for the entire security area, not
just for EMU.  So I'd suggest that this issue be brought up in SAAG. 
 
=Below is a 
revision to the EMU charter that is intended to reflect thediscussions in the 
Philadelphia meeting.  Please respond to the list ifyou approve of the charter 
or if you have any comments on the charter.I would like to have responses by 
4/24.
 
Thanks,
Joe
 
 ___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EMU Charter revision

[Bernard Aboba]

I also do NOT approve of the current charter revision, for several reasons:

a.  The Charter text contains statements that are no longer true.  For example:
Most of these methods are proprietary methods and only a few methods 
are documented in RFCs.

The following EAP methods are now documented in RFCs:

EAP-TLS (RFC 2716)
EAP-SIM (RFC 4186)
EAP-AKA (RFC 4187)
EAP-PAX (RFC 4746)
EAP-SAKE (RFC 4763)
EAP-PSK (RFC 4764)
EAP-POTP (RFC 4793)
EAP-FAST (RFC 4851)
EAP-IKEv2 (RFC 5106)

9 methods claiming to satify RFC 4017 critieria is more than a few. 

b. The Charter requires support for Channel Bindings without doing the
preparatory work to define how Channel Bindings works.  Either the
requirement should be removed, or a work item should be added to 
better define the approach to Channel Bindings. 

c. The text on tunnel methods does not provide enough guidance to avoid
potentially fruitless arguments.  So far, the EMU WG has not been able
to come to consensus on selection of one of the existing tunneling
protocols, and efforts to design yet another tunneling protocol 
haven't gotten very far either.  I'd like to see more specific 
language that would make it clear that work on improving existing
tunneling protocols is within scope, and also that the EMU WG,
if it cannot come to consensus on a single protocol, can proceed to 
work on one or more protocols with significant support.  

d. Password-based methods.  While I can understand the desire to limit the
number of charter items, I do agree with Dan that work on weak-password
methods is important.  With some of the IPR obstacles likely to fall by
the wayside in coming years, it is time for the IETF to re-visit its policy
on inclusion of zero knowledge algorithms within standards track documents. 
Dan Harkins said:

 Hi Joe,

  I do NOT approve of the current charter revision, specifically the
change that says the password-based method can only be via the
tunneled method. I do approve of the inclusion of tunneled methods
in the charter though and would be willing to contribute as a
reviewer.

  regards,

  Dan.
On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote:
 The response to the charter revision has been underwhelming.  I am a bit
 concerned that we do not have enough participation to complete the
 tunnel method work (most of the recent discussion has been about other
 methods).

 I would like to get an idea of the number working group members that
 approve of working on the tunnel method items and are able to
 participate in the development of requirements and specifications as
 contributors and/or reviewers.

 Please respond to this message and state whether you approve of the
 current charter revision and what capacity you would be willing to
 contribute towards tunneled method development: contributor, reviewer or
 not able to contribute.

 I have submitted an internet draft attempt at an outline of requirements
 for tunneled methods
 (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
 txt) that I hope can provided a starting point for discussions on the
 list and in the Philadelphia meeting.

 Thanks,

 Joe
___
Emu mailing list
Emu@ietf.org
http://www.ietf.org/mailman/listinfo/emu

[Emu] IETF DISCUSS comment on RFC 2716bis

[Bernard Aboba]

Chris Newman has filed an IETF DISCUSS comment on RFC 2716bis Section 2.4.  
 
The text of this section reads as follows:
 
2.4.  Ciphersuite and Compression Negotiation   EAP-TLS implementations MUST 
support TLS v1.0.   EAP-TLS implementations need not necessarily support all 
TLS   ciphersuites listed in [RFC4346].  Not all TLS ciphersuites are   
supported by available TLS tool kits and licenses may be required in   some 
cases.   To ensure interoperability, EAP-TLS peers and servers MUST support   
the TLS [RFC4346] mandatory-to-implement ciphersuite:   
TLS_RSA_WITH_3DES_EDE_CBC_SHA.   In addition, EAP-TLS servers SHOULD support 
and be able to negotiate   all of the following TLS ciphersuites:   
TLS_RSA_WITH_RC4_128_MD5   TLS_RSA_WITH_RC4_128_SHA   
TLS_RSA_WITH_AES_128_CBC_SHA   In addition, EAP-TLS peers SHOULD support the 
following TLS   ciphersuites defined in [RFC3268]:   
TLS_RSA_WITH_AES_128_CBC_SHA   TLS_RSA_WITH_RC4_128_SHA   Since TLS 
supports ciphersuite negotiation, peers completing the TLS   negotiation will 
also have selected a ciphersuite, which includes   encryption and hashing 
methods.  Since the ciphersuite negotiated   within EAP-TLS applies only to the 
EAP conversation, TLS ciphersuite   negotiation MUST NOT be used to negotiate 
the ciphersuites used to   secure data.   TLS also supports compression as well 
as ciphersuite negotiation.   However, during the EAP-TLS conversation the EAP 
peer and server MUST   NOT request or negotiate compression.
 
Here is the comment:
 
Chris Newman:Discuss [2008-01-24]:I'd like to discuss the cipher suite issue 
raised in my comment on theIESG call.  An RFC editor note or even an assurance 
the typos will befixed before publication would suffice to clear my discuss 
position.Comment [2008-01-10]:In this excerpt:   all of the following TLS 
ciphersuites:   TLS_RSA_WITH_RC4_128_MD5   TLS_RSA_WITH_RC4_128_SHA 
  TLS_RSA_WITH_AES_128_CBC_SHA   In addition, EAP-TLS peers SHOULD support the 
following TLS   ciphersuites defined in [RFC3268]:   
TLS_RSA_WITH_AES_128_CBC_SHA   TLS_RSA_WITH_RC4_128_SHAThere are two 
errors: 1. two of the cipher suites are listed twice.2. the RC4_128 cipher 
suite is not defined in RFC 3268.Q: Would it be useful for this protocol to 
recommend support for theserver name indication extension in RFC 4366?  
Otherwise the serverrequires an IP address for each name it supports.
 
The proposed resolution to this comment is as follows:
 
With respect to the server name indication extension, I am not sure
that the IP address issue applies to EAP-TLS, which typically runs
over the link layer without IP.  Or is there something I'm missing?
 
With respect to the ciphersuite comments, I suggest that the 
text of Section 2.4 be changed to the following:
 
2.4.  Ciphersuite and Compression Negotiation   EAP-TLS implementations MUST 
support TLS v1.0.   EAP-TLS implementations need not necessarily support all 
TLS   ciphersuites listed in [RFC4346].  Not all TLS ciphersuites are   
supported by available TLS tool kits and licenses may be required in   some 
cases.   To ensure interoperability, EAP-TLS peers and servers MUST support   
the TLS [RFC4346] mandatory-to-implement ciphersuite:   
TLS_RSA_WITH_3DES_EDE_CBC_SHA
 
   EAP-TLS peers and servers SHOULD also support and be able
   to negotiate the following TLS ciphersuites:
 
TLS_RSA_WITH_RC4_128_SHA [RFC4346]
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]   In addition, EAP-TLS servers 
SHOULD support and be able to negotiate   the following TLS ciphersuite:   
TLS_RSA_WITH_RC4_128_MD5 [RFC4346]   Since TLS supports ciphersuite 
negotiation, peers completing the TLS   negotiation will also have selected a 
ciphersuite, which includes   encryption and hashing methods.  Since the 
ciphersuite negotiated   within EAP-TLS applies only to the EAP conversation, 
TLS ciphersuite   negotiation MUST NOT be used to negotiate the ciphersuites 
used to   secure data.   TLS also supports compression as well as ciphersuite 
negotiation.   However, during the EAP-TLS conversation the EAP peer and server 
MUST   NOT request or negotiate compression.
 ___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

[Bernard Aboba]

[Joe] It seems there is a lot of complexity here.  It seems that being
able to validate the server's root would be sufficient in most cases.
At least there is some trust chain back a server, validating the SSID at
this point does not seem to add too much.


Assuming that the selected SSID advertising Emergency Sevices has no 
pre-existing profile, I would agree that validating the server certificate 
to some set of trust anchors (that may be specific to emergency services) is 
sufficient.


If we are talking about a pre-existing profile, then the authentication 
policy for that profile should still be enforced.   For example, an attacker 
shouldn't be able to trick a victim into abandoning an existing profile just 
by advertising Emergency Services capability along with the SSID.  After 
all, the existing profile may require use of a different EAP method, set of 
trust anchors, etc.





___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

[Bernard Aboba]

[Joe] I agree, that if No pre-configured trust relationship refers to
configuration of client on the server then we are in a better position.
However it seems that in you discussion below that the peer does not
typically have enough information to validate the server.


I think we need to distinguish between validating the server and 
validating the authenticator.  If the EAP peer has trust anchors, it can 
validate the server.  The question is whether that should be sufficient to 
allow the peer to connect to the authenticator or not.


It may matter whether the peer has a pre-existing profile.   For example, if 
there is a profile corresponding to the EXAMPLE network, and the peer 
successfully validates the example.com server, then the question is 
whether the peer should apply the EXAMPLE profile based on validation of 
the example.com server certificate.  If the EXAMPLE profile includes a 
requirement for validation of a certificate from example.com, then that 
should be sufficient.


However, if there is no pre-existing profile then it is not clear to me what 
security services can be required.  Should the peer be satisfied if the 
server certificate chains to any trust anchor, regardless of the SSID?  If 
the SSID in question represents a pre-existing profile requiring chaining to 
a particular trust anchor, I'd say no.  However, if the SSID is unknown 
and there is an unknown SSID that advertises emergency services, then it is 
probably better to try that (and maybe even go ahead if the server cert 
fails validation) than to fail -- leaving the user without the ability to 
make an emergency call in a life and death situation.





 Requirement #2 is Small number of messages.  While this
 requirement clearly excludes long exchanges, it is not clear
 to me that TLS-based methods are excluded, particularly if
 the method is to be implemented on the AP itself, which
 potentially would result in lower round-trip times and
 eliminate the possibility of AAA-based frame loss.

[Joe] the requirement is a bit unclear, however I agree that it is worth
including text about this.

 It may be possible that requirements #1 and #2 are compatible
 with proposals involving unauthenticated client access
 combined with server authentication.
However, due to lack of a pre-configured network access
 profile, this scenario presents additional threats that are
 worthy of further discussion.

 The presentation refers to the desire to for confidentiality
 (presumably at L2, rather than using SRTP).  Where
 confidentiality is desirable, it will also presumably be
 important for the client to determine that it has connected
 to a legitimate network.

 Where a pre-configured network access profile exists, the
 binding between a validated server certificate and an
 advertised SSID is pre-configured.
 However, where there is no pre-configured network access
 profile, the binding may be difficult to establish without
 imposition of additional requirements.

 For example, the server certificate/SSID binding cannot be
 determined solely via verification of the server certificate.
  An attacker could obtain a valid server certificate for
 example.com; does this entitle them to advertise an SSID of
 Emergency Network or even Example?  Since SSIDs are not
 globally unique, there is no verifiable mapping between a
 Server-Id and an allowed set of SSIDs. In general, a CA has
 no way of determining whether a server has the rights to a
 particular SSID or not, so that a CA cannot in practice vouch
 for an RFC 4334 SSID extension within a server certificate.

[Joe] If this is the case then I don't think there is a valid trust
relationship for the peer to validate the server.


 Therefore verification of a binding between the server
 identity and the advertised network would only seem to be
 possible by requiring the advertised network name to match
 the Server-Id advertised in the server certificate.  This in
 turn would require restricting the allowable SSIDs, or adding
 another field to the IEEE 802.11 Beacon/Probe Response.

[Joe] It seems like there are at least two possibilities here:

1. Have a CA that only issues emergency services certificates and an
indication in the beacon/probe of which SSIDs are emergency services.

2. Have a CA that issues different types of certificates and have
specific SSIDs and names in the certificates to create the authorization
linkage.







 From: Joseph Salowey (jsalowey) [EMAIL PROTECTED]
 To: emu@ietf.org
 CC: [EMAIL PROTECTED], Bernard Aboba
 [EMAIL PROTECTED]
 Subject: Draft liaison response for IEEE 802.11u EAP method for
 emergency calls
 Date: Sun, 16 Sep 2007 22:26:36 -0700
 
 The EMU working group has a liaison request from IEEE 802.11u on EAP
 methods for emergency calls.  The liaison request can be
 found on the
 liaison statement page, https://datatracker.ietf.org/liaison/ (May
 2007).  We had a presentations and discussion of this topic at the
 Chicago EMU meeting.  Below

RE: [Emu] Issue with RFC 2716bis key generation

[Bernard Aboba]

Hao said:



Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716? 
What's the reason for the change in 2716Bis?
 
[BA]  I would agree that the approach used in RFC 2716 is preferrable.  As to 
how the change got into RFC 2716bis, it appears to have been introduced in -01; 
-00 Section 2.5 contained the original text from RFC 2716. 
 
The text inserted into -01 appears to have been taken from the EAP Key 
Management Framework document, which included similar text in Appendix C in 
-00, and included an Appendix A on EAP-TLS key management up to version -09 
(e.g. see http://www.watersprings.org/pub/id/draft-ietf-eap-keying-09.txt). 
 
As you noted, the formula in RFC 2716bis appears to imply that two PRFs need to 
be computed (TLS-PRF-64 and TLS-PRF-128) when in fact only one is needed (a 
single TLS-PRF-128).  ___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Issue: Encoding of NAIs within EAP-TLS certificates

[Bernard Aboba]

RFC 3280 Section 4.1.2.6 says:

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (section 4.2.1.7) to describe such identities.
   Simultaneous inclusion of the EmailAddress attribute in the subject
   distinguished name to support legacy implementations is deprecated
   but permitted.

This leads me to believe that the statement below from Section 5.2 isn't quite 
right: 

Although the use of the subject name field is existing practice, its use
in EAP-TLS is deprecated and Certification Authorities are encouraged
to use the subjectAltName field instead. 

An RFC 3280-equivalent statement would be:

Conforming implementations generating new certificates with
network access identifiers MUST use the rfc822Name in the
subject alternative name field to describe such identities.
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Encoding of NAIs within EAP-TLS certificates

[Bernard Aboba]

Right.  The RFC 3280 statement only applies to RFC 822 names.  That's why I 
think that the text should focus on those names.  Subject: RE: [Emu] Issue: 
Encoding of NAIs within EAP-TLS certificates Date: Thu, 7 Jun 2007 08:57:49 
-0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; emu@ietf.org  Not all 
identities are an RFC822 Name so using an RFC822 name is not always 
appropriate. If you are going to include an RFC822 name in the certificate 
then it should be in the RFC822 SubjecAltName. The Subject distinguished name 
may include other name elements.   -Original Message-  From: 
Bernard Aboba [mailto:[EMAIL PROTECTED]   Sent: Thursday, June 07, 2007 7:54 
AM  To: emu@ietf.org  Subject: [Emu] Issue: Encoding of NAIs within EAP-TLS 
certificates  RFC 3280 Section 4.1.2.6 says:Conforming 
implementations generating new certificates with  electronic mail addresses 
MUST use the rfc822Name in the subject  alternative name field (section 
4.2.1.7) to describe such   identities.  Simultaneous inclusion of the 
EmailAddress attribute in the subject  distinguished name to support legacy 
implementations is deprecated  but permitted.This leads me to believe 
that the statement below from   Section 5.2 isn't quite right: 
Although the use of the subject name field is existing   practice, its use 
in EAP-TLS is deprecated and Certification   Authorities are encouraged to 
use the subjectAltName field instead. An RFC 3280-equivalent statement 
would be:Conforming implementations generating new certificates with  
 network access identifiers MUST use the rfc822Name in the   subject 
alternative name field to describe such identities.  
___  Emu mailing list  
Emu@ietf.org  https://www1.ietf.org/mailman/listinfo/emu  ___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Issue with RFC 2716bis key generation

[Bernard Aboba]

It has been pointed out by Paul Funk that the key generation formula specified 
in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is 
introduced. 
 
The formula in -09 is as follows:
 
MSK(0,63)= TLS-PRF-64(TMS, client EAP encryption,
client.random || server.random)   EMSK(0,63)   = second 64 octets of:   
   TLS-PRF-128(TMS, client EAP encryption,
client.random || server.random)   IV(0,63) = TLS-PRF-64(, client EAP 
encryption,client.random || server.random)
The issue here is that RFC 2716 Section 3.5 specifies a different approach:
 
   MSK(0,63)   = first 64 octets of:  TLS-PRF-128(TMS, client 
EAP encryption,client.random || server.random)   
EMSK(0,63)   = second 64 octets of:  TLS-PRF-128(TMS, client 
EAP encryption,client.random || server.random)   IV(0,63)  
   = TLS-PRF-64(, client EAP encryption,client.random 
|| server.random)
 
With the current TLS PRF, these two approaches are identical.  However, this is 
not necessarily true for all PRFs that could conceivably be negotiated within 
TLS v1.2.  
 
The text from RFC 2716 Section 3.5 reads as follows:
 
   Since the normal TLS keys are used in the handshake, and therefore   should 
not be used in a different context, new encryption keys must   be derived from 
the TLS master secret for use with PPP encryption.   For both peer and EAP 
server, the derivation proceeds as follows:   given the master secret 
negotiated by the TLS handshake, the   pseudorandom function (PRF) defined in 
the specification for the   version of TLS in use, and the value random defined 
as the   concatenation of the handshake message fields client_hello.random and  
 server_hello.random (in that order), the value PRF(master secret,   client 
EAP encryption, random) is computed up to 128 bytes, and the   value PRF(, 
client EAP encryption, random) is computed up to 64   bytes (where  is an 
empty string).  The peer encryption key (the   one used for encrypting data 
from peer to EAP server) is obtained by   truncating to the correct length the 
first 32 bytes of the first PRF   of these two output strings.  The EAP server 
encryption key (the one   used for encrypting data from EAP server to peer), if 
different from   the client encryption key, is obtained by truncating to the 
correct   length the second 32 bytes of this same PRF output string.  The   
client authentication key (the one used for computing MACs for   messages from 
peer to EAP server), if used, is obtained by truncating   to the correct length 
the third 32 bytes of this same PRF output   string.  The EAP server 
authentication key (the one used for   computing MACs for messages from EAP 
server to peer), if used, and if   different from the peer authentication key, 
is obtained by truncating   to the correct length the fourth 32 bytes of this 
same PRF output   string.  The peer initialization vector (IV), used for 
messages from   peer to EAP server if a block cipher has been specified, is 
obtained   by truncating to the cipher's block size the first 32 bytes of the   
second PRF output string mentioned above.  Finally, the server   initialization 
vector (IV), used for messages from peer to EAP server   if a block cipher has 
been specified, is obtained by truncating to   the cipher's block size the 
second 32 bytes of this second PRF   output.___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue with RFC 2716bis key generation

[Bernard Aboba]

The problem is that RFC 2716 specifies the use of TLS-PRF-128.  If TLS v1.2 
negotiates a PRF where PRF-64 is not the same as the first 64 octets of PRF-128 
(the IKEv2 PRF is an example of such a PRF), then RFC 2716bis implementations 
will not interoperate with RFC 2716 implementations.   


Subject: RE: [Emu] Issue with RFC 2716bis key generationDate: Thu, 7 Jun 2007 
17:02:40 -0400From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: 



Is there any reason not to use the approach in RFC2716Bis? This guarantees 
backward compatibility and require less computation.



From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 
3:05 PMTo: [EMAIL PROTECTED]: [Emu] Issue with RFC 2716bis key generation
It has been pointed out by Paul Funk that the key generation formula specified 
in RFC 2716bis could cause backward compatibility problems once TLS v1.2 is 
introduced.  The formula in -09 is as follows: MSK(0,63)= TLS-PRF-64(TMS, 
client EAP encryption,client.random || server.random)   
EMSK(0,63)   = second 64 octets of:  TLS-PRF-128(TMS, client 
EAP encryption,client.random || server.random)   IV(0,63)  
   = TLS-PRF-64(, client EAP encryption,client.random 
|| server.random)The issue here is that RFC 2716 Section 3.5 specifies a 
different approach:MSK(0,63)   = first 64 octets of:  
TLS-PRF-128(TMS, client EAP encryption,client.random || 
server.random)   EMSK(0,63)   = second 64 octets of:  
TLS-PRF-128(TMS, client EAP encryption,client.random || 
server.random)   IV(0,63) = TLS-PRF-64(, client EAP encryption, 
   client.random || server.random) With the current TLS PRF, these two 
approaches are identical.  However, this is not necessarily true for all PRFs 
that could conceivably be negotiated within TLS v1.2.   The text from RFC 2716 
Section 3.5 reads as follows:Since the normal TLS keys are used in the 
handshake, and therefore   should not be used in a different context, new 
encryption keys must   be derived from the TLS master secret for use with PPP 
encryption.   For both peer and EAP server, the derivation proceeds as follows: 
  given the master secret negotiated by the TLS handshake, the   pseudorandom 
function (PRF) defined in the specification for the   version of TLS in use, 
and the value random defined as the   concatenation of the handshake message 
fields client_hello.random and   server_hello.random (in that order), the value 
PRF(master secret,   client EAP encryption, random) is computed up to 128 
bytes, and the   value PRF(, client EAP encryption, random) is computed up 
to 64   bytes (where  is an empty string).  The peer encryption key (the   
one used for encrypting data from peer to EAP server) is obtained by   
truncating to the correct length the first 32 bytes of the first PRF   of these 
two output strings.  The EAP server encryption key (the one   used for 
encrypting data from EAP server to peer), if different from   the client 
encryption key, is obtained by truncating to the correct   length the second 32 
bytes of this same PRF output string.  The   client authentication key (the one 
used for computing MACs for   messages from peer to EAP server), if used, is 
obtained by truncating   to the correct length the third 32 bytes of this same 
PRF output   string.  The EAP server authentication key (the one used for   
computing MACs for messages from EAP server to peer), if used, and if   
different from the peer authentication key, is obtained by truncating   to the 
correct length the fourth 32 bytes of this same PRF output   string.  The peer 
initialization vector (IV), used for messages from   peer to EAP server if a 
block cipher has been specified, is obtained   by truncating to the cipher's 
block size the first 32 bytes of the   second PRF output string mentioned 
above.  Finally, the server   initialization vector (IV), used for messages 
from peer to EAP server   if a block cipher has been specified, is obtained by 
truncating to   the cipher's block size the second 32 bytes of this second PRF  
 output.___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Multiple identity issue

[Bernard Aboba]

At  the EMU WG meeting, we discussed the situation where more than one 
altsubjectName or subject field are present in a certificate.  Here is some 
text which can be added to the end of Section 5.2 to address this issue:
 
It is possible for more than one subjectAltName field to be presentin a peer 
or server certificate;  similarly, it is possible for morethan one subject name 
field to be present in a peer or servercertificate.  In this case, EAP-TLS may 
export more than one Peer-Idor more than one Server-Id; all of the exported 
Peer-Id(s) and Server-Id(s) are considered valid. ___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] RFC 2716bis Issue: Use of rfc822Name

[Bernard Aboba]

The following question has come up in the WiMAX Forum with respect to 
EAP-TLS peer certificate usage:



From RFC 3280:

  When the subjectAltName extension contains an Internet mail address,
  the address MUST be included as an rfc822Name.  The format of an
  rfc822Name is an addr-spec as defined in RFC 822 [RFC 822].  An
  addr-spec has the form [EMAIL PROTECTED].  Note that an addr-spec
  has no phrase (such as a common name) before it, has no comment (text
  surrounded in parentheses) after it, and is not surrounded by  and
  .  Note that while upper and lower case letters are allowed in an
  RFC 822 addr-spec, no significance is attached to the case.

The question is whether any NAI as defined in RFC 4282 meets these 
requirements for inclusion in subjectAltName using the rfc822Name format.


For example, what if an NAI does not contain a realm portion?

My personal take is that as long as the NAI is legal within RFC 4282, it 
should be legal for inclusion in the subjectAltName field using the 
rfc822Name format.  This seems preferrable to registering a new type-id.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings

[Bernard Aboba]

I agree with Lakshminath on this.  



From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
Sent: Wed 4/11/2007 11:03 PM
To: Sam Hartman
Cc: [EMAIL PROTECTED]; Bernard Aboba; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Emu] Last call comments: 
draft-williams-on-channel-binding-01.txt: EAP channel bindings



Hi Sam,

Here is my take on this topic:

After having reviewed draft-williams-on-channel-binding-01, I feel
that putting EAP in scope of that document would require a rather
involved revision of the document.  As Charles noted it might require
further abstraction of the concept of channel binding as defined in
draft-williams.

Now, I must say, I do see the similarities between the two notions of
channel binding.  But the EAP/AAA model is unique and it is not easy to
map it to the other, let's say simpler, security models.  The notion of
compound binding or crypto binding also has some similarities to the
notion of channel binding in draft-williams-on-channel-binding-01, but
there are also some differences.

Overall though, since expanding draft-williams-on-channel-binding-01's
scope to EAP means that the requirements, recommendations and
suggestions of Section 2.1 may be applied to EAP channel binding, it
would be a rather painful exercise to sort it all out.  For now, I am
comfortable with the guidance in Section 7.15 of 3748.

thanks,
Lakshminath

Sam Hartman wrote:


 Hi.

 For the last couple of years, we've been believing that EAP and GSS
 used the term channel bindings inconsistently.  For those of us
 dealing with both, it's been a bit annoying.

 I've been thinking about EAP a lot lately. and have come to the
 conclusion that actually the terms are used consistently.

 I'd like to see if people agree with the following change to Nico's channel 
 binding draft:

 old:

Also unfortunately there is a conflict with the Extensible
Authentication Protocol (EAP) [RFC3748] which uses channel binding
to refer to a facility that is subtly different from the one
described here.  (It does not seem feasible to adopt new terminology
to avoid these problems now.  The GSS-API, NFSv4 and other
communities have been using the terms channel binding and channel
bindings in these ways for a long time, sometimes with variations
such as channel binding facility and so on.)

 new:

 The Extensible Authentication Protocol (EAP) [RFC3748] includes two
 facilities related to channel binding.  The first, called channel
 binding, is used to bind the lower-layer channel created between the
 peer and the authenticator to the authentication performed using EAP.
 Specific detials of this facility have not been specified, but it is
 likely that this channel would use endpoint channel bindings carried
 in the EAP method exchange.  The endpoint channel bindings would be
 defined for the specific lower layer.  EAP also has a facility called
 cryptographic binding, which is another instance of channel binding.
 Cryptographic binding refers to binding the channel created by a
 tunneling EAP method to an inner authentication performed within that
 method.  Cryptographic binding will likely use unique channel
 bindings.

 Do these changes make sense to people?  Am I telling any lies or
 conflating two architectures in a bad way?


 ___
 Emu mailing list
 [EMAIL PROTECTED]
 https://www1.ietf.org/mailman/listinfo/emu



___
Emu mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Re: Thoughts on Password-based EAP Methods

[Bernard Aboba]

I'm glad to hear from Steve here that there is support for publishing
TTLSv0. I would like to see that happen regardless of whether it is done
as an EMU work item or not.


My understanding is that a new version of the TTLSv0 document will be 
forthcoming which will fill in some of the details that were previously 
missing, such as the EMSK generation formula, and the definitions of the 
Session-Id, Peer-Id and Server-Id.


A new version of the PEAPv0 specification will also be forthcoming.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP chann

[Bernard Aboba]

This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the
identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as
the backend protocol) and this identifier is sent to the peer during
association (before EAP authentication). In addition, both the R0KH-ID
(NAS-Identifier) and R1KH-ID (authenticator MAC address) are mixed in
into the key derivation after the EAP authentication.


I would also add that IEEE 802.11r binds the R1KH-ID and the AP BSSID/MAC 
address during the post-EAP handshake.  IEEE 802.11r also advertises the set 
of authenticators within which fast handoff is possible via the Mobility 
Domain IE.  Currently there is no equivalent AAA attribute to carry that, 
but once there is (it has been discussed in RADEXT WG), it will also be 
possible to verify this parameter within EAP Channel Bindings.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Re: Next Steps on Passwd-based EAP Methods

[Bernard Aboba]

During the meeting the group said that they want to have a password-based 
only approach (no tunneled EAP support). Even CHAP etc. was left for 
future work, if ever done. For this purpose PAP over TLS + room for 
extensibility is just good enough.


FWIW, EAP-TTLSv0 does support non-EAP authentication as well as tunneling.  
This includes support for PAP, CHAP, MS-CHAP and MS-CHAPv2.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Thoughts on Password-based EAP Methods

[Bernard Aboba]

Also, Pascal asked about a patent application. I asked Paul about
that and he said it isn't about EAP-TTLS.


Searching the IETF IPR page, I found the following disclosure, which relates 
to TLS-IA, and therefore is only relevant to EAP-TTLSv1:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=594



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Re: Thoughts on Password-based EAP Methods

[Bernard Aboba]

The latest EAP-TTLSv0 draft is available here:
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt

In terms of publication interest, back in the fall Jari Arkko had announced 
a program to encourage widely implemented EAP methods to publish their 
specifications  as RFCs.  As I recall, there was interest to publish 
EAP-FAST (in the RFC Editor queue), PEAPv0 (documentation currently being 
revised for submission as an Internet Draft).   I don't know the current 
status of the EAP-TTLSv0 publication effort (e.g. whether publication has 
been requested or not).   Steve Hanna might know.


In terms of history, EAP-TTLSv0 was accepted as a Standards Track work item 
of the PPPEXT WG prior to the formation of the EAP WG.  It has been 
implemented on a wide variety of platforms including open source versions 
for Windows (http://www.securew2.com/) and Linux 
(http://open1x.sourceforge.net/).  Interoperability of EAP-TTLSv0 
implementations is currently certified by the WFA.


In terms of features that would be needed to meet EMU WG requirements, I 
think we are probably talking about crypto-binding and channel binding.  It 
is possible that there may be other features needed for some scenarios (e.g. 
mutual certificate authentication for a device/machine plus user auth for 
scenarios currently discussed within WiMAX Forum and 3GPP2).




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Thoughts on Password-based EAP Methods

[Bernard Aboba]

After listening to the IETF 68 presentation on a password-based EAP method, 
I would like to voice some concerns.


Today we already have an over abundance of such methods.  These include 
PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST.   In my discussions 
with customers, I invariably hear complaints about this explosion, and about 
various interoperability and compatibility problems that it causes.  Simply 
put, customers do not want yet another password-based EAP method;  they 
want a single method that is widely implemented and interoperable.


I am concerned that by defining yet another password-based authentication 
mechanism, EMU WG will be making this problem worse, not better.   Creating 
yet another mechanism which differs little from the existing ones also seems 
to have very little chance of being implemented.


There is a better alternative that EMU WG should consider. This is to  
choose an existing method for inclusion on the IETF Standards Track, rather 
than creating a new one.  In order to maintain backward compatibility, this 
would require that the owners give up change control to the IETF.


I would suggest that the best candidate for this would be EAP-TTLSv0, since 
it is very widely implemented, and has an existing certification program in 
WFA.   Also, EAP-TTLSv0 had previously been on the Standards Track in the 
PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter 
and the EAP WG was formed.


In terms of steps to be taken, this would require the following actions:

a. Review and publication of the existing EAP-TTLSv0 specification as an 
RFC.  The goal here would be to document EAP-TTLSv0 as it exists today.


b. Agreement by the authors to give up change control to the IETF.

c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying 
additional capabilities (such as Channel Bindings).




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Q C on 2716bis-08

[Bernard Aboba]

What sort of benefit does this provide. If a server fails to authenticate
due to a security reason, then its EAP failure would not matter, since it
cannot be trusted anyway.


This is an optional mechanism for enabling the server to log the reason for 
the error.  This might allow an administrator to diagnose and correct the 
problem.



How would the peer and the server know this is a subsequent certificate
request and not the initial certificate request?


Because the peer did not provide a certificate in response to the first 
request -- that is how privacy is provided.



Is possession of anything (except of sessionID) being proven? Anything is
signed?


Authentication is provided in the Finished message.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Bernard Aboba]

Hannes Tschofenig said:

We discussed this already several times and this lead me to work on a draft 
together with Thomas Otto:


http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt


Which begs the question:  what is the WG doing with this draft?

From where I sit, it seems quite likely that EAP-TLS-PSK, if completed, will 
be deployed.  When TLS 1.2 is done, this method could eventually benefit 
from KDF negotiation, and should meet the criteria for FIPS 140-2 
certification.  Given the TLS code base in embedded systems, it should not 
be hard to add support for EAP-TLS-PSK within embedded devices.


I my doubts about EAP-GPSK on several of these dimensions.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Bernard Aboba]

[Joe] The KDF needs to be looked at, but I do not think it is
necessarily a show stopper, it does provide KDF agility.  Reports from
people who implemented EAP-GPSK indicate that it was simple to
implement. I have heard push back from embedded system implementers on
EAP-TLS stating that it is too complex, this may be a result of
certificate support I am not sure.


In my experience, adding certificate support dramatically increases 
footprint.  For example, as I recall IKEv1/IPsec with AES CBC/HMAC-SHA1 is 
around 250 KB or so if we're just talking about pre-shared key 
authentication but if you add certificate support that is another 750 KB, 
which will be too big for some applications.


I would think that the same logic applies to EAP-TLS-PSK.  Of course that 
would require a stripped down implemenation of TLS that only supported 
TLS-PSK, no certificates.  I guess that doesn't exist yet?  If you had to 
pull in all of say, Open SSL plus add TLS-PSK support, that would almost 
certainly make it too large for many embedded applications.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Bernard Aboba]

According to RFC 2716, a compliant EAP-TLS implementation must support 
certificates.  Since the resources required to support certificates is much 
larger than the resources required for TLS-PSK, a combined method would not 
be optimal for use within an embedded environment.  There would also be 
substantial costs to adding support for additional authentication methods to 
EAP-TLS.  For example, EAP-TLS certification and testing programs have been 
developed which focus solely on certificate ciphersuites; rewriting those 
test suites would be costly.


By developing EAP-TLS-PSK as a separate EAP method an implementation can 
solely implement TLS-PSK while remaining compliant.  This permits EAP 
TLS-PSK implementations to be optimized for embedded environments.  As a 
side benefit, this approach also eliminates multiple levels of negotiation, 
which had been raised as a potential problem.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Bernard Aboba]

[rmh] As for the value, EAP is not 802.11 only therefore a
device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used as a source address a attacker can presume if a EAP
authentication is successful the MAC used in the source address was
authenticated. I think there are other issues related to it being a MAC
address that should be thought through before it is added; especially if
its not even common practice today which it doesnt apear to be.

[Joe]  I think we are in agreement here.


Use of the MAC address as an EAP-TLS identity is not yet common practice.   
Yet both IEEE 802.1AR and WiMAX documents talk about use of MAC addresses in 
certificates (using different formats), so it could be used more widely in 
the future.


I agree that using a locally administered MAC address as an identity in 
EAP-TLS does not make sense.


Do we have proposed text to deal with this issue?



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Bernard Aboba]

  The subject field identifies the entity associated with the public
  key stored in the subject public key field.  The subject name MAY
  be carried in the subject field and/or the subjectAltName
  extension...  If subject naming information is present only in the
  subjectAltName extension (e.g., a key bound only to an email
  address or URI), then the subject name MUST be an empty sequence
  and the subjectAltName extension MUST be critical.

  Where it is non-empty, the subject field MUST contain an X.500
  distinguished name (DN).

[rmh] We do not universally quote deep references in this document, what
criteria are being applied to determine which references will warrant a
reference + quote vs. just a reference?


[BA] I just realized that the last sentence of the first paragraph is 
already in the document.  I think the quote can be eliminated if we add the 
sentence where it is non-empty... into the text as well.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Bernard Aboba]

If possible, I'd like to include text arising from this thread in the -08 
version of the document, submitted by the IETF 68 deadline.


To make it easier for me to figure out what that text is, it would be 
helpful for someone to post the suggested changes in their entirety, with 
modifications agreed to during the discussion.  Further comments can then 
refer to that text, suggesting specific changes.


Having that record on the mailing list will make it a lot easier for me to 
figure out what changes to make to the document.


Thanks in advance,

Bernard



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Review of draft-ietf-emu-eap-gpsk-03.txt

[Bernard Aboba]

Review of draft-ietf-emu-eap-gpsk-03.txt

Section 1

   At present, several pre-shared key EAP methods are specified, most
  notably

  o  EAP-PAX [RFC4746]
  o  EAP-PSK [I-D.bersani-eap-psk]
  o  EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
  o  EAP-SAKE [I-D.vanderveen-eap-sake].

  Each method has its particular benefits but also its particular
  deficiencies.  EAP-GPSK is a new EAP method that tries to combine the
  most valuable characteristics of each of these methods and therefore
  attempts to address a broad range of usage scenarios.

I would delete this discussion since it doesn't really relate to the
design goals of EAP-GPSK.  As it stands, this statement is too vague
to motivate the design, and discussion of deficiencies without
providing justification is problematic.

  EAP-GPSK should be easy to implement and therefore quickly
 available.

I would leave out and therefore quickly available.  You might also
provide some more info on what makes a method easy to implement,
such as single purpose (PSK), use of commonly available algorithms,
etc.

   Wide applicability:

 EAP-GPSK has been designed in a threat model where the attacker
 has full control over the communication channel.  This is the EAP
 threat model that is presented in Section 7.1 of [RFC3748].

I think a more appropriate title would be Security model.

Efficiency

You might mention round-trips here.

This section should also mention that Privacy is not supported.

Section 4

In addition to the Method-Id, this section should define the Peer-Id
(ID_Client), Server-Id (ID-Server) and Session-Id
(Type-Code || MID).

Section 5

SHA-1 is on a path to deprecation by NIST, so I am concerned about
including this algorithm.

The KDFs do not appear to comply with the NIST KDF recommendation included 
in this draft:

http://www.watersprings.org/pub/id/draft-dang-nistkdf-01.txt

Or am I not reading it correctly?



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

[Bernard Aboba]

I don't care about client authorization -- there should be server-side ACLs 
for this.


Right.


I guess for EAP-TLS, server authorization isn't a huge deal.  If an
unauthorized server is giving you access to the network, what difference
does it make to a client?  The only compromise is maybe that of user
confidentiality.  What worries me are improperly authorized servers for
something like PEAP+MSCHAPv2, where a dictionary attack against a client's
password might be possible.

My biggest worry is that someone, for example, hacks a web server, steals
the key pair, fires up a rogue AP+AAA, and starts stealing client 
passwords.


They wouldn't even have to steal the key pair.  All they'd have to do is 
start a modified RADIUS service and get a rogue AP to point to it.



The user is never presented with a dialog box saying by the
way, you're talking to CN=www.domain.net, not CN=aaa.domain.net.  Oh, and
be sure to check the CRL to see if it's been revoked or not.


Typically the client will not check for a particular FQDN in the 
subjectAltName field in the server cert, only a pattern (e.g. *.domain.net). 
 CRL checking has to occur after the fact, unless the client already has 
connectivity; most implementations don't seem to do the checks at all.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Open issues with draft-simon-emu-rfc2716bis-06.txt

[Bernard Aboba]

1. Use of TLS-WWW EKU

The question was raised that the TLS WWW EKU may not be appropriate for
EAP-TLS.  The suggestion was made to remove the text on EKU.  Are
members of the working group in favor of removing this text?


There are a number of EAP-TLS implementations that require TLS WWW EKUs (or 
any).  So in practice an implementation needs to understand that or it may 
not interoperate.  It also occurs to me that there could be some security 
issues that would surface.  For example, if there is no indication that an 
EAP-TLS server is authorized for that function (e.g. if it doesn't contain a 
TLS WWW server EKU or any), then any machine possessing an EAP-TLS client 
certificate chaining to a trust anchor could use that certiciate to act as 
an EAP-TLS server (assuming that the NASes were configured to trust it).  It 
seems like this could make it easier to put up a rogue NAS.


With respect to the RFC 4334 OIDs, I'm ok with removing mention of them.  
There are no existing implementations, and as a result, there should be no 
expectation that EAP-TLS clients or servers will understand these 
extensions.  It seems like these OIDs are problematic since they don't 
correspond to values of the NAS-Port-Type attribute, and therefore can't be 
compared to NAS-Port-Type values by implementations that don't understand 
them.



2. Discussion of naming

This section recommends

Where the subjectAltName field is present, the Peer-Id or Server-Id
is set to the contents of the subjectAltName.  If subject naming
information is present only in the subject field, then the Peer-Id or
Server-Id is set to the Distinguished Name (DN).

It is possible that more than one subjectAltName may be present in a
certificate.  Are there any rules as to how this is represented as a
Peer name?  Also would it be more consistent to use the DN unless it is
empty?


Can someone descirbe a case where there would be more than one 
subjectAltName in a certificate?

I'm having a hard time wrapping my head around this case.


3. Discussion of authorization

The later part of this section seems to discuss authorization.  A
suggestion for revised text was made in
http://www1.ietf.org/mail-archive/web/emu/current/msg00309.html.  Does
the suggested text convey the necessary information?


I'd suggest that the rest of the section include the following text (missing 
the RFC 4334 discussion):


Once the endpoints of the EAP-TLS conversation have been authenticated
and have had their certificates validated they then must be authorized.
The authorization process makes use of the contents of the certificates
as well as other contextual information.  While authorization
requirements will vary from deployment to deployment it is RECOMMENDED
that implementations be able to authorize based on the EAP Peer and EAP
Server identities defined above.

Since authorization based on specific identities may not scale well in a
large environment implementations may make use of other fields in the
certificate.  For example an implementation may be configured to accept
all certificates issued by a CA with a certain name format as trusted.
In another example the peer may test whether the EAP server certificate
is signed by a CA controlling the destination network and whether the
Server-Id matches the format expected for that network.  For example, an
EAP peer connecting to the EXAMPLE SSID may check whether the
Server-Id matches the regular expression *.example.com, in addition to
checking whether the server certificate chains to the example.com CA.
However, it is important to realize that any certificate matching the
above criteria will be authorized, so this method should only be used in
environments where this is guaranteed to be accurate.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[Bernard Aboba]

Comparing the Server-Id in the certificate to the expected server
name limits the damage that will result from an attacker compromising
a server private key.  If the peer does not check the Server-Id, then
the peer would accept a compromised server certificate chaining to
any of the configured trust anchors.


[Joe] If the server key is compromised then it seems checking the
server-ID will not help discover this or limit damage.


Maybe this should have been compromising a trust anchor private key.  I 
think the idea was to prevent a compromise of a trust anchor from enabling 
attackers to carry out rogue authenticator attacks across the board.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[Bernard Aboba]

 How about rephrasing the text to something like this?
 
Since the identity presented in the Identity Response need not be
related to the identity presented in the peer certificate, EAP-TLS
implementations SHOULD NOT require that they be identical.
However, if they are not identical, the identity presented in the
Identity Response is unauthenticated information, and SHOULD NOT be
used for access control or accounting purposes.

Looks good.

 I'm aware that some implementations do this, but the document should
 explain the security implications better. If you compare the name in
 the certificate with the expected server name, an attacker fool you if
 he breaks into that server and steals its private key. If you don't
 check the name, the attacker can steal a private key corresponding to
 any certificate issued by your trusted CA (which in case of large CA
 could be millions of potential points of failure).

OK. 

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05

[Bernard Aboba]

Thanks for catching this.  Yes, it is a typo.



From: Jouni Malinen [EMAIL PROTECTED]
To: emu@ietf.org
Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05
Date: Thu, 14 Dec 2006 19:52:06 -0800

On Thu, Nov 30, 2006 at 10:28:51AM -0800, Joseph Salowey (jsalowey) wrote:
 This is a working group last call for draft-simon-emu-rfc2716bis-05.

2.3.  Key Hierarchy

   Session-Id   = 0x0C || client.random || server.random


Isn't Session-Id usually the concatenation of the EAP type and some
session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP
type 13 (0x0D) and I would have expected to see 0x0D || ... here.

--
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[Bernard Aboba]

Thank you for your detailed and thoughtful review comments.


Roughly in order of importance:

1) Section 2.7: An EAP-TLS server supporting privacy MUST NOT treat a
certificate list containing no entries as a terminal condition;
instead it MUST bring up the TLS session and then send a server_hello
followed by a certificate_request.

Not quite correct... The TLS server sends hello_request, then the
handshake proceeds as normally (client sends client_hello, server
sends server_hello, certificate, server_key_exchange,
certificate_request, and server_hello_done, and so on). Example 2 in
Appendix B also needs to be fixed.


Right.


2) Section 2.1 is very long and quite difficult to read. I have two
suggestions for clarifying it a bit: First, split the text to four
subsections: first covering the basic case, the second session
resumption, the third privacy support (current section 2.7), and the
fourth the error cases. Second, copy or move some/all of the message
sequence diagrams from Appendix B to here.


The suggestion to split section 2.1 is a good one.


3) The document would be much shorter if it omitted text that applies
to all EAP methods. This text might have been necessary when RFC 2716
was published, but not is largely covered by RFC 3748. For example,
Sections 2.2, the non-EAP-TLS specific parts of Section 3, Section
4.4, and Section 4.5 seem largely redundant to me...


I agree that Sections 2.2, 4.4 and 4.5 could probably be deleted, since much 
of this material is now in RFC 3748.   Section 3.1 could also probably be 
deleted, since it is just reprising the EAP packet format.



4) Section 2.4, SHOULD NOT use the identity presented in the Identity
Response for access control or accounting purposes: is using
unauthenticated information for access control or accounting purposes
really something where we think there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or
even useful? (quoting from RFC2119)


Some EAP-TLS implementations do match the identity in the Response with the 
identity included in the certificate, though this is not a good idea.  The 
SHOULD was left here so as to be compatible with

RFC 3748 Section 5.1:

 It is RECOMMENDED that the Identity Response be used primarily for
 routing purposes and selecting which EAP method to use.  EAP
 Methods SHOULD include a method-specific mechanism for obtaining
 the identity, so that they do not have to rely on the Identity
 Response.


5) Section 2.4, SHOULD also examine the Server-id in order to
determine whether the EAP server can be trusted: if this is really an
appropriate SHOULD, it definitely needs more discussion.  If you don't
check the name (the most important piece of information!) in the
certificate, why bother checking the certificate at all, or details
such as revocation?


Some implementations may not have expectations relating to the server name 
and may just verify the server certificate chain.  Verifying the certificate 
chain and checking revocation provide benefits independent of checking the 
server name against a pre-configured template.



6) Section 2.4: For example, an EAP peer connecting to the EXAMPLE
SSID may wish to check whether the Server-Id matches the regular
expression *.example.com, in addition to checking whether the server
certificate chains to the example.com CA.

I find this suggestion quite dubious. So if I break into
www.example.com and steal its private key, I should be able to
masquerade as EAP server for EXAMPLE SSID? Even though this text is
only an example, it's one with serious security considerations...


If you compromised the private key corresponding to the server certificate, 
then you could put up a rogue AP utilizing the EXAMPLE SSID, and could 
convince the EAP-TLS peer that your rogue AP was genuine.  I believe that 
such an attack would work on quite a few EAP/802.11 implementations, 
assuming that your rogue AP advertised the same security properties as the 
original EXAMPLE SSID.



7) Section 4.2 Where the subject field is not empty, the Peer-Id and
Server-Id are obtained from the Common Name (CN) field of the DN

It's not guaranteed a DN always include the CN field, or that it
includes only one CN field, or that the CN alone (without the rest of
the DN) is a meaningful identifier. So probably the Peer-Id/Server-ID
should be the whole DN...?


Will have to think about this.


8) Section 4.2: A valid EAP-TLS client certificate SHOULD contain an
extendedKeyUsage value indicating support for Client Authentication
(1.3.6.1.5.5.7.3.2).  A valid EAP-TLS server certificate SHOULD
contain an extendedKeyUsage value indicating support for Server
Authentication (1.3.6.1.5.5.7.3.1).

According to RFC 3280, 1.3.6.1.5.5.7.3.2 means TLS WWW client
authentication. Although EAP-TLS does use TLS, we're not doing WWW
client authentication here, so is the recommendation to include this
EKU a good one? Is it consistent with what existing 

Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05

[Bernard Aboba]

However, this requires more cryptographic computations
since both entities will encrypt the second TLS session packets and it
augments significantly the number of rounds trips over the wireless link,
which is not always widely available.


As you point out, the approach described in the document is not optimal; 
rather the goal was to provide functionality that could be most easily 
implemented, and would be good enough.


The computational load of encrypting additional packets is fairly small 
compared with the initial TLS negotiation, which may involve public key 
computations, so I don't think this is much of a burden.


I believe that the proposed approach adds 1.5 round trips to an initial 
conversation (session resumption is not affected).  As noted in the draft, 
ciphersuite negotiation could eliminate this.  On the other hand, the total 
number of round-trips in EAP-TLS is largely determined by the certificate 
chain size, which is the same whether privacy is supported or not.  So 
adding 1.5 round-trips for an initial exchange will typically not represent 
much of a performance penalty in intranet scenarios.



Hajjeh and I recently submitted a document to add identity protection to
TLS. This solution does not suffer from interoperability issues related to
TLS Extensions, TLS 1.0 and TLS 1.1 implementations. I would like that
EAP-TLS reconsider this document for identity protection implementations.


If and when identity protection ciphersuites are added to TLS, EAP-TLS 
implementations can support it.  I agree that it would be somewhat more 
efficient in terms of round-trips.


However, I don't think we want to require that EAP-TLS implementations 
wishing to implement privacy support identity protection ciphersuites.  For 
example, the set of Identity protection ciphersuites described in the 
document are limited, so that an EAP-TLS implementation might not be able to 
negotiate the ciphersuites that it would prefer along with identity privacy.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] MSK but no EMSK

[Bernard Aboba]

One question though. I couldn't find any mention of MSK or EMSK in RFC
2716. Can you tell us how to get those keys out of that spec?


RFC 2716bis explains how the send and receive keys map to the MSK/EMSK:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK

[Bernard Aboba]

[Joe] It seems that the server ID is as authenticated as the client ID.
The server ID and client ID are associated with the shared key.  If a
different identity is asserted a different key would be selected and the
protocol should fail.


Since more than one AAA server can have access to the credentials, I don't 
see how the client can verify which server it is talking to.  It only knows 
that the server has access to the PSK, not which server it is.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] MSK but no EMSK

[Bernard Aboba]

I remember someone in Hokey WG meeting mentioned that not all methods
generate EMSK (even though they generate MSK). Is that accurate?


The simple answer is we don't know because prior to RFC 3748, EAP Type 
Codes could be allocated without a specification.


However, for methods published as RFCs or in the RFC Editor Queue, we know 
the following:


a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, 
GTC).


b) All of the key generating EAP methods published as RFCs specify how to 
derive the MSK and EMSK.   This includes EAP TLS (RFC 2716), EAP SIM (RFC 
4186), and EAP AKA (RFC 4817).   The generation of the Session-Id, Peer-Id 
and Server-Id is also specified for these methods in the Key Management 
Framework document.


c) All of the key generating EAP methods currently in the RFC Editor queue 
specify how to derive both the MSK and EMSK.  This includes EAP PSK 
(draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake-02.txt), 
EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP 
(draft-nystrom-eap-potp-07.txt).  None of these methods specify how to 
derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant 
with the EAP Key Management Framework).


d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, 
and Session-Id and Peer-Id/Server-Id if known.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

[Bernard Aboba]

Here the goal of privacy is to protect the identity from exposure over the 
wire (e.g. wireless network), and possibly exposure to the local operator.  
There is no goal to hide the user identity from the EAP server, if only 
because if that were done authentication would be difficult.



From: Madjid Nakhjiri [EMAIL PROTECTED]
To: 'Bernard Aboba' [EMAIL PROTECTED], 
[EMAIL PROTECTED],emu@ietf.org

Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
Date: Thu, 02 Nov 2006 18:07:29 -0800

I have a question that is somewhat related (at least what I think:))

In the privacy section (2.7) it is stated that when a peer that supports
privacy receives a subsequent certificate_request from the server (after 
the

server have received a list with no certs), the peer MUST provide a cert
list containing at least one entry in its response to the server.
What would the subject name in that entry be, if the peer intends to 
protect

its identity? Is there a part of the draft that explains this and I missed?

Thanks,

Madjid

-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 22, 2006 8:47 AM
To: [EMAIL PROTECTED]; emu@ietf.org
Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

The document should also state in the security considerations section
that the identity in the identity response is not necessarily related to
the identity authenticated in EAP-TLS and should not be relied upon for
any access control or accounting purposes.

Here is some proposed new text for Section 2.4:

As noted in [RFC3748] Section 5.1:

   It is RECOMMENDED that the Identity Response be used primarily for
   routing purposes and selecting which EAP method to use.  EAP
   Methods SHOULD include a method-specific mechanism for obtaining
   the identity, so that they do not have to rely on the Identity
   Response.

As part of the TLS negotiation, the server presents a certificate to
the peer, and if mutual authentication is requested, the peer
presents a certificate to the server.  EAP-TLS therefore provides
a mechanism for determining both the peer identity (Peer-Id in [KEYFRAME])
and server identity (Server-Id in [KEYFRAME]).
Since the identity presented in the Identity Response need
not be related to the identity presented in the peer certificate,
EAP-TLS implementations SHOULD NOT require that they be identical,
and SHOULD NOT use the identity presented in the Identity Response
for access control or accounting purposes.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Comment on 2716bis: Examples in Appendix B

[Bernard Aboba]

Here is a strawman responding to Pasi's comments:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-05.txt



From: Bernard Aboba [EMAIL PROTECTED]
To: [EMAIL PROTECTED], emu@ietf.org
Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B
Date: Mon, 06 Nov 2006 16:34:37 -0800


client sends change_cipher_spec/finished twice?


I think the client will send the Alert at that point, no?


I don't see how this message sequence could ever occur.


It is possible for a session resume attempt to fail, but if so, it will not 
look like the example.  A client could mistakenly attempt a session resume 
with a commonly utilized SSID, but then typically the server will not have 
keying material for the Session-Id so that the session resume attempt will 
fail quickly.



If the client is not happy with the server's cert anymore, it won't resume 
the session.


Right.


If the master_secret is not the same, TLS finished message
can't be decrypted, so the conversation will end there.


Even getting there assumes that the server has state for the Session-Id 
proposed by the client.  Therefore the failure will typically occur 
earlier.


As far as I can see, examples 7 and 8 could just be deleted without losing 
anything.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Re: new authenticated encryption draft and a proposed use in EMU GPSK

[Bernard Aboba]

Hi David,

I have a problem with the suggested approach for a couple of reasons:

* There is no problem with the currently defined cipher suites. The
design team has just picked something; Different cipher suites got
proposed during the design team discussions and almost all of them got 
removed from the document. As you saw from the discussions and my previous 
mail to the EMU mailing list it seems that there is a shift towards AES 
CBC. That's fine with me.


I agree with Hannes here.

To date, EMU documents have been consistent with respect to the choice of 
ciphersuites - rmandating 3DES/HMAC-SHA1 ciphersuites today, transitioning 
to AES CBC tommorrow.


Introducing a dependency on AES CCM for EAP GPSK is not advisable at this 
time, since FIPS 140-2 certified libraries for AES CCM are not common today, 
whereas support for AES CBC is more widespread.



* I don't like the split into two documents since it makes a simple
protocol complicated. For EAP-GPSK I don't think that we will see 10+ 
cipher suites being proposed.


The goal for EAP GPSK was to produce a simple, low footprint method that 
could be implemented easily in embedded devices.   Splitting the 
specification in two parts, and  introducing 10+ ciphersuites runs counter 
to that goal and and could risk introducing interoperability problems.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] Duplicate integrity protection on Protected Payload datainGPSK

[Bernard Aboba]

AES-CBC seems like a good choice.


This might also be a decent choice for the EAP-TLS mandatory-to-implement 
ciphersuite (unless the issues with 3DES can be ironed out).




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] EMU WG issues tracker?

[Bernard Aboba]

Does the EMU WG have an issues tracker?  


___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

[Emu] Partial Proposed Resolution to RFC 2716bis Review

[Bernard Aboba]

Find enclosed below some review questions from Joe Salowey.  I still am 
researching the answers to questions 1A and 1B, so I have not included a 
proposal for these yet.


--
C. This document should probably reference RFC 3280.

[BA] DONE.

D. I think the last paragraph might not be quite correct:

... Please note that in the case where the EAP authentication is remoted 
that

  the EAP server will not reside on the same machine as the
  authenticator, and therefore the name in the EAP server's certificate
  cannot be expected to match that of the intended destination. In this
  case, a more appropriate test might be whether the EAP server's
  certificate is signed by a CA controlling the intended destination
  and whether the EAP server exists within a target sub-domain.

I'm not quite sure what the is meant by target sub-domain.  In any
case it is important that the peer be able to authorize the server as an
EAP-Server that can authorize the authenticator the peer is connecting
to. This is more than being issued by an organizational CA since that
particular CA may issue certificates for many purposes. There either
needs to be something in the certificate or the peer must have
configuration to be able to perform the authorization.

[BA] How about this?

  The peer MUST verify the validity of the EAP server certificate, and
  SHOULD also examine the EAP server name presented in the certificate,
  in order to determine whether the EAP server can be trusted.  For
  example, just because a server certificate can chain to a trust
  anchor does not necessarily imply that it is valid for connection to
  a particular network.  As a result, the peer may also want to test
  whether the EAP server certificate is signed by a CA controlling the
  destination network and whether the Server-Id matches the format
  expected for that network.  For example, an EAP peer connecting to
  the EXAMPLE SSID may wish to check whether the Server-Id matches
  the regular expression *.example.com, in addition to checking
  wehther the server certificate chains to the example.com CA.

2. Section 2.5 Key Hierarchy

A.  Why is the EMSK broken into two halves?  It should not be as this
implies a particular usage for the EMSK.  It should just be one 64 byte
value.

[BA] Right.  I've removed the mateiral on the halves of the EMSK.

B. Does this section tie the implementation of the PRF to 2246?  What if
TLS 1.2 supports a different PRF?

[BA] I've removed the RFC 2246 reference here and also replaced other 2246 
references with

RFC 4346 since that obsoletes 2246.

C. This section shows the TLS key hierarchy, shouldn't it show the
EAP-TLS key hierarchy?

[BA]  How about this?

   In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
  secret via a one-way function.  This ensures that the TLS master
  secret cannot be derived from the MSK, EMSK or IV unless the one-way
  function (TLS PRF) is broken.  Since the MSK and EMSK are derived
  from the TLS master secret, if the TLS master secret is compromised
  then the MSK and EMSK are also compromised.

  The MSK is divided into two halves, corresponding to the Peer to
  Authenticator Encryption Key (Enc- RECV-Key, 32 octets) and
  Authenticator to Peer Encryption Key (Enc- SEND-Key, 32 octets).

  The IV is a 64 octet quantity that is a known value; octets 0-31 are
  known as the Peer to Authenticator IV or RECV-IV, and Octets 32-63
  are known as the Authenticator to Peer IV, or SEND-IV.

  EAP-TLS derives exported keying material and parameters as follows:

  MSK(0,63)   = TLS-PRF-64(TMS, client EAP encryption,
   client.random || server.random)
  EMSK(0,63)  = second 64 octets of:
TLS-PRF-128(TMS, client EAP encryption,
   client.random || server.random)
  IV(0,63)= TLS-PRF-64(, client EAP encryption,
   client.random || server.random)


  MSK(0,31)   = Peer to Authenticator Encryption Key (Enc-RECV-Key)
(MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
PMK in [IEEE-802.11i].
  MSK(32,63)  = Authenticator to Peer Encryption Key (Enc-SEND-Key)
(MS-MPPE-Send-Key in [RFC2548])
  IV(0,31)= Peer to Authenticator Initialization Vector (RECV-IV)
  IV(32,63)   = Authenticator to Peer Initialization vector (SEND-IV)
  Session-Id  = 0x0C || client.random || server.random

  Where:

  IV(W,Z)   = Octets W through Z inclusive of the IV.
  MSK(W,Z)  = Octets W through Z inclusive of the MSK.
  EMSK(W,Z) = Octets W through Z inclusive of the EMSK.
  TMS   = TLS master_secret
  TLS-PRF-X = TLS PRF function computed to X octets
  client.random = Nonce generated by the TLS client.
  server.random = Nonce generated by the TLS server.

|   | pre_master_secret   |
  server|   |   

[Emu] EAP-TLS implementers?

[Bernard Aboba]

The EMU WG charter requires that RFC 2716bis remain backward compatible with 
existing EAP-TLS implementations:


- An update to RFC 2716 to bring EAP-TLS into standards track, clarify
specification, interoperability, and implementation issues gathered
over the years, and update the document to meet the requirements of
RFC 3748, RFC 4017, and EAP keying framework documents. Backwards
compatibility with RFC 2716 is a requirement.

Given the widespread interoperability problems experienced with TLS 
implementations, the question has arisen as what if any TLS functionality 
introduced after TLS v1.0 can be included in RFC 2716bis.


To attempt to address this, we would like to assemble a team of EAP-TLS 
implementers which may participate in impromptu tests of EAP-TLS 
interoperability (such as exchanges of RADIUS/EAP-TLS

traffic over the Internet).

If you are interested in participating, please contact me.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

RE: [Emu] EMU PSK opaque blogs

[Bernard Aboba]

Just a random comment:

Server identity as an opaque blog.

Many blogs are in fact quite opaque, but do we really need to force the user 
to read an opaque blog as part of the protocol? :)




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Identity Protection in EAP-TLS

[Bernard Aboba]

Furthermore if the server ignores  the TLS extension the client MAY send 
its certificate encrypted with its preferred

encryption algorithm (the first in the TLS extension list)


This definitely breaks backward compatibility.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Re: [Emu] Identity Protection in EAP-TLS

[Bernard Aboba]

Clearly using this within eap-tls would require some specification
work, but I think would be preferable to your approach.


The EMU WG charter states:
Backwards compatibility with RFC 2716 is a requirement.

So I'd like to understand which approach (if any) is backward compatible 
with existing RFC 2716 implementations.


EAP-TLS server implementations always request a certificate.   If the client 
desires privacy, it can choose not to respond to the certificate request.  
An EAP-TLS server supporting privacy would then bring up the TLS channel and 
request the certificate again, and a client supporting privacy would comply. 
However, existing EAP-TLS servers will terminate the connection if a 
certificate is not provided in response to the first request, so an uplevel 
client talking to a downlevel server would have to choose between 
connectivity and privacy, at least on the first attempt.  On subsequent 
attempts, the uplevel client could choose whether it is willing to hand over 
its certificate in cleartext and if so, it could connect using the RFC 
2716-specified sequence.


The backward compatibility of the client extension approach depends on the 
server's reaction to the offering of client extensions.  There seems to be 
an assumption that a downlevel server will ignore the extensions and that 
therefore the conversation would complete as in RFC 2716.  This would allow 
a client supporting privacy extensions but willing to connect without 
privacy to successfully authenticate on the first attempt.  However, I'm not 
clear whether the underlying assumption of extension backward compatibliity 
is actually true or not -- as I understand it, some EAP-TLS server 
implementations do not react well to extensions.




___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu