Subject: Re: [Emu] #18 Internationalization

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Aug 2009 00:08:41 -0700

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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 13 Aug 2009 12:31:59 -0700

The core chartered requirements also include the use of the tunnel
method for password authentication, so it is important to consider this
case.   

In addition, there is a proposal for defining conventions for defining
generic textual attributes within the tunnel.  I think the main
advantage of doing this would be to have a consistent approach to
internationalization.   If this is too difficult, perhaps it should be
dropped, although I'm not sure these requirements would be too different
form what is needed for password authentication.  

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernard Aboba
> Sent: Monday, August 10, 2009 12:09 AM
> To: [email-masked]
> Subject: Re: [Emu] #18 Internationalization
> 
> Joe Salowey said:
> 
> "
> #18: Internationalization
> 
> 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. 
> 
> 
> 
> 
> <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 
> 	
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Aug 2009 16:39:18 -0700

Within Tunnel methods, exchanges of user names and passwords are often accomplished either
using TLS or existing EAP methods (e.g. Identity or inner authentication methods).   There are
some tunnel methods that have their own native authentication methods (e.g. EAP-TTLSv0), but
even those typically reuse functionality defined previously (e.g. Diameter AVPs for PAP, CHAP, etc.).  

Given that, I'd suggest that the scope of the requirements needs to be clarified.  For example, 
support for negotiation of language tags might make sense for tunnel methods that carry such
text in an EAP-method specific way.  However, a method that relies solely on TLS or existing
EAP methods would not benefit from this functionality, and the requirements document should
not imply that it is within scope for proposals to change TLS, RFC 3748 or existing EAP methods
so as to better support internationalization. 

> Subject: RE: [Emu] #18 Internationalization
> Date: Thu, 13 Aug 2009 12:31:59 -0700
> From: [email-masked]
> To: [email-masked]; [email-masked]
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Aug 2009 15:06:22 -0700

The scope of the work is a method for transporting passwords.  The
requirements include appropriate internationalization support.  

Section 4.6 covers requirements that existing EAP method not be modified
by the tunnel.  The sections that talk about internationalization are:

4.3.6 which discusses an optional requirement to have an attribute
format for display strings that supports internationalization. 

4.5.2 which discusses the internationalization requirements for a
password exchange.  

If existing mechanisms do not meet the requirements for
internationalization then either they will need to be modified or new
ones will need to be developed.  

I'm not sure where the confusion exists, other than the requirements for
internationalization themselves.  

Joe

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, August 13, 2009 4:39 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> some tunnel methods that have their own native authentication 
> methods (e.g. EAP-TTLSv0), but even those typically reuse 
> functionality defined previously (e.g. Diameter AVPs for PAP, 
> CHAP, etc.).  
> 
> Given that, I'd suggest that the scope of the requirements 
> needs to be clarified.  For example, support for negotiation 
> of language tags might make sense for tunnel methods that 
> carry such text in an EAP-method specific way.  However, a 
> method that relies solely on TLS or existing EAP methods 
> would not benefit from this functionality, and the 
> requirements document should not imply that it is within 
> scope for proposals to change TLS, RFC 3748 or existing EAP 
> methods so as to better support internationalization. 
> 
> > method for password authentication, so it is important to consider 
> > this case.
> > 
> > dropped, although I'm not sure these requirements would be too 
> > different form what is needed for password authentication.
> > 
> > Joe
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Bernard Aboba
> > > authentication 3. Other textual data "
> > > 
> > > 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.
> > > 
> > > 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.
> > > 
> > > 
> > > 
> > > 
> > >

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 17 Aug 2009 22:42:31 -0700

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.

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Aug 2009 14:58:37 +0800

It seems to me, the consistency between EAP peer and EAP Server can be caused by the Lying NAS 
Even this NAS is not malicious authenticator who impersonates another authenticator, this NAS should 
be a stupid NAS or malfunctional NAS who make a mistake for some reason. Because this NAS distributes
inconsistent data to the peer and server respectively. 

>From this aspect, the lying NAS can be understoond as ill NAS. am I right?
On the other hand, as described in the section 5.3.3, 
"
it is possible for a  first-hop AAA proxy to detect a AAA client attempting to impersonate
another authenticator.
"
Based on this, impersonation issue seems to overlap with channel binding or lying NAS issue.

Regards!

-Qin
----- Original Message ----- 
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 18, 2009 1:42 PM
Subject: [Emu] Impersonation and Lying NAS problem: two distinct issues (with different solutions)

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 18 Aug 2009 10:22:44 +0300

There are 3 parties in the AAA/EAP exchange. Not every party is
authenticated in the exchange (e.g. the NAS/AAA client is not
authenticated by the EAP peer) -- there is only key confirmation taking
place. 

The NAS can therefore report different identities to the EAP client and
to the AAA server. 
To deal with this issue the solution of channel binding was proposed.
There are, however, other solutions as well (theoretically at least). 

The impersation aspect that is described in Section 5.3.2 of
http://tools.ietf.org/html/rfc5247 is a very different thing, namely the
case where one authenticator impersonates another authenticator towards
the AAA server. 

Since the identity reported within the channel binding solution is not
related to the identity used for authenticating the AAA client to a AAA
server (or to a proxy) the two aspects, as Bernard said, are unrelated. 

Ciao
Hannes

>Behalf Of ext Qin Wu
>Sent: 18 August, 2009 09:59
>To: Bernard Aboba; [email-masked]
>Subject: Re: [Emu] Impersonation and Lying NAS problem: two 
>distinctissues (with different solutions)
>
>It seems to me, the consistency between EAP peer and EAP 
>Server can be caused by the Lying NAS Even this NAS is not 
>malicious authenticator who impersonates another 
>authenticator, this NAS should be a stupid NAS or 
>malfunctional NAS who make a mistake for some reason. Because 
>this NAS distributes inconsistent data to the peer and server 
>respectively. 
>
>On the other hand, as described in the section 5.3.3, "
>it is possible for a  first-hop AAA proxy to detect a AAA 
>client attempting to impersonate another authenticator.
>"
>Subject: [Emu] Impersonation and Lying NAS problem: two 
>distinct issues (with different solutions)
>
>
>> Dan Harkins said:
>>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Aug 2009 06:59:01 -0700

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.
"

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 18 Aug 2009 07:10:19 -0700

The problem is that the internationalization language is too general.  
For example, Section 4.3.6 states:

"  Any strings sent by the server intended for display to the user MUST 
   be sent in UTF-8 format and SHOULD be able to be marked with language 
   information and adapted to the user's language preference.
"

This language applies to any string sent by the server, regardless of whether it was
sent as part of TLS, or an existing EAP method.  Changing this to "Strings sent as
part of the tunnel method (e.g. not part of the tunneling protocol or inner method)"
would make more sense. 

Also, we probably should make a distinction between numeric and non-numeric 
strings.  Requiring numbers to be internationalized (e.g. use of Arabic instead of
ASCII digits) is not probably not what was intended here. 

Also, there are issues in Section 4.5.2:

"   The password authentication exchange MUST support user names and
   passwords in international languages.  It MUST support encoding of
   user name and password strings in UTF-8 [RFC3629] format.  Any
   strings sent by the server during the password exchange and intended
   for display to the user MUST be sent in UTF-8 format and SHOULD be
   able to be marked with language information and adapted to the user's
   language preference.
"

Again, this section refers to "any strings sent by the server", regardless of whether
those strings are sent within TLS or existing EAP methods.  The scope of this requirement
should be narrowed. 

> Date: Mon, 17 Aug 2009 15:06:22 -0700
> From: [email-masked]