Re: dail-up ISP login can't do W3C encoding.
not_at_top-post
Date: 12/25/04
- Next message: David: "Re: Linux drivers for AirPlus DWL-120+ USB Adapter??"
- Previous message: Michael Heiming: "Re: Troubleshooting XP <-> Fedora 2 crossover cable connection."
- Maybe in reply to: not_at_top-post: "dail-up ISP login can't do W3C encoding."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 25 Dec 2004 09:17:59 -0600
not@top-post writes:
> > Persons who know about ppp MUST know about dial-in ISPs.
James Carlson wrote:
> Sure.
>
> > And they know that eg. character "@" can be decoded to %40
> > via some inet convention [RFC standard].
>
> Absolutely.
>
> > The question reduces to:
> > is this decoding available before login.
> > I.e. before the UserID and password have been accepted ?
>
> The question makes no sense to me.
>
> The answer depends entirely on local conventions and what the
> authentication software and ISP chooses to do. It's not at all
> governed by anything in the PPP standards. It's an implementation
> issue.
>
Clearly it's market driven:
consumer/public level ISPs are globally uniformly setup like Macdonalds
for the M$ public. So I'm wrong: they don't use 'text login anymore;
it's ppp from the start ?
>
> In other words, if a vendor of PPP or authentication software wants to
> support such a thing, that's fine. If an ISP wants to deploy it,
> that's also fine. It has nothing to do with what is "available."
>
> (By saying "available," it sounds to me like you're making some sort
> of assumptions about how the software is built internally, and what
> the software can and cannot do. I don't understand those
assumptions.)
I mean the 'capability available to the listener to my telco line'.
Initially the 'listener' [black box abstract] has only the 'capability
available' to understand DTFM dialing. And some where 'along
to chain of capabilities' the 'capability is available' to translate
a 3 octet "%40" to "@". I've been contending that this ability
is not 'available' before login/password.
> > I say no.
> > The sequence is aproximately as follows:
> > 1. ISP modem receives a 'call' & dialogs with the caller in 'plain serial
> > ASCII', with no '%XX encoding' ability.
>
> Actually, that's not quite true on at least three counts:
>
> - Most modern ISPs launch PPP immediately on dial-in. There's no
> plain old ASCII conversation anymore, as such conversations
> require extensive scripting on the caller's side, and are hard (or
> impossible) to support with ordinary Windows users (unfortunately
> the bulk of the clientele).
Well this is my most fundamental mistaken assumption.
> - The existence of any particular encoding ability is merely a
> feature of the software implementation. I can't say I've *ever*
> heard of %XX encoding being used here (or &foo; for that matter),
> but it's certainly not impossible.
BTW where in the 'chain' is %XX encoding implemented ? TCP ?
> - Availability or non-availability of the encoding mechanism is a
> non-issue. If the ISP requires it for some reason, and the PPP
> implementation you're using cannot do it automatically, then
> you'll need to type "user%40realm.net" into that box or
> configuration file instead of "user@realm.net". Otherwise, you'll
> just need to find a new ISP.
Then I'm mistaken: my whole argument has been that the ISP won't
translate '%40' to '@' before login/password. I've hacked the 'dialler'
script to see "user$realm.net" and send "user%40realm.net" to the ISP.
My notebook has [to] have a different version of the software and I
don't want to have to analyse and patch that too.
If translate "%40" -> "@" worked that would be a quick solution;
but on the dialer which was hacked to work, testing by using "%61"
in place of "a" fails to login. I'm really confused !
> In fact, I think that the idea of using %XX encoding inside of peer
> names used for PPP authentication would be particularly crack-headed,
> but my opinion rarely stops others from doing what they please. ;-}
>
> > 2. Only if the UserID and password stage are passed does ppp become
> > enabled. So apparently ppp also doesn't do '%XX encoding'.
>
> This assumption isn't correct.
>
> For most modern ISPs, PPP typically starts immediately. It then
> negotiates LCP (link parameters), and then uses either PAP (simple
> username / password) or CHAP (challenge / response) to authenticate
> the user. The authentication takes place *within* PPP, not outside of
> it.
>
> There are still a few 'unusual' ISPs that require a text-based login
> before starting PPP. They're by far the minority, because it's hard
> to tell a Windows user how to interact with such a thing. (And some
> of those repeat the same authentication in PPP afterwards.)
>
> Even in the cases where text-based login is used, there's nothing that
> prohibits anyone from using %XX if they want to. Again, I've never
> heard of such a thing ever being done for any reason (why on earth
> would you want it?), but that alone doesn't make it impossible.
Yes but would you expect the ISP to translate %XX before login,
if it was one of the old text login systems ?
> > 3. Then an even later stage must do the '%XX encoding' ?
> >
> > Conclusion:
> > the "@" character in the userID or password can't be '%XX encoded'
> > because at that stage the ISP doesn't understand '%XX encoding'.
>
> The conclusion isn't really based on anything useful.
>
> The real issue here is what the authenticator _requires_ the
> authenticatee to do to prove his identity. Authenticators are
> generally free to demand whatever they want of authenticatees. It's
> the authenticatee who is on the hook to provide it (or look elsewhere
> for service).
>
> Let me try to explain this another way, by getting away from the
> apparently hot topic of %XX encoding. Some ISPs today (but not all)
> require users to express their identity as "user@domain.tld".
> Internally, the ISP breaks this apart at the "@" sign, and uses
> "domain.tld" to select a back-end authentication server. This allows
> the ISP to serve multiple populations of users.
>
> RFC 2486 documents that usage, and it's probably a good one, but
> nothing actually _compels_ it. ISPs are free to require what they
> want from their users. Some may ask for just "user", and others may
> ask for a completely different format.
>
> Similarly, ISPs are free to just treat the entire "user@domain.tld" as
> a single token -- not breaking it apart at the "@" sign -- and
> authenticate with a unified database. There's really no way an user
> could tell which of these is done.
>
> Would we assert that the "user@domain.tld" encoding has to be
> "available" (whatever that might mean) at authentication time? No, of
> course not. We merely assert that a user who wants to talk to one of
> those systems configured to use that encoding will need to express his
> identity in those terms. How he accomplishes that (by explicit
> configuration or by some special encoding software) is completely out
> of scope, as it's his problem to solve.
>
> (And what did Oberon have to do with the question ... ?)
The whole problem arose in the oberon-dialer assuming that "@"
would not be used in the username, and using it as the username
string-terminator. When involving third parties in an argument,
it is good form to reveal all parties to each other ?
=========== part 2: I withdraw my admissions above:-
I dug out a DOS ap. from before WIN3.1, ppp, slip - from the days of BBS.
Here's a capture of 2 'login sessions':
----session 1==
CChecking authorization, Please wait...
username:2nm4nx6x@za
password:
cas4-rba> <-- after a delay I pressed <CR>
cas4-rba> <-- after a delay I pressed <CR>
cas4-rba> <-- after a delay I pressed <CR>
cas4-rba> <-- after a delay I pressed <CR>
cas4-rba>ppp <-- after a delay I pressed "ppp"
Entering PPP mode. <-- so ppp comes AFTER 'login' ??!!
Async interface address is unnumbered (FastEthernet0)
Your IP address is 0.0.0.0. MTU is 1500 bytes
~ÿ}#À!}!™} %}"}&} }*} } }#}$À#}%}&WafÇ}'}"}(}"}1}$}%ô}3})}!isd
----------- session 2, %40 failed. Exactly my point ==
username:2nm4nx6x%40za
% username: timeout expired! <--- why did it echo "%" ?
-----------
The only way I could still agree with your argument [and the oberon
users'] is if the ISP operates in 'dual mode':
IF the client 'starts talking ppp'
THEN the ISP replies with ppp;
ELSEIF the client 'starts talking <CR> '
THEN the ISP replies with 'text-mode' until UserName & Password =OK;
afterwhich:switch to ppp & Tx "Entering PPP mode".
The question still remains:
would you expect a 'normal' [designed for Winxx consumer market]
ISP to decode "%40" to "@" as part of the UserId ?
Thanks to anybody who can lay this dog to rest.
== Chris Glur.
- Next message: David: "Re: Linux drivers for AirPlus DWL-120+ USB Adapter??"
- Previous message: Michael Heiming: "Re: Troubleshooting XP <-> Fedora 2 crossover cable connection."
- Maybe in reply to: not_at_top-post: "dail-up ISP login can't do W3C encoding."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
