On Fri, 2004-05-07 at 18:55, Erik Nordmark wrote: > > IMHO a protocol doing this MUST not rely on an external mechanism. > > But later you say that referring to a website for registration is ok. > Perhaps we mean different things by "external mechanism". > > I think it is find to have the tunnel set-up return a > "please register at www.example.com/register" as you suggest, > and that is what I call "external". > > So I suspect we agree on this point. Correct. > I don't know if the "direct" is that useful. You effectively end > up carrying a subset of html when you do this; it is simpler just > to refer to a URL. > (And there might non-technical reasons for an ISP wanting a URL for > registration; they can have banner ads for their ADSL service etc.) Indeed, which is why I also noted that in the message. Most users are able to navigate through a 'register' type site. It is up to the ISP to make it doable and this also 'lightens' the burden on the tool as it doesn't need to be able to do checks of validity and other things which can then be handled in a webstyle method. > One question: > For the [registered user, aka one with an account] you are describing > something that looks like a full authentication exchange, which opens > up the door to questions like "are we encapsulating EAP over the tunnel > setup protocol? or SASL?". > > Do you see this strong authentication as a requirement? > Or do you think it is sufficient to have the registration result in > some "key/tag" where presenting that key/tag in the clear in the tunnel setup > protocol is sufficient? I personally would be more inclined to require a somewhat more strong authentication, thus in the form of SASL at least that the key is not passed in cleartext and that a replay attack can be avoided. I guess that most people will not mind, but if someone has a good argument against doing that, please mention it of course. IMHO the best thing to go is require that a tunnel setup protocol is able to allow multiple styles of authentication and let the deployer pick. Thus that the server announces it's capabilities: - SSL/TLS negotiation so that the complete protocol is crypted (think starttls here just like in SMTP). - Several authentication methods: - cleartext (required) - md5/sha/sasl style (optional but recommended) Advertisements of capabilities should be done in order of strongest to the weakest version. Clients should then pick the first one which it can handle and use that. It would of course be easier to just define one single strong authenticator and a cleartext variant, which may be only available when using SSL/TLS for instance. Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part