Subject: [eap] Issue 33: Encoding of Identity Response

From: [email-masked] (Bernard Aboba)
Date: Sat, 5 Oct 2002 19:20:45 -0700 (PDT)

Issue 33: Encoding of Identity Response
Submitter: Mark Wodrich
Submitter email address: [email-masked]
Date first submitted: August 12, 2002
Reference:
Document: RFC2284bis-05
Comment type: T
Priority: S
Section: 5.2

Rationale/Explanation of issue:

Displayable messages are to be encoded in UTF-8. The Identity Request
MAY contain a displayable message, and if so, that is UTF-8 encoded.
But what about an Identity Response? Is that UTF-8 encoded? Does
RFC 2486 allow this? Please clarify in the text.

[BA] If the Identity Response contains an NAI, then the Response
MUST satisfy the NAI grammar described in RFC 2486. This appears to
enable any character to be utilized within the username, so UTF-8
is reasonable there. However, the encoding of the NAI realm is
subject to the same restrictions as Internationalized Domain Names,
which do *not* use UTF-8 encoding.

So I don't think that the Identity Response has the same requirements
as a Displayable Message (though it may indeed be displayed). Here is
the proposed text:

"If the Identity Response contains a Network Access Identifier (NAI),
then the NAI MUST conform to the grammar described in [RFC2486]. For
example, the realm field of the NAI may contain any characters legal
for inclusion within fully qualified domain names, and thus is
internationalized as though it were an Internationalized Domain Name
(IDN)."

---

From: [email-masked] (James Carlson)
Date: Sat, 5 Oct 2002 23:36:26 -0400

> Submitter email address: [email-masked]
[...]
> RFC 2486 allow this? Please clarify in the text.

I fail to see how this is an issue.  The 'identity' string is a
sequence of octets -- period.  Any semantics that it might possibly
have (including being an NAI, being in Chinese, or any other context)
is outside the scope of EAP itself.  The things that provide suitable
context here are:

	- the definition of the method to be used; some methods may
          have stronger requirements on identity values.

	- the deployment -- some operators may insist on having
          identities conform to some standard.  (For instance, some of
          our networks require IDs be given as two initials and an
          employee number.  Some networks require NAIs.)

	- the association -- a system attempting to prove its identity
          of course needs to have a pre-arranged association with the
          authenticator, and part of that association is the identity.

I think that last bit is the key one -- authentication isn't done in a
vacuum.

> internationalized as though it were an Internationalized Domain Name

I think that makes the text rather worse than better.  It seems to
imply that there's some sort of constraint on how the identity can be
used.

Given the linkage to other bits of the authentication infrastruture
here, I think this request is somewhat akin to insisting that any
strings that appear in an IP datagram be UTF-8 encoded.  Perhaps
consistency across all protocols could be useful to someone, but I
don't think it should be codified.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677