There's no guarantee that I can navigate the USPTO website, but where in this trademark record is it abandoned? I used TESS, the basic search, and entered SSH. Am I missing something here?
Word Mark SSH
Goods and Services IC 009. US 021 023 026 036 038. G & S: computer programs and software for preventing unauthorized access to computer networks and for providing secured connections to computer networks
IC 038. US 100 101 104. G & S: telecommunication services, namely, providing secured telecommunications connections to a global computer network
IC 042. US 100 101. G & S: maintenance and support services for computer programs and software
Mark Drawing Code (5) WORDS, LETTERS, AND/OR NUMBERS IN STYLIZED FORM Serial Number 75150525 Filing Date August 15, 1996
Filed ITU FILED AS ITU Published for Opposition December 16, 1997
Registration Number 2141991 Registration Date March 10, 1998
Owner (REGISTRANT) SSH Communications Security Oy JOINT STOCK COMPANY FINLAND Tekniikantie 12 02150 Espoo FINLAND
Attorney of Record MICHAEL B LASKY
Section 44 Indicator SECT44
Priority Date March 1, 1996 Type of Mark TRADEMARK. SERVICE MARK
Register PRINCIPAL Live/Dead Indicator LIVE
As applied to prohibit DeCSS, the antidevice provision of the DMCA violates the First Amendment. CSS is a device that makes fair and otherwise privileged uses of digitized materials practically impossible. Prohibiting its circumvention in the absolute way that the antidevice provision, as interpreted below, does, would render these materials practically unavailable to the vast majority of users who are not computer geeks. (emphasis mine).
As a side note, is there a legal test for "computer geek?"
A guy hands you a pair of handcuffs, and says "See if you can get out of these." You twist them and break free with a smug grin.
The next day he returns with new pair, and you play the game again.
One day, you find you can't get out of them. And he walks away, leaving you bound and defeated.
Since we're all unfortunately going to have play this game, I propose a new strategy. Fein defeat at every turn. After he has expanded fortunes producing similar handcuffs for everyone else, divulge the weakness. If he persists in this game, bankrupt him.
Additionally, if the RIAA and MPAA cannot find technological measures to protect their interests, I believe that they will increasingly rely on congress. It would be a grave mistake to assume that we have better access to our congressmen than they do.
However, while the industry's resources may be vast, they are not infinite. Senators *can* be expensive, and prices do fluctuate. Hypothetically, they have to buy off a majority. After rounds three and four, after vendors are expending their own R&D budgets to comply with laws and customers/constituents are wailing, these congressmen will be considerably more expensive. Let's make certain that the cuffs are still quite loose at this point, or it will be close game.
Yes. You are correct. The Gnu Free Document License is the more appropriate license. My mistake.
As mentioned in a prior post above, this document is a starting point. If it cannot be legally migrated to the GFDL, then a new, more comprehensive document can be written using this as a foundation.
It is been accurately pointed out that the GPL is not the correct license for this type of distribution. My fault for not paying better attention; I write more code than specifications. That said however, if this ever becomes a problem, there are at least two obvious solutions. 1) if there is a legal migration to the GFDL, then use it; otherwise 2) use it as the basis for a properly GFDL'd specification.
This spec is the starting point for a more comprehensive solution. Certain details have been left out on purpose so that the authors of the new spec must parse the data from the server to understand certain data types. This will happen normally in the course of implementing the spec anyway.
(1) The information can no longer be assumed to be a trade secret. (2) It's not patented. (3) The Microsoft document is copyrighted, but the information can be disseminated in any way other than their document.
Solution: Rewrite the document
Like this: http://www.thetop.net/kerbos/spec.html I've got a message posted below, but it's buried too deep to get moderated up. Hopefully, it can see some light up here.
So far, over 100 hits since I posted two hours ago. The server wouldn't mind a couple thousand... it's bored out of its skull anyway.
Yes, it's real. Anyone who can initiate Kerbos transactions within a development environment should be able to reverse-engineer the MS spec using this information.
As usual, I'm late to the party, so it may never get mod'd up, but that's the way it is. I don't read Slashdot every day; I posted it primarily for posterity.
Now that the cat is out of the bag, I believe the best way to move forward on this is to release a new spec. Read on...
MS W2K Kerbos V5 Authorization Fields
1.0 PREAMBLE - READ THIS NOW This document is a compilation of information posted publicly on the internet. The author has not entered into any agreement with Microsoft regarding non-disclosure of this specification, nor bypassed any copyright protections, nor reverse-engineered the protocol.
1.1 INTENT The author intends for this document to assist in the reverse-engineering of the protocol by describing the fields necessary to interoperate between UNIX and W2K server implementations of the Kerbos V5 specification. The author will not maintain this document, therefore it is requested that the relevent interested parties host, maintain, and correct this document as reference for future work, without being tainted by the MS EULA.
1.2 LICENSE This document is licensed under the GNU Public License. See www.gnu.org for details.
1.3 FURTHER READING http://www.ietf.org/internet-drafts/draft-ietf-c at-kerberos-revisions-05.txt http://www.ietf.org/internet-drafts/draft-ietf-c at-kerberos-pk-init-11.txt
1.4 REPRESENTATION All symbolic names have been changed. The data representation has been changed. Any derived work will not violate MS copyright in this regard.
1.5 PREREQUISTES Reader should have knowledge of MS API, particularly FILETIME, UNICODE, and SIDs. Reader should be familiar with NDR encoding and the Kerbos V5 specification.
2.0 SPECIFICATION Microsoft has produced an extension to the Kerbos spec called PAC (Privilege Attribute Certificate) which includes proprietary information in the ticket authorization field, specifically the IF-RELEVANT field with a sub-identifier of 128.
2.0.1 FORMAT All data is in low endian format. Most data is in NDR format, a stream- based serialization of structures and arrays. Sometimes this data is encrypted. There are not many keys to deal with so some experimentation should yield good results.
2.1 PAC STRUCTURE
DWORD toc_count ; number of items in the TOC (table of ; contents) DWORD pac_version ; version number for this specification, ; currently 0 TOCITEM toc_items[toc_count] ; array of TOC items BYTE raw_data[...] ; raw data corresponding to items in TOC, ; all items are aligned to 8 bytes
2.1.1 TOCITEM
DWORD item_type ; the type of the item in the data portion DWORD item_length ; the number of bytes in the item QWORD item_offset ; 64bit offset from the beginning of the PAC ; structure to the raw data corresponding to ; this item. least significant three bits ; MUST BE ZERO. isn't this a bit large for ; network traffic?
TIMESTAMP login_time ; last login time TIMESTAMP expire_time ; session expiration time or TIME_NA if n/a TIMESTAMP forced_time ; forced session expiration time or TIME_NA ; if n/a TIMESTAMP passwd_mtime ; last password modification time or 0 if not ; set TIMESTAMP passwd_min_time; time afterwhich password may be changed TIMESTAMP passwd_max_time; time afterwhich password must be changed or ; TIME_NA USTRING username ; (optional) the W2K user name USTRING userdesc ; (optional) the W2K descriptive user name USTRING script_path ; (optional) the user login script path USTRING profile_path ; (optional) the user profile path USTRING homedir_path ; (optional) the user home directory USTRING homedir_drv ; (optional) the user home directory drive ; mapping in the event of a UNC home directory WORD session_cnt ; (ignore) the number of sessions the user ; currently maintains WORD badpasswd_cnt ; number of bad authentication attempts since ; last successful authentication DWORD uid ; relative user id DWORD gid ; relative primary group id DWORD gid_cnt ; number of additional groups GIDATTRIB moregids[gid_cnt] ; array of relative gids and attributes DWORD flags ; determines the validity of the following ; fields: 0x0020= extra_sid* info is present, ; 0x0200= resgrp* info is present DWORD ignore1[4] ; (ignore) USTRING nb_server ; netbios name for KDC that requested AS USTRING nb_domain ; netbios name for user's domain SID sid_domain ; sid for user's domain, base for relative ids DWORD ignore2[2] ; (ignore) DWORD userflags ; tons of flags (see uf_* below) DWORD ignore3[7] ; (ignore) DWORD extra_sid_cnt ; number of sids to follow, see flags SIDATTRIB extra_sids[extra_sid_cnt] ; more sids, see flags SID resgrp_sid_domain ; sid for resource domain, base for relative ; ids below DWORD resgrp_gid_cnt ; number of groups to follow, see flags GIDATTRIB resgrp_gids[resgrp_sid_cnt] ; more relative gids and ; attributes, see flags
2.2.1 TIMESTAMP
QWORD time ; 64 bit value of 100nsec increments from ; 1601-01-01 GMT epoch
TIME_NA = 0x7FFFFFFFFFFFFFFF
2.2.2 USTRING
WORD size ; number of bytes in the unicode string, ; length is size/2 WORD max ; number of bytes in the buffer WORD buf[max/2] ; array of unicode characters
2.2.3 GIDATTRIB
DWORD id ; relative id DWORD attrib ; attributes (0x1=required, ; 0x2=enabled_by_default, 0x4=enabled)
2.2.4 SID
BYTE version ; version number BYTE agent_cnt ; number of authorizing agents, max 15 SIDPREFIX prefix ; the sid prefix DWORD agent[agent_cnt] ; array of authorizing agents
2.2.5 SIDPREFIX
BYTE b[6] ; array of six bytes, presumably ; S-5-a-b-c-d SID prefix
BTW, NT authority's SID is 0,0,0,0,0,5; note the unusual byte order
2.3 SUPPLEMENTAL - additional information may be sent by the KDC depending on the security package, but this only pertains to PKINIT packets. I good deal of encryption goes on here as well. The data itself is encrypted with the client key, but also appears to be NDR encoded and encrypted with the KDC->client key as well. Some experimentation should resolve this once and for all. Be wary that multiple levels of NDR encoding may be present.
2.3.1 SUPPLEMENTAL HEADER (NDR encoded and encrypted with KDC->client key)
DWORD crypt_ver ; version number of key if encrypted, ; 0 otherwise DWORD crypt_type ; type of cryptography (see Kerbos types) BYTE raw[...] ; the raw data is an NDR encoded CREDARRAY ; below (size in TOC entry)
2.3.2 CREDARRAY (NDR encoded)
DWORD cnt ; number of credentials CREDS creds[cnt] ; credentials (NDR encoded again)
2.3.3 CREDS (NDR encoded)
USTRING pckg_name ; name of package DWORD size ; number of bytes in opaque data BYTE opaque[size] ; array of bytes comprising opaque data
2.4 SIGNATURES
DWORD sig_type ; type of signature (keyed checksum only) BYTE sig[...] ; raw signature data (size in TOC entry)
FYI: signing of PAC is performed as follows: 1. PAC is generated with both signatures zeroed out 2. Signature is run on PAC with server key and stored in server entry 3. Signature is run on PAC with KDC key and stored in KDC entry
2.5 USER NAME - helps resolve that the PAC applies to the correct user
TIMESTAMP timestamp ; ticket AuthTime field in timestamp format WORD size ; size of username in bytes, length is size/2 WORD name[size] ; array of unicode characters comprising ; username delimited with / and @, NOT ; TERMINATED
2.6 REQUEST PREAUTH DATA - PACS occur in conjuction with AS and TGS requests, but they can be requested on demand or suppressed with a PAC-REQUEST. The format is a mere BOOLEAN value. If the PAC is not present and the value is true, it is included. If the PAC is present and the value is false, it is omitted. The ID for this request is called KRB5_PADATA_PAC_REQUEST and has a value of 128.
Frankly, having access to the source code for everything running on my machine has allowed me to sleep very well at nights. Running applications that cannot be audited- especially applications from Microsoft- does not.
I have been writing applications for MS platforms since day one. Until October 1999, NT COM, ATL, and MFC were my breakfast, lunch, and dinner.
However, over the last three years of this project, NT has became so difficult to maintain and develop for, that my team was collectively forced to give up on MS altogether. For linking reasons, our legacy code had to be recompiled and redeployed for every new release of the MFC, DLL mismatches at client sites alone ate our technical support to death, our development machines had a 3 month lifespan between total reinstalls. Why? Because Microsoft was constantly screwing around with the architecture of MFC, the configurations of our machines, etc. Need that new feature? You must install Service Pack X. Oops, sorry about that registry entry. You didn't need it anyway.
Having found Linux, I for one, am in programmer's paradise. I have no interest in running Microsoft code anywhere except in VMWare under Linux with the network bound to the host machine. That way, I know that MS software can't chat with Redmond without my permission, and if the NT installation blows itself up, I can cleanup afterwards with 'rm -rf vmware/nt' and laugh heartily to myself that I finally managed to get the tiger into the cage.
Funny you should mention it. I've been using NTFS for as long as it's been available and until yesterday, I'd never lost any data.
My assistant turned off the scanner on the scsi bus and not seconds later, the machine BSOD'd. Haven't seen one of those in at least a month. (Before people get on my case, the scanner is not on the same bus as the hard drives.) After rebooting, we were completely unable to access our development drive because of... a permissions problem. Hmmm. A little bit of investigation and the problem was discovered- the security descriptors for every directory from the root of the drive all the way down to the working directory were corrupted. As we discovered this afternoon, any directory on the volume that we had accessed for writing in the last two weeks was similarly toasted. In the end, we ate the week's loss of data and restored from backup.
If NTFS as deployed on NT4.0 was a journaling filesystem, I suspect that we would have gotten through unscathed; however, contrary to most speculation, journaling appears to be a feature of NT5.0. MSJ recently did a two part article on it hoping that developers would fall in love and start incorporating its features into new software. NTFS has better checks than say FAT, but it's certainly not the robust powerhouse that Malor has made it out to be.
By the end of the day, I was struck with the idea that maybe I should put my scanner on the UPS just to keep NT happy/afloat?
Microsoft states that in order to reduce costs and expedite deployment of cryptographic modules, they implemented two keys in the event that their primary was lost. This rational is strictly invalidated by their principle means of distributing system updates, the service-pack dependency.
...Microsoft would need to sign future CSPs using a new key. In order for these CSPs to be verified, matching key material would need to be provided to all of the millions of customers using Windows 95, 98, and Windows NT. Clearly this would be a massive undertaking. This is why there are two keys. - Microsoft
Deployment of a new key is trivial for Microsoft. They have demonstrated the capability to distribute sweeping changes to their operating system through the use of service-packs. Moreover, they have forced the installation of these service-packs through widespread use of software dependencies. One version of Microsoft Developer Studio, for instance, required not only the installation of SP3 under NT, but IE4 as well. A reasonable administrator accepts that software dependencies exist and expects to upgrade libraries to take advantage of new features; however, it would be absurd to argue that Microsoft is only casually aware of the power it exercises in this matter.
At any point in time, Microsoft can replace or update the CryptoAPI by requiring all newly-signed cryptographic modules to first install the appropriate service-pack. This circumstance is so routine for administrators that it could hardly be considered an exceptional solution.
Whether the NSA holds any of Microsoft's private keys may never be known. Why Microsoft implemented two keys is anyone's speculation. One thing is for certain however, Microsoft's statement that deployment costs alone governed that decision does not stand to reason. Microsoft deploys what it wants, when it wants, and achieves widespread adoption.
Slashdot Mirror
There's no guarantee that I can navigate the USPTO website, but where in this trademark record is it abandoned? I used TESS, the basic search, and entered SSH. Am I missing something here?
Word Mark SSH
Goods and Services IC 009. US 021 023 026 036 038. G & S: computer programs and software for preventing unauthorized access to computer networks and for providing secured connections to computer networks
IC 038. US 100 101 104. G & S: telecommunication services, namely, providing secured telecommunications connections to a global computer network
IC 042. US 100 101. G & S: maintenance and support services for computer programs and software
Mark Drawing Code (5) WORDS, LETTERS, AND/OR NUMBERS IN STYLIZED FORM
Serial Number 75150525
Filing Date August 15, 1996
Filed ITU FILED AS ITU
Published for Opposition December 16, 1997
Registration Number 2141991
Registration Date March 10, 1998
Owner (REGISTRANT) SSH Communications Security Oy JOINT STOCK COMPANY FINLAND Tekniikantie 12 02150 Espoo FINLAND
Attorney of Record MICHAEL B LASKY
Section 44 Indicator SECT44
Priority Date March 1, 1996
Type of Mark TRADEMARK. SERVICE MARK
Register PRINCIPAL
Live/Dead Indicator LIVE
From Profs. Benkler & Lessig Amici Brief in "MPAA v. 2600" Case
As applied to prohibit DeCSS, the antidevice provision of the DMCA violates the First Amendment. CSS is a device that makes fair and otherwise privileged uses of digitized materials practically impossible. Prohibiting its circumvention in the absolute way that the antidevice provision, as interpreted below, does, would render these materials practically unavailable to the vast majority of users who are not computer geeks. (emphasis mine).
As a side note, is there a legal test for "computer geek?"
A guy hands you a pair of handcuffs, and says "See if you can get out of these." You twist them and break free with a smug grin.
The next day he returns with new pair, and you play the game again.
One day, you find you can't get out of them. And he walks away, leaving you bound and defeated.
Since we're all unfortunately going to have play this game, I propose a new strategy. Fein defeat at every turn. After he has expanded fortunes producing similar handcuffs for everyone else, divulge the weakness. If he persists in this game, bankrupt him.
Additionally, if the RIAA and MPAA cannot find technological measures to protect their interests, I believe that they will increasingly rely on congress. It would be a grave mistake to assume that we have better access to our congressmen than they do.
However, while the industry's resources may be vast, they are not infinite. Senators *can* be expensive, and prices do fluctuate. Hypothetically, they have to buy off a majority. After rounds three and four, after vendors are expending their own R&D budgets to comply with laws and customers/constituents are wailing, these congressmen will be considerably more expensive. Let's make certain that the cuffs are still quite loose at this point, or it will be close game.
-Hope
Yes. You are correct. The Gnu Free Document License is the more appropriate license. My mistake.
As mentioned in a prior post above, this document is a starting point. If it cannot be legally migrated to the GFDL, then a new, more comprehensive document can be written using this as a foundation.
-Hope
It is been accurately pointed out that the GPL is not the correct license for this type of distribution. My fault for not paying better attention; I write more code than specifications. That said however, if this ever becomes a problem, there are at least two obvious solutions. 1) if there is a legal migration to the GFDL, then use it; otherwise 2) use it as the basis for a properly GFDL'd specification.
This spec is the starting point for a more comprehensive solution. Certain details have been left out on purpose so that the authors of the new spec must parse the data from the server to understand certain data types. This will happen normally in the course of implementing the spec anyway.
-Hope
(1) The information can no longer be assumed to be a trade secret.
(2) It's not patented.
(3) The Microsoft document is copyrighted, but the information can be disseminated in any way other than their document.
Solution: Rewrite the document
Like this: http://www.thetop.net/kerbos/spec.html
I've got a message posted below, but it's buried too deep to get moderated up. Hopefully, it can see some light up here.
So far, over 100 hits since I posted two hours ago. The server wouldn't mind a couple thousand... it's bored out of its skull anyway.
-Hope
Just hit 100 page requests. Now if someone would moderate this up, maybe it'll get some serious play.
This is the MS Kerbos Spec WITHOUT the MS copyright, EULA, or trade secret issues. It has been rewritten from scratch and GPL'd.
-Hope
Given that there is a GPL'd document published that does not have the Microsoft restrictions, I wonder where they stand legally now?
I published this on Friday, but here it is again. Maybe it'll get moderated up this time.
http://www.thetop.net/kerbos/spec.html
http://www.thetop.net/kerbos/spec.txt
Good luck!
-Hope
And here it is in HTML...
Microsoft Kerbos V5 Authentication Specification in HTML
-Hope
Here's a link to the document... http://www.thetop.net/kerbos/spec.txt -Hope
Yes, it's real. Anyone who can initiate Kerbos transactions within a development environment should be able to reverse-engineer the MS spec using this information.
As usual, I'm late to the party, so it may never get mod'd up, but that's the way it is. I don't read Slashdot every day; I posted it primarily for posterity.
-Hope
Now that the cat is out of the bag, I believe the best way to move forward on this is to release a new spec. Read on...
c at-kerberos-revisions-05.txt c at-kerberos-pk-init-11.txt
n t,extra_sids,
MS W2K Kerbos V5 Authorization Fields
1.0 PREAMBLE - READ THIS NOW
This document is a compilation of information posted publicly on the
internet. The author has not entered into any agreement with Microsoft
regarding non-disclosure of this specification, nor bypassed any copyright
protections, nor reverse-engineered the protocol.
1.1 INTENT
The author intends for this document to assist in the reverse-engineering
of the protocol by describing the fields necessary to interoperate between
UNIX and W2K server implementations of the Kerbos V5 specification. The
author will not maintain this document, therefore it is requested that the
relevent interested parties host, maintain, and correct this document as
reference for future work, without being tainted by the MS EULA.
1.2 LICENSE
This document is licensed under the GNU Public License. See www.gnu.org
for details.
1.3 FURTHER READING
http://www.ietf.org/internet-drafts/draft-ietf-
http://www.ietf.org/internet-drafts/draft-ietf-
1.4 REPRESENTATION
All symbolic names have been changed. The data representation has been
changed. Any derived work will not violate MS copyright in this regard.
1.5 PREREQUISTES
Reader should have knowledge of MS API, particularly FILETIME, UNICODE,
and SIDs. Reader should be familiar with NDR encoding and the Kerbos V5
specification.
2.0 SPECIFICATION
Microsoft has produced an extension to the Kerbos spec called PAC
(Privilege Attribute Certificate) which includes proprietary information
in the ticket authorization field, specifically the IF-RELEVANT field
with a sub-identifier of 128.
2.0.1 FORMAT
All data is in low endian format. Most data is in NDR format, a stream-
based serialization of structures and arrays. Sometimes this data is
encrypted. There are not many keys to deal with so some experimentation
should yield good results.
2.1 PAC STRUCTURE
DWORD toc_count ; number of items in the TOC (table of
; contents)
DWORD pac_version ; version number for this specification,
; currently 0
TOCITEM toc_items[toc_count] ; array of TOC items
BYTE raw_data[...] ; raw data corresponding to items in TOC,
; all items are aligned to 8 bytes
2.1.1 TOCITEM
DWORD item_type ; the type of the item in the data portion
DWORD item_length ; the number of bytes in the item
QWORD item_offset ; 64bit offset from the beginning of the PAC
; structure to the raw data corresponding to
; this item. least significant three bits
; MUST BE ZERO. isn't this a bit large for
; network traffic?
item_type may be one the following values:
item_login = 1 ; item contains client credentials (2.2)
item_supplemental = 2 ; item contains supplemental credentials (2.3)
item_server_sig = 6 ; item contains server signature (2.4)
item_kdc_sig = 7 ; item contains kdc signature (2.4)
item_user_name = 10 ; item contains the username (2.5)
2.2 LOGIN information (NDR encoded)
TIMESTAMP login_time ; last login time
TIMESTAMP expire_time ; session expiration time or TIME_NA if n/a
TIMESTAMP forced_time ; forced session expiration time or TIME_NA
; if n/a
TIMESTAMP passwd_mtime ; last password modification time or 0 if not
; set
TIMESTAMP passwd_min_time; time afterwhich password may be changed
TIMESTAMP passwd_max_time; time afterwhich password must be changed or
; TIME_NA
USTRING username ; (optional) the W2K user name
USTRING userdesc ; (optional) the W2K descriptive user name
USTRING script_path ; (optional) the user login script path
USTRING profile_path ; (optional) the user profile path
USTRING homedir_path ; (optional) the user home directory
USTRING homedir_drv ; (optional) the user home directory drive
; mapping in the event of a UNC home directory
WORD session_cnt ; (ignore) the number of sessions the user
; currently maintains
WORD badpasswd_cnt ; number of bad authentication attempts since
; last successful authentication
DWORD uid ; relative user id
DWORD gid ; relative primary group id
DWORD gid_cnt ; number of additional groups
GIDATTRIB moregids[gid_cnt] ; array of relative gids and attributes
DWORD flags ; determines the validity of the following
; fields: 0x0020= extra_sid* info is present,
; 0x0200= resgrp* info is present
DWORD ignore1[4] ; (ignore)
USTRING nb_server ; netbios name for KDC that requested AS
USTRING nb_domain ; netbios name for user's domain
SID sid_domain ; sid for user's domain, base for relative ids
DWORD ignore2[2] ; (ignore)
DWORD userflags ; tons of flags (see uf_* below)
DWORD ignore3[7] ; (ignore)
DWORD extra_sid_cnt ; number of sids to follow, see flags
SIDATTRIB extra_sids[extra_sid_cnt] ; more sids, see flags
SID resgrp_sid_domain ; sid for resource domain, base for relative
; ids below
DWORD resgrp_gid_cnt ; number of groups to follow, see flags
GIDATTRIB resgrp_gids[resgrp_sid_cnt] ; more relative gids and
; attributes, see flags
2.2.1 TIMESTAMP
QWORD time ; 64 bit value of 100nsec increments from
; 1601-01-01 GMT epoch
TIME_NA = 0x7FFFFFFFFFFFFFFF
2.2.2 USTRING
WORD size ; number of bytes in the unicode string,
; length is size/2
WORD max ; number of bytes in the buffer
WORD buf[max/2] ; array of unicode characters
2.2.3 GIDATTRIB
DWORD id ; relative id
DWORD attrib ; attributes (0x1=required,
; 0x2=enabled_by_default, 0x4=enabled)
2.2.4 SID
BYTE version ; version number
BYTE agent_cnt ; number of authorizing agents, max 15
SIDPREFIX prefix ; the sid prefix
DWORD agent[agent_cnt] ; array of authorizing agents
2.2.5 SIDPREFIX
BYTE b[6] ; array of six bytes, presumably
; S-5-a-b-c-d SID prefix
BTW, NT authority's SID is 0,0,0,0,0,5; note the unusual byte order
2.2.6 SIDATTRIB
SID sid ; sid
DWORD attrib ; attributes (0x1=required,
; 0x2=enabled_by_default, 0x4=enabled)
2.2.7 userflag VALUES
uf_disabled = 0x00001 ; account disabled
uf_directory = 0x00002 ; home directory is required
uf_nopasswd = 0x00004 ; password not necessary
uf_tmpdup = 0x00008 ; account is a temporary duplicate
uf_normal = 0x00010 ; normal account
uf_mnslogin = 0x00020 ; mns login account
uf_domaintrust = 0x00040 ; domain-wide trust account
uf_hosttrust = 0x00080 ; host-wide trust account
uf_servertrust = 0x00100 ; server-wide trust account
uf_noexpire = 0x00200 ; password does not expire
uf_autolock = 0x00400 ; account is autolocked
uf_encrypt = 0x00800 ; encrypted password is valid
uf_smartcard = 0x01000 ; smartcard is required
uf_delegate = 0x02000 ; delegate trust account
uf_notdelegated = 0x04000 ; not currently delegated
uf_desonly = 0x08000 ; only des key is valid
uf_nopreauth = 0x10000 ; do not require pre-authentication
2.2.8 NT TOKEN - is apparently generated from the following fields
uid,gid_cnt,moregids,flags,sid_domain,extra_sid_c
resgrp_gid_cnt,resgrp_sid_domain,resgrp_gids
2.3 SUPPLEMENTAL - additional information may be sent by the KDC
depending on the security package, but this only pertains to PKINIT
packets. I good deal of encryption goes on here as well. The data
itself is encrypted with the client key, but also appears to be NDR
encoded and encrypted with the KDC->client key as well. Some
experimentation should resolve this once and for all. Be wary that
multiple levels of NDR encoding may be present.
2.3.1 SUPPLEMENTAL HEADER (NDR encoded and encrypted with KDC->client
key)
DWORD crypt_ver ; version number of key if encrypted,
; 0 otherwise
DWORD crypt_type ; type of cryptography (see Kerbos types)
BYTE raw[...] ; the raw data is an NDR encoded CREDARRAY
; below (size in TOC entry)
2.3.2 CREDARRAY (NDR encoded)
DWORD cnt ; number of credentials
CREDS creds[cnt] ; credentials (NDR encoded again)
2.3.3 CREDS (NDR encoded)
USTRING pckg_name ; name of package
DWORD size ; number of bytes in opaque data
BYTE opaque[size] ; array of bytes comprising opaque data
2.4 SIGNATURES
DWORD sig_type ; type of signature (keyed checksum only)
BYTE sig[...] ; raw signature data (size in TOC entry)
FYI: signing of PAC is performed as follows:
1. PAC is generated with both signatures zeroed out
2. Signature is run on PAC with server key and stored in server
entry
3. Signature is run on PAC with KDC key and stored in KDC entry
2.5 USER NAME - helps resolve that the PAC applies to the correct user
TIMESTAMP timestamp ; ticket AuthTime field in timestamp format
WORD size ; size of username in bytes, length is size/2
WORD name[size] ; array of unicode characters comprising
; username delimited with / and @, NOT
; TERMINATED
2.6 REQUEST PREAUTH DATA - PACS occur in conjuction with AS and
TGS requests, but they can be requested on demand or suppressed
with a PAC-REQUEST. The format is a mere BOOLEAN value. If the
PAC is not present and the value is true, it is included. If the
PAC is present and the value is false, it is omitted. The ID for
this request is called KRB5_PADATA_PAC_REQUEST and has a value of
128.
Frankly, having access to the source code for everything running on my machine has allowed me to sleep very well at nights. Running applications that cannot be audited- especially applications from Microsoft- does not.
I have been writing applications for MS platforms since day one. Until October 1999, NT COM, ATL, and MFC were my breakfast, lunch, and dinner.
However, over the last three years of this project, NT has became so difficult to maintain and develop for, that my team was collectively forced to give up on MS altogether. For linking reasons, our legacy code had to be recompiled and redeployed for every new release of the MFC, DLL mismatches at client sites alone ate our technical support to death, our development machines had a 3 month lifespan between total reinstalls. Why? Because Microsoft was constantly screwing around with the architecture of MFC, the configurations of our machines, etc. Need that new feature? You must install Service Pack X. Oops, sorry about that registry entry. You didn't need it anyway.
Having found Linux, I for one, am in programmer's paradise. I have no interest in running Microsoft code anywhere except in VMWare under Linux with the network bound to the host machine. That way, I know that MS software can't chat with Redmond without my permission, and if the NT installation blows itself up, I can cleanup afterwards with 'rm -rf vmware/nt' and laugh heartily to myself that I finally managed to get the tiger into the cage.
Hope to see you here someday,
-HopeOS
Funny you should mention it. I've been using NTFS for as long as it's been available and until yesterday, I'd never lost any data.
My assistant turned off the scanner on the scsi bus and not seconds later, the machine BSOD'd. Haven't seen one of those in at least a month. (Before people get on my case, the scanner is not on the same bus as the hard drives.) After rebooting, we were completely unable to access our development drive because of... a permissions problem. Hmmm. A little bit of investigation and the problem was discovered- the security descriptors for every directory from the root of the drive all the way down to the working directory were corrupted. As we discovered this afternoon, any directory on the volume that we had accessed for writing in the last two weeks was similarly toasted. In the end, we ate the week's loss of data and restored from backup.
If NTFS as deployed on NT4.0 was a journaling filesystem, I suspect that we would have gotten through unscathed; however, contrary to most speculation, journaling appears to be a feature of NT5.0. MSJ recently did a two part article on it hoping that developers would fall in love and start incorporating its features into new software. NTFS has better checks than say FAT, but it's certainly not the robust powerhouse that Malor has made it out to be.
By the end of the day, I was struck with the idea that maybe I should put my scanner on the UPS just to keep NT happy/afloat?
-Hope
Microsoft states that in order to reduce costs and expedite deployment of cryptographic modules, they implemented two keys in the event that their primary was lost. This rational is strictly invalidated by their principle means of distributing system updates, the service-pack dependency.
Deployment of a new key is trivial for Microsoft. They have demonstrated the capability to distribute sweeping changes to their operating system through the use of service-packs. Moreover, they have forced the installation of these service-packs through widespread use of software dependencies. One version of Microsoft Developer Studio, for instance, required not only the installation of SP3 under NT, but IE4 as well. A reasonable administrator accepts that software dependencies exist and expects to upgrade libraries to take advantage of new features; however, it would be absurd to argue that Microsoft is only casually aware of the power it exercises in this matter.
At any point in time, Microsoft can replace or update the CryptoAPI by requiring all newly-signed cryptographic modules to first install the appropriate service-pack. This circumstance is so routine for administrators that it could hardly be considered an exceptional solution.
Whether the NSA holds any of Microsoft's private keys may never be known. Why Microsoft implemented two keys is anyone's speculation. One thing is for certain however, Microsoft's statement that deployment costs alone governed that decision does not stand to reason. Microsoft deploys what it wants, when it wants, and achieves widespread adoption.
John Joganic
The J. Arkadia Corporation