<br><br><div><span class="gmail_quote">On 5/8/06, <b class="gmail_sendername">Manlio Perillo</b> <<a href="mailto:manlio_perillo@libero.it">manlio_perillo@libero.it</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
jarrod roberson ha scritto:<br>> [...]<br>> I simply have seen an UDP protocol that uses sessions to identify each<br>> request.<br>> The session is obtained after an authentication phase.<br>><br>
><br>> if the sesssion id never changes I am SURE you have seen an insecure UDP<br>> protocol<br><br>Of course, as the 90% of internet (as far as I have seen)..<br><br>> which means unless the client and server are generating dynamic single
<br>> use tokens and "know" what the next valid session id the client should<br>> send, which implies encryption plus authenticaiton on every request.<br>><br>> Since I think that the procedure is similar to HTTP session handling, I
<br>> was asking if there is some reusable support for creating "secure"<br>> session id and if cred has some support for this.<br>><br>><br>><br>> you still don't understand STATE != Authentication.
<br>><br>> ANYONE can sniff the packets, get whatever token or breadcrumb you are<br>> using for the state id and spoof it.<br>> that is unless you REQUIRE authentication on every request. "secure"<br>
> session id's imply a form of authenticaiton on every request.<br>><br><br>Ok, but this implies (with simple authentication scheme like HTTP) to<br>double the number of requests/reponses.<br><br>And what if the authentication protocol is more complex?
<br><br></blockquote></div><br>you can send "premetive" authentication in the REQUEST headers<br>