Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: Paul Fiondella who wrote (28504)	10/7/1999 12:30:00 AM
From: Scott C. Lemon	Read Replies (1) \| Respond to of 42771

Hello Roger Thomas via Paul, I'm glad to get more people involved so that we can flesh out the actual details of the functionality ... and someone from across the pond at that! ;-) > BorderManager and Authentication > > BM does not use MAC addresses as a way to tell nodes apart. I believe that we have discussed the IP address (and I have skipped IPX completely), not the MAC address. > Instead it currently has 2 solutions. Agreed ... > The first is a SSL based login, so creating a session between the > browser and the BM server. So let's take a look at this. We actually mentioned it during our discussion - browser authentication. The "session" that you talk about is first created for the purposes of passing the NDS username and password securely over the net. But once I have done that, BM keeps track of my IP address in order to allow or disallow any subsequent requests. And in reality, the SSL session drops immediately because the sites that I'm going to are probably not SSL. And so they will not include the proper HTTPS:// moniker. There is no persistant connection (by default) in HTTP ... > The second is background with the workstation itself, currently > this works by running an extra programming at the workstation which > validates the workstation by the fact that it has been logged into > an NDS Tree. So I'm not sure if you are referring to the NetWare Client itself, or the "ClientTrust" application, which relies on the NetWare client. In either case, the authentication that occurs is done via a Novell NCP protocol transaction, and then all subsequent Internet protocol requests from the client are verified ... by their source IP address. If you have details that you can provide which explain otherwise please provide them as they would add to the discussion ... > BorderManager (or any firewall) against NAT users. > > Features such as the one above, will allow ISPs to limit the use of > NAT over their connections. I'm sorry, but the methods that you describe above do not provide any such limitations ... unless you are limiting all users (not just the NAT user.) > Via QOS software authenticated sessions will be given higher > priority than non-authenticated sessions. This will removes many of > the advantages of NAT solutions. Since all sessions will appear to orginate from the same client machine, and same IP address, can you please provide more detail on the "clues" that would be utilized to allow such prioritization to be done? > Digitalme security. > > The current level of security means that Novell, can not directly > data mine the details entered by reporting out the contents of its > NDS tree. Hmmmm. I'm not sure that I understand this. Novell (or their servers) are able to retrieve my information to send it to me so that I can see it in my browser. They are even able to retrieve my information to allow you to see it (if I have told them it's ok to do this). So if they can read it to send it to me, and read it to send it to you, why can't they read it to "mine" the data? > Single sign on encripts the data it stores with the users password. This is not the default actions of NDS, although this might be one way to operate. But again, I'm not sure how this could be the case since, if I share the information with you, they are able to read it and send it to you. So they must also have access to my password? I don't think so ... > Of course Novell could code their CGI scripts to log details as > they are accessed (including the password), that comes down to who > you trust. This I will agree with you completely! It all comes down to who you trust .. that is the whole problem, solved. I will always pick and choose who I trust ... Scott C. Lemon