Re: Anatole in-room net confusion
Last night the nice desk lady said go ahead and agree to pay for access, and that at checkout the charges will be disappeared. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[EMAIL PROTECTED] Guerilla Party Events for Tuesday
[EMAIL PROTECTED] Guerilla Party Events for Tuesday **I Wish I Had an IETF Tattoo Day** Ever wished you had an IETF tattoo? Today, your wish can come true with the hot-off-the-presses temporary version of the [EMAIL PROTECTED] tattoo. Pick up a tat at the [EMAIL PROTECTED] table. These arent as limited as the grey beards but since we know the tats will be coveted for those boring meetings back in the office where you might want to come in emblazoned with IETF body art, I will remind you that these are first-come, first-served and will be placed on the table at random times during the day. Be nice and share. **Tuesdays Social Gone Wild over [EMAIL PROTECTED] On March 21st, in conjunction with IETF65, Nokia and the Internet Society cordially invite you to celebrate [EMAIL PROTECTED] in Dallas, Texas at the traditional IETF Social. It will be held at Eddie Deen's Ranch in downtown Dallas, Texas. Planned festivities include: * Reprise of David Clark's famous "rough consensus and running code" speech from David himself. * Acknowledgment of the founders of the IETF and those that have played an important role in its growth * Remarks from the current IETF and IAB Chairs with a toast-off to the future of the IETF (so start working on the toasts now ) * Tons of good food, drinks and IETF colleagues - from the first IETF all the way to the present. * A cake worthy of the IETF - chocolate sculptures and quotable quotes bring your camera. Tickets are still available. Busses will be leaving from the hotel. Paddles and life jackets are optional. For driving directions, visit http://www.eddiedeen.com/ranch_facility.htm For the folks that cant attend, well be taping the festivities and archiving video on the web in a week or two. Crack a brew and watch on your monitor. [EMAIL PROTECTED] Trivia** One aside: Steven Bellovin, who wished he could have been in Dallas on Monday to be part of the real grey beard faction, thought the trivia buffs in the crowd would like to visit http://ioih.org The Institute of Internet History. Visit todays trivia event at http://ietf20.isoc.org/trivia/. Take a minute or two to test your knowledge of the IETF and get a chance to be one of 20 lucky people each day to receive a bag filled with [EMAIL PROTECTED] goodies. For today's (Tuesdays) drawing, we will select the first 5 submitters, 10 random names and the 5 last submitters from all entries. Timing is everything. If you were a winner for Mondays event, you should have received an email from me telling you so. Pick up your prize during the course of the IETF65 meeting in the ISOC office. Office hours will be posted with the winners list on the [EMAIL PROTECTED] table. The ISOC office is at the Opal Room on Tower lobby floor across from Business Center. Want to add your own trivia question? Send the question and three answers (including the right one) to [EMAIL PROTECTED] Well add it to future quizzes if we can. **Miscellany** [EMAIL PROTECTED] Guerilla Partying is sponsored by ISOC for IETF65. This is for entertainment. None of your registration fees were used to support these activities. No humans were harmed (but possibly should have been) during the planning process. No RFCs are available to further explain this and none are planned. Yes, there will be different activities each day. And, if you dont want to pay attention to the [EMAIL PROTECTED] stuff because it makes you feel too young or you are too busy trying to find all the good beer places in Dallas, delete these messages. **Mondays Trivia Q&A** 1. For what document was the longest ever single sitting working group meeting convened? Host Requirements from 8 am until 2 am the next morning. Masochists, anyone? 2. Who was the first chair of the IETF? Mike Corrigan (say hi to him at the social) 3. The IETF had its own series of document separate from RFCs and prior to Internet Drafts. Name it and expand the acronym. IDEAS - Internet Design, Engineering and Analysis Series. We are so clever with our names, arent we? 4. Who was member #1 for the ISOC? Jon Postel. Yes, he whipped out his checkbook and threw the check across the table to Vint. The rest is history. Im pretty sure ISOC still takes checks. 5. Given an infinite bandwith and a round trip time of 20ms, what's the maximum throughput of a TCP connection assuming no negotiated options. 50 * 64K = 3200K ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pana-framework-06
Russ, First of all, thank you very much for your input. [1] I checked the latest 802.11ma draft and I confirm that the description in pana-framework draft stating that Class 1 data frames can be received in any state is not applicable any more. So the description on Class 1 data frame should be removed from the pana-framework draft. [2] It is not still clear whether running PANA over IEEE 802.1X Uncontrolled Port is prohibited in IEEE 802.11i specification even in the latest 802.11ma draft. In the PANA WG session today, Bob O'Hara indicated the following text in 802.11i, clause 6.1.4: "The IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled or if the MSDU does not represent an IEEE 802.1X frame." On the other hand, 802.11i clause 5.4.2.2 describes as follows (I checked the latest 802.11ma draft and the description remains the same): "However, a given protocol may need to bypass the authorization function and make use of the IEEE 802.1X Uncontrolled Port." According to the text, it is still possible to *interpret* this text such that a give protocol like PANA is allowed to exchanged over 802.1X Uncontrolled Port. [Note that several days after the email discussion over the EAP mailing list quoted below, I had a short conversation on this issue with Jesse Walker during IEEE 802 interim meeting in January in order to follow-up the email discussion and understand the input from Jesse more. As far as I understand, he seemed to agree on this possible interpretation while he mentioned that there is no existing 802.11i implementation that uses 802.1X Uncontrolled Port for non-802.1X frame exchange, but I may be still misunderstanding something. Also, for the sake of completeness of the email discussion over the EAP mailing list, the following email that I sent in response to msg03872 should be quoted as well: http://lists.frascone.com/pipermail/eap/msg03879.html.] The pana-framework draft is written based on the possible interpretation, not based on existing 802.11i implementation. As far as the pana-framework draft is consistent with 802.11i specification in terms of clause 5.4.2.2, whether an 802.11i implementation runs PANA over Uncontrolled Port to bootstrap PSK mode seems to be an implementation or deployment issue. If the intent of 802.11i specification is to prohibit any data frame other than 802.1X frame exchanged over Uncontrolled Port without any exception, I'd suggest removing the above text in clause 5.4.2.2 from 802.11i specification. Best regards, Yoshihiro Ohba On Mon, Mar 20, 2006 at 08:17:22PM -0500, Russ Housley wrote: > Yesterday I had a discussion with Bernard Aboba about PANA. I think > that Bernard was talking to me because of my involvement in IEEE > 802.11i. It appears to me the PANA WG has a major problem. > > The PANA WG seems to have a fundamental misunderstanding about > 802.11i. I believe that the people involved in the PANA WG have been > told about their misunderstanding by the editor of 802.11i (Jesse > Walker from Intel), and it seems that this input was ignored this > input. As a result the PANA specification that will not work at all > in wireless LANs that deploy 802.11i. > > The PANA framework document states in Section 10.2.2: > >This model does not require any change in the current WPA and IEEE >802.11i specifications. > > The PANA framework document also states in Section 10.2.2: > >The IEEE 802.11 specification [802.11] allows Class 1 data frames to >be received in any state. Also, IEEE 802.11i [802.11i] optionally >allows higher-layer data traffic to be received and processed on the >IEEE 802.1X Uncontrolled Ports. This feature allows processing IP- >based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA) >on IEEE 802.1X Uncontrolled Port prior to client authentication. > > This is wrong on two points. First, 802.11 ESS mode does not allow > data frames to be sent except in State 3. I did not review the most > recent 802.11ma text, but I understand that this was recently > clarified in that document. Also, 802.11i does not allow non-802.1X > traffic to be received or sent until completion of 802.1X > authentication and the 802.11i 4-way handshake. > > This problem was discussed on the EAP WG in the following exchange > with Jesse Walker back in January: > >http://lists.frascone.com/pipermail/eap/msg03867.html >http://lists.frascone.com/pipermail/eap/msg03868.html >http://lists.frascone.com/pipermail/eap/msg03869.html >http://lists.frascone.com/pipermail/eap/msg03872.html > > Given this situation, an Access Point that implements 802.11i will > silently discard all PANA traffic, and as a result, the PANA usage > scenarios 802.11i (either TKIP or CCMP, which are called WPA and WPA2 > by the WiFi Alliance) cannot work as described. > > Russ > > > ___ > Ietf mailing l
Meeting Venue - Breakfast Ran Out
This morning the food was gone by 8:45 and the Hilton staff present made no efforts to remedy this, saying that all the food which had been ordered was consumed. Considering that the continental breakfast is included in our meeting fee, this is not an acceptable answer. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Stephane Bortzmeyer writes: > On Sun, Mar 19, 2006 at 12:42:17PM -0800, > Ned Freed <[EMAIL PROTECTED]> wrote > a message of 35 lines which said: >> The privileged port concept has some marginal utility on multiuser >> systems where you don't Joe-random-user to grab some port for a >> well known service. > "had", not "has". The concept was invented at a time where multi-users > machines were rare and expensive monsters. So, a request coming from > source port 513 probably was "serious". Today, any highschool student > is root on his PC and therefore this protection is almost useless. Stephane, you are thinking of a different "security mechanism" based on ports <1024 - the one used by the infamous Berkeley r* utilities to decide whether to trust a client's credentials. This mechanism doesn't use well-known ports, but "ephemeral" ports <1024 on the client side. I think it is fairly much consensus that this kind of mechanism has become useless years ago, for the reason you state. What we are collecting input on is for which kinds of use (if any) a privileged/well-known (as opposed to just IANA "registered") *server* port makes sense. -- Simon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pana-framework-06
> "Yoshihiro" == Yoshihiro Ohba <[EMAIL PROTECTED]> writes: e email discussion over Yoshihiro> the EAP mailing list quoted below, I had a short Yoshihiro> conversation on this issue with Jesse Walker during Yoshihiro> IEEE 802 interim meeting in January in order to Yoshihiro> follow-up the email discussion and understand the input Yoshihiro> from Jesse more. As far as I understand, he seemed to Yoshihiro> agree on this possible interpretation while he Yoshihiro> mentioned that there is no existing 802.11i Yoshihiro> implementation that uses 802.1X Uncontrolled Port for Yoshihiro> non-802.1X frame exchange, but I may be still Yoshihiro> misunderstanding something. Also, for the sake of Yoshihiro> completeness of the email discussion over the EAP Yoshihiro> mailing list, the following email that I sent in Yoshihiro> response to msg03872 should be quoted as well: Yoshihiro> http://lists.frascone.com/pipermail/eap/msg03879.html.] So, the implementability of our specifications is a significant concern. If we do not expect there to be environments in which a feature of our spec will be implementable, then we should remove that feature. Implementability is sufficiently important that RFC 2026 explicitly gives the IESG the ability to request an implementation report even for publication at proposed standard when it has questions about whether a particular feature can be implemented interoperably. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
Kurt, I've spent some time over this topic with Russ Housley and Paul Hoffman here at the IETF and the conclusion is that we should not specify any granular encoding or matching rules for the hints. The client's use of the name hint requires the client to know its account name and as such the client will also know in what form the server needs it. The client should never send the name hint in a way where the server needs to process it in order to map the hint to an account. There reference will be fixed (or removed). Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] > Sent: den 7 mars 2006 18:35 > To: ietf@ietf.org > Subject: draft-santesson-tls-ume Last Call comment > > I note the IETF last call was issued for rev. 2. That > revision no longer exists, hence I reviewed rev. 3. > > This document specification of a "User Principal Name", > I believe, is inadequate. > > The I-D indicates that a user_principal_name is a sequence of > 0 to 65535 bytes in the form of [EMAIL PROTECTED] However, > such a form implies the value is a character string, > but there is no mention of what character set/encoding > is used here. I would think interoperability > requires both client and server to have a common > understand of what character set/encoding is to > be used. Additionally, there is no discussion > of UPN matching. Are byte sequences that differ > only due to use of different Unicode normalizations > to be consider the same or differ? Are values > case sensitive or not? etc.. > > The domain_name field suffers not only from the > above problem, but is flawed due to use of the > outdated "preferred name syntax" of RFC 1034. > This syntax doesn't allow domains such as > 123.example. The text should likely reference > the RFC 1123 which updates the "preferred name > syntax" for naming hosts. > > Additionally, no mention of how International > domain names (IDNs) are to be handled. > > I recommend ABNF be used to detail the syntax > of each of these fields and that the I-D detail > how values of these fields are to be compared. > Additionally, the I-D should discuss how IDNs > are to be handled. > -- Kurt > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Simon Leinen wrote: Stephane Bortzmeyer writes: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed <[EMAIL PROTECTED]> wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. "had", not "has". The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was "serious". Today, any highschool student is root on his PC and therefore this protection is almost useless. It never was a protection against malevolent students but it still is a protection against silly mistakes. Just try "accidently" 'cd / ; rm -R *' You know what I mean with silly mistakes. It makes a difference beeing root or beeing user joe when you "accidently" execute the shown command. Mistakes like that do happen. Stephane, you are thinking of a different "security mechanism" based on ports <1024 - the one used by the infamous Berkeley r* utilities to decide whether to trust a client's credentials. This mechanism doesn't use well-known ports, but "ephemeral" ports <1024 on the client side. I think it is fairly much consensus that this kind of mechanism has become useless years ago, for the reason you state. Behind closed doors and on virtual machines they still work remarkebly well. It would be overkill to run an sshd on each of the virtual machines. So would be logging in as root to directly access the virtual root directories. What we are collecting input on is for which kinds of use (if any) a privileged/well-known (as opposed to just IANA "registered") *server* port makes sense. Some 70% of all server machines run operating systems that have a notion of multiuser and of privileged user. Only servers are allowed access to the privileged well-known ports. Allowing non-privileged programmes access to the privileged ports leads to desaster Moving the 1K border for well-known ports up to 16K would be nice in the long run. I agree, on the client only machines the distinction between well-known and not so well-known ports does not make much sense. But those clients cannot live without their servers and the servers would not survive very long without their well-known ports. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
At 11:06 AM 3/21/2006, Stefan Santesson wrote: >Kurt, > >I've spent some time over this topic with Russ Housley and Paul Hoffman >here at the IETF and the conclusion is that we should not specify any >granular encoding or matching rules for the hints. > >The client's use of the name hint requires the client to know its >account name and as such the client will also know in what form the >server needs it. What about character set/encoding? - Kurt >The client should never send the name hint in a way where the server >needs to process it in order to map the hint to an account. > >There reference will be fixed (or removed). > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > >> -Original Message- >> From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] >> Sent: den 7 mars 2006 18:35 >> To: ietf@ietf.org >> Subject: draft-santesson-tls-ume Last Call comment >> >> I note the IETF last call was issued for rev. 2. That >> revision no longer exists, hence I reviewed rev. 3. >> >> This document specification of a "User Principal Name", >> I believe, is inadequate. >> >> The I-D indicates that a user_principal_name is a sequence of >> 0 to 65535 bytes in the form of [EMAIL PROTECTED] However, >> such a form implies the value is a character string, >> but there is no mention of what character set/encoding >> is used here. I would think interoperability >> requires both client and server to have a common >> understand of what character set/encoding is to >> be used. Additionally, there is no discussion >> of UPN matching. Are byte sequences that differ >> only due to use of different Unicode normalizations >> to be consider the same or differ? Are values >> case sensitive or not? etc.. >> >> The domain_name field suffers not only from the >> above problem, but is flawed due to use of the >> outdated "preferred name syntax" of RFC 1034. >> This syntax doesn't allow domains such as >> 123.example. The text should likely reference >> the RFC 1123 which updates the "preferred name >> syntax" for naming hosts. >> >> Additionally, no mention of how International >> domain names (IDNs) are to be handled. >> >> I recommend ABNF be used to detail the syntax >> of each of these fields and that the I-D detail >> how values of these fields are to be compared. >> Additionally, the I-D should discuss how IDNs >> are to be handled. >> -- Kurt >> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pana-framework-06
If implementability of the specification is an issue, my company has an implementation of bootstrapping 802.11i PSK mode based on running PANA over Uncontrolled Port. The implementation works without modifying a WiFi hardware or its firmware. We have a plan to publish the source code of the implementation in Open Diameter project. Regards, Yoshihiro Ohba On Tue, Mar 21, 2006 at 11:45:25AM -0500, Sam Hartman wrote: > > "Yoshihiro" == Yoshihiro Ohba <[EMAIL PROTECTED]> writes: > > e email discussion over > Yoshihiro> the EAP mailing list quoted below, I had a short > Yoshihiro> conversation on this issue with Jesse Walker during > Yoshihiro> IEEE 802 interim meeting in January in order to > Yoshihiro> follow-up the email discussion and understand the input > Yoshihiro> from Jesse more. As far as I understand, he seemed to > Yoshihiro> agree on this possible interpretation while he > Yoshihiro> mentioned that there is no existing 802.11i > Yoshihiro> implementation that uses 802.1X Uncontrolled Port for > Yoshihiro> non-802.1X frame exchange, but I may be still > Yoshihiro> misunderstanding something. Also, for the sake of > Yoshihiro> completeness of the email discussion over the EAP > Yoshihiro> mailing list, the following email that I sent in > Yoshihiro> response to msg03872 should be quoted as well: > Yoshihiro> http://lists.frascone.com/pipermail/eap/msg03879.html.] > > > So, the implementability of our specifications is a significant > concern. If we do not expect there to be environments in which a > feature of our spec will be implementable, then we should remove that > feature. > > Implementability is sufficiently important that RFC 2026 explicitly > gives the IESG the ability to request an implementation report even > for publication at proposed standard when it has questions about > whether a particular feature can be implemented interoperably. > > --Sam > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Have You Attended 50 or More IETF Meetings?
Susan, Two things. (1) I don't count. But I have been to all or part of every meeting since (and including) Santa Fe, whenever that was. (2) FWIW, many of the people you probably want to reach give very low priority to reading the public IETF list during the IETF week. Volume too high, S/N too low. I'm taking a few minutes now to do queue-clearing, but this is the first time I've touched it since, I think, Monday sometime.If you want to reach people, you need access to the IETF-Announce list. regards, john --On Monday, March 20, 2006 18:06 -0800 Susan Estrada <[EMAIL PROTECTED]> wrote: If you have attended 50 or more IETF meetings, tell me so I can add you to the 50+ list. And, yes, for you doubters out there, some people have attended over 60 IETF meetings (even before there were free t-shirts.) That's dedication. Susan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Have You Attended 50 or More IETF Meetings?
Well I happened to catch this one because it was on the top when opened the folder... Santa Fe was #22. By my count I have been to 51 (10-64 missed:27,28,29). Tony > -Original Message- > From: John C Klensin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 21, 2006 4:34 PM > To: Susan Estrada; ietf@ietf.org > Subject: Re: Have You Attended 50 or More IETF Meetings? > > Susan, > > Two things. > > (1) I don't count. But I have been to all or part of every > meeting since (and including) Santa Fe, whenever that was. > > (2) FWIW, many of the people you probably want to reach give > very low priority to reading the public IETF list during the > IETF week. Volume too high, S/N too low. I'm taking a few > minutes now to do queue-clearing, but this is the first time > I've touched it since, I think, Monday sometime.If you want > to reach people, you need access to the IETF-Announce list. > > regards, > john > > --On Monday, March 20, 2006 18:06 -0800 Susan Estrada > <[EMAIL PROTECTED]> wrote: > > > If you have attended 50 or more IETF meetings, tell me so I > > can add you to the 50+ list. > > > > And, yes, for you doubters out there, some people have > > attended over 60 IETF meetings (even before there were free > > t-shirts.) That's dedication. > > > > Susan > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Pana] Last Call: 'PANA Framework' to Informational RFC
There is a problem with some assertions made in the PANA Framework draft with respect to the operation of 802.11. The specific paragraphs are the following in section 10.2.2, PANA with Bootstrapping WPA/IEEE 802.11i: " This model does not require any change in the current WPA and IEEE 802.11i specifications. This also means that PANA doesn't provide any link-layer security features beyond those already provided for in WPA and IEEE 802.11i. The IEEE 802.11 specification [802.11] allows Class 1 data frames to be received in any state. Also, IEEE 802.11i [802.11i] optionally allows higher-layer data traffic to be received and processed on the IEEE 802.1X Uncontrolled Ports. This feature allows processing IP- based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client authentication." 802.1X does indeed allow the option of additional protocol entities operating over the uncontrolled port. This is described in clause 5.2 of 802.1X-2004. This being an option of 802.1X, it is very likely to be inconsistently implemented. In 802.11i, clause 6.1.4 describes the following: "The IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled or if the MSDU does not represent an IEEE 802.1X frame." This is an additional, more restrictive requirement that goes beyond the 802.1X requirement. This additional requirement of 802.11i would seem to make the operation of any other protocol entity on the uncontrolled port problematic. Finally, the framework claims that data frames are class 1 and available to be sent and received at any time. This is the case only for an independent BSS (ad hoc WLAN), when both the To DS and From DS bits are zero. See 5.5 a) 3) i) in 802.11-1999. In an infrastructure network with an AP, where either the To DS or From DS bit is set to 1, data frames are class 3 and available only after both association and authentication. See 5.5 c) 1). These problems would seem to prevent this bootstrapping mode from operating without requiring changes to 802.11 and/or 802.11i. I would suggest that removal of this section from the draft would resolve these problems. The remaining modes described using 802.11 and 802.11i are not impacted by these problems. -Bob Bob O'Hara Cisco Systems - WNBU ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
Kurt: Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern: This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as SASLprep [SASLPREP]. Russ At 12:19 PM 3/21/2006, Kurt D. Zeilenga wrote: At 11:06 AM 3/21/2006, Stefan Santesson wrote: >Kurt, > >I've spent some time over this topic with Russ Housley and Paul Hoffman >here at the IETF and the conclusion is that we should not specify any >granular encoding or matching rules for the hints. > >The client's use of the name hint requires the client to know its >account name and as such the client will also know in what form the >server needs it. What about character set/encoding? - Kurt >The client should never send the name hint in a way where the server >needs to process it in order to map the hint to an account. > >There reference will be fixed (or removed). > >Stefan Santesson >Program Manager, Standards Liaison >Windows Security > > >> -Original Message- >> From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] >> Sent: den 7 mars 2006 18:35 >> To: ietf@ietf.org >> Subject: draft-santesson-tls-ume Last Call comment >> >> I note the IETF last call was issued for rev. 2. That >> revision no longer exists, hence I reviewed rev. 3. >> >> This document specification of a "User Principal Name", >> I believe, is inadequate. >> >> The I-D indicates that a user_principal_name is a sequence of >> 0 to 65535 bytes in the form of [EMAIL PROTECTED] However, >> such a form implies the value is a character string, >> but there is no mention of what character set/encoding >> is used here. I would think interoperability >> requires both client and server to have a common >> understand of what character set/encoding is to >> be used. Additionally, there is no discussion >> of UPN matching. Are byte sequences that differ >> only due to use of different Unicode normalizations >> to be consider the same or differ? Are values >> case sensitive or not? etc.. >> >> The domain_name field suffers not only from the >> above problem, but is flawed due to use of the >> outdated "preferred name syntax" of RFC 1034. >> This syntax doesn't allow domains such as >> 123.example. The text should likely reference >> the RFC 1123 which updates the "preferred name >> syntax" for naming hosts. >> >> Additionally, no mention of how International >> domain names (IDNs) are to be handled. >> >> I recommend ABNF be used to detail the syntax >> of each of these fields and that the I-D detail >> how values of these fields are to be compared. >> Additionally, the I-D should discuss how IDNs >> are to be handled. >> -- Kurt >> >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
