Table of contents
- Documentation
- The Authentication and Ticket acquisition process
- Setting up Kerberos
- Network Packet Dumps
Kerberos is not trivial. This tutorial is aimed at three groups:
- those who want to understand Kerberos at a high level — just look at the pretty pictures ;-)
- those who have to set up Kerberos
- those unlucky enough to have to debug Kerberos down to the network packet level.
There are other documents out there, but my head hurt after reading pages of sentences like:
| TGS_REP is the reply of the Ticket Granting Server to the previous request. Located inside is the requested service ticket (encrypted with the secret key of the service) and a service session key generated by TGS and encrypted using the previous session key generated by the AS. |
Documentation
- RFCs
- Sun Administration Documents
- http://www.kerberos.org/software/tutorial.html
The Authentication and Ticket acquisition process
- Ticket
- An authorisation to do something.
- Ticket Granting Ticket (TGT)
- An initial Ticket that confirms to the Realm that you have provided adequate proof of who you claim to be. The actual ticket name is typically
- Realm
- (Designated R below.) An administrative grouping for network services, that typically (but not always) coincides with a network domain or sub-domain (eg dfusion.com.au). Realms are often named the same as the domain but in UPPER CASE (eg DFUSION.COM.AU) (mostly for sanity in troubleshooting AFAIK, although som software seems to assume/enforce upper case).
- Authentication Service (AS)
- The service that confirms a user's identity.
- Ticket Granting Service (TGS)
- The service that hands out the TGT once authentication is complete.
Kerberos process in a nutshell
Although the process looks complex, well it is complex, the request/reply pairs (AS: 1 and 2) , (TGS: 3 and 4) are actually very similar, their function is to obtain Tickets. In the first case the Ticket is the master ticket (TGT), in the second it is a ticket for the right-to-use a specific service (eg nfs). The third transaction (AP:5 and 6) is to initiate the required service. Simple!
Although the process looks complex, well it is complex, the request/reply pairs (AS: 1 and 2) , (TGS: 3 and 4) are actually very similar, their function is to obtain Tickets. In the first case the Ticket is the master ticket (TGT), in the second it is a ticket for the right-to-use a specific service (eg nfs). The third transaction (AP:5 and 6) is to initiate the required service. Simple!
The numbers here match those in the diagram.
- A user initiates the Kerberos authentication client either by logging in to an appropriately configured client machine or by explicitly using a Kerberos client application like "kinit". The user provides their Kerberos username and password and asks to be authenticated for a particular Kerberos Realm (R). kinit sends this initial request (AS_REQ) to the Authentication Service (AS) (Note 0).
- The Authentication Service (AS) looks up the user in its
database (or it can connect to LDAP). If user is valid the AS generates a
random session encryption key (Notes 1,2). The session key (GREEN) is
encrypted with the user's password (BLUE) (kept in an encrypted database
- KDB) and then sent back to the user along with an "Authenticated
User" pass, called the Ticket Granting Ticket (TGT) (YELLOW) (Note 3)
that is used to get access to other services. It works on the principle
of authenticate once, then trust the user in the local realm for the
next few hours at least.
If the user is who they claim to be then the BLUE password they entered at the client will decrypt the GREEN session key (encrypted with their BLUE password). This means both Client and KDC now both have a shared secret session key and can pass secured data to each other without fear of evesdroppers. Note the password stays within kinit and is NEVER transmitted across the network during a normal Kerberos session.
The Kerberos authentication process is now complete. The user has a TGT (may be shown as krbtgt/R@R where R is the realm, eg DFUSION.COM.AU).
- The user now wants to access a Kerberised service like nfs (eg to mount a Kerberos secured NFS share). The mount client sends a TGS_REQ request asking for access to the service (eg "nfs/hostS.domain@R" for the nfs service on hostS in realm R) (Note 4). The request include a copy of the TGT and a piece of "Authorisation" data encrypted with the GREEN session key (the important bit is that it has the GREEN session key because the user proved they knew a valid password).
- The TGS (having approved the request) sends back a Ticket for the requested service (RED). The ticket is encrypted with the service's private key so again the client just treats it as an opaque blob. A NEW random, transient session key (PINK) is created for the future communication between the Client and hostS (ie they both know this key). It is protected from eavesdropping by encrypting it with the GREEN session key.
- Finally the client connects to the machine actually providing the service and sends (AP_REQ) the opaque service ticket as well as some "Authentication" data encrypted with the new service session (PINK) key. The service host needs to know this service session key but rather than having it contact the KDC directly a more efficient approach is taken - the (PINK) key is stored inside the encrypted service ticket supplied to the client in the TGS_REP. (Thus the client actually receives two copies of the service session (PINK) key but of course can't access the one locked in the service ticket.) The service host decrypts the service ticket, extracts the service session key and uses it to decrypt the auth token also sent in AP_REQ. (The auth token timestamp is also checked to ensure it is acceptably recent.)
- The last stage (AP_REP) many not occur, it is only needed if mutual authentication is required (ie client wants the server to prove it is who it claims to be). If this happens the server just sends back some verification data encrypted with the PINK session key. (If it was an interloper service it would not have been able to obtain the PINK session key from the KDC.
Notes:
0) There may be an initial AS_REQ/AS_REP "preauth" stage which is not shown here. Packet examples are included below.
1) A random session key is used and then discarded making it harder to do cryptographic attacks based on gathering large samples encrypted with the same key over a long period of time. By the time any current computer could crack the session key it will be useless.
2) A "session" typically lasts up to the order of hours.
3) The TGT is encrypted with the Ticket Granting Server (TGS) private key. The key itself is not sent across the network, and the client cannot decrypt it, so it remains an opaque token as far as the client is concerned.
4) The service names are just conventions, however software tends to assume things about the different components H/D@R so conform to the structure.
5) Don't go talking about yellow and pink keys to others, they'll just look at you strangely. I made up the colours to simplify the description.
Encryption Types
To encrypt data one needs both a KEY and an encryption ALGORITHM (referred to here as "encryption type").
Kerberos implementations typically support a number of encryption types whose names include:
- des-cbc-crc
- des-cbc-md5
- aes256-cts-hmac-sha1-96
- etc.
At the same time however the client and server are likely to be upgraded at widely varying intervals and it is not practical to upgrade all servers and clients at exactly the same time. So part of the Kerberos protocol is to negotiate encryption algorithms between client and server for the two session keys (which are the only keys they both have to share).
There is one more piece to this puzzle. The KDC keeps all the service keys encrypted ...
The negotiation goes as follows:
- Client sends a list of encryption types in order of preference that it can handle in the AS_REQ.
- The KDC looks up a preferentially ordered list of encryption types that it can handle for the relevant session ticket.
- The KDC then chooses the first encryption type that they both support (ie first match in an the intersection of both sets) (Note A)
- The session key is now encrypted with the client's private key using the selected encryption type (Algorithm).
Kerberos allows the lists of preferred encryption types to be configured. This is actually necessary in some cases to get Kerberos clients to talk to the servers successfully (because of implementation differences).
The CLIENT has two configuration items:
- It can specify the TGT encryption type using the krb5.conf property: ++default_tkt_enctypes = ...++
- It can specify the TGS encryption type using the krb5.conf property: ++default_tgs_enctypes = ...++
The SERVER has several configuration options:
- permitted_enctypes = This restricts ALL encryption types, TGT, TGS and Principal encryption types.
- supported_enctypes =
Note A: The intersection is further subset by the list of permitted_enctypes.
In addition the encryption types used to encode the service keys can be specified at creation time (kadmin's ktadd command etc)
GREEN Session Key Encryption type chosen is the 1st match of an intersection between Client Preferred Encryption Type list and the Server Preferred Encryption Types
There's also a complexity to do with highest value keys numbers (KVNO) being used before lower values. The higher value keys effecticvely expire/replace the earlier keys. A simple installation should be able to ignore this complexity.
Setting up Kerberos
This section provides an overview of the initial admin processes with an emphasis on keys and config files. It tries to be system independent but the examples rely on the fact that many implementations are based on the MIT version. It does not detail a step-by-step process but seeks to give an overview so that step-by-step processes documented elsewhere make sense.
There are a number of files to setup. This sections assumes three logical types of server: KDC server, service host, client.
A service host provides a service such as NFS shares or permits ssh login. A client is a user of these services.
A single physical machine may be all three: KDC, service provider, client in which case the various configuration files and databases will be a combination of the requirements for each host type.
Note: This overview does not include a
slave KDC which would add unnecessary complexity for an overview.
References to kiprop and kpropd (used for master/slave replication) have
been omitted.
First we must create the KDB and configuration files.
Note: There are a number of commands and scripts to do this so it is system specific. A script utility
There are two kadmin commands: kadmin and kadmin.local, the latter is used early in the setup process and can only be run on the KDC.
kdcmgr
or similar may exist on your system that asks questions then creates
the kdc.conf, krb5.conf configuration files and runs kdb5_util and
kadmin to create the database and add the standard principals.There are two kadmin commands: kadmin and kadmin.local, the latter is used early in the setup process and can only be run on the KDC.
In the diagram the KDB is shown being created via the
kdcmgr create command run on the KDC. It asks a number of questions and performs the following functions:- creates kdc.conf, krb5.conf and kadm5.acl files on the KDC.
- creates an empty Kerberos Database (KDB) and encrypts it with the requested master key (black key in diagram).
- creates krb5.keytab (and kadm5.keytab ?) databases on KDC.
- creates a random TGT key (yellow in diagram)
- may add various other principals including:
- host/hostK.domain... (host authentication, used by a number of clients/services)
- kiprop/hostK.domain... (optionally needed for kerberos master/slave replication)
- kadmin/hostK.domain... (used by kadmind)
- kadmin/changepw (used by kadmind)
- kadmin/history (used by kadmind)
The
kdcmgr script can be examined to see what it does. Most of the actions reduce to some text editing and a few kadmin commands which can be entered by hand if better understanding of the processes is desired.KDC configuration files and databases
After creation (either manually or automagically) they should looks something like these (my version is from Solaris):
kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
DFUSION.COM.AU = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
# admin_keytab = /etc/krb5/kadm5.keytab
master_key_type = aes128-cts-hmac-sha1-96
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}
krb5.conf
[libdefaults]
default_realm = DFUSION.COM.AU
[realms]
DFUSION.COM.AU = {
kdc = blackhole.dfusion.com.au
admin_server = blackhole.dfusion.com.au
kpasswd = blackhole.dfusion.com.au
}
[domain_realm]
.dfusion.com.au = DFUSION.COM.AU
# Next line is optional, but doesn't hurt to include even if not used.
# Needed if there is a server named the same as the domain ie dfusion.com.au rather than
# the more common case of servers named xxx.dfusion.com.au
# dfusion.com.au = DFUSION.COM.AU
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable = true
}
KDB (via kadmin: listprincs)
K/M@DFUSION.COM.AU krbtgt/DFUSION.COM.AU@DFUSION.COM.AU changepw/blackhole.dfusion.com.au@DFUSION.COM.AU kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU kadmin/changepw@DFUSION.COM.AU kadmin/history@DFUSION.COM.AU host/blackhole.dfusion.com.au@DFUSION.COM.AU kim @DFUSION.COM.AU kim/admin@DFUSION.COM.AU
To view the keytab files use:
- klist - simple list tool (eg klist -ke)
- ktutil - keytable editor tool
man pages for usage.
KDC krb5.keytab (via ktutil)
slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 host/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 3 host/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-128 CTS mode with 96-bit SHA-1 HMAC) 3 3 host/blackhole.dfusion.com.au@DFUSION.COM.AU (Triple DES cbc mode with HMAC/sha1) 4 3 host/blackhole.dfusion.com.au@DFUSION.COM.AU (ArcFour with HMAC/md5) 5 3 host/blackhole.dfusion.com.au@DFUSION.COM.AU (DES cbc mode with RSA-MD5)
kadm5.keytab (via ktutil)
slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 3 kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-128 CTS mode with 96-bit SHA-1 HMAC) 3 3 kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU (Triple DES cbc mode with HMAC/sha1) 4 3 kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU (ArcFour with HMAC/md5) 5 3 kadmin/blackhole.dfusion.com.au@DFUSION.COM.AU (DES cbc mode with RSA-MD5) 6 3 changepw/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-256 CTS mode with 96-bit SHA-1 HMAC) 7 3 changepw/blackhole.dfusion.com.au@DFUSION.COM.AU (AES-128 CTS mode with 96-bit SHA-1 HMAC) 8 3 changepw/blackhole.dfusion.com.au@DFUSION.COM.AU (Triple DES cbc mode with HMAC/sha1) 9 3 changepw/blackhole.dfusion.com.au@DFUSION.COM.AU (ArcFour with HMAC/md5) 10 3 changepw/blackhole.dfusion.com.au@DFUSION.COM.AU (DES cbc mode with RSA-MD5) 11 3 kadmin/changepw@DFUSION.COM.AU (AES-256 CTS mode with 96-bit SHA-1 HMAC) 12 3 kadmin/changepw@DFUSION.COM.AU (AES-128 CTS mode with 96-bit SHA-1 HMAC) 13 3 kadmin/changepw@DFUSION.COM.AU (Triple DES cbc mode with HMAC/sha1) 14 3 kadmin/changepw@DFUSION.COM.AU (ArcFour with HMAC/md5) 15 3 kadmin/changepw@DFUSION.COM.AU (DES cbc mode with RSA-MD5)
Although the above KDB and keytab files appear complex they reduce to some relatively simple concepts.
The keytab files store local, multiply encrypted copies of the named keys. Each key is encrypted using all the publicly supported encryption types (encryption algorithms - see previous section). This is done so that the key itself does not have to be known at "runtime" for encryption using an encryption type supported by a particular client/service (encrypted keys are sent around the network).
The kadm5.keytab contains various keys (kadmin/host..., changepw/host... and kadmin/changepw used by the kadmin/kadmind utilities to manage remote password changes etc. These are not further discussed.
This leaves us with several keys of interest:
- K/M@DFUSION.COM.AU — the Kerberos master key (black key in diagram)
- krbtgt/DFUSION.COM.AU@DFUSION.COM.AU — the TGT key (it is a randomly generated key and lives in the KDB)
- host/blackhole.dfusion.com.au@DFUSION.COM.AU — a key representing the KDC host itself. Used by various services for authentication. Encrypted copies of this key are stored in the krb5.keytab file on the KDC host as they may be sent across the network.
- kim @DFUSION.COM.AU — a user principal. There will be one per human kerberos user. The password is stored in the KDB only. It is never sent across the network.
- kim/admin@DFUSION.COM.AU — an admin user principal. By convention it is in the form username/admin. The password is stored in the KDB only. It is never sent across the network.
Note “kim” is different to “kim/admin”. Administration is kept separate from normal user authentication by convention to minimise accidents.
Note: Random keys are used in some cases to save humans thinking up secure passwords which they won't ever need to use.
To help understand the commands that produce the files above it helps to group the principals into roughly two classes:
- principals that have passwords created by humans (eg for user
principals or special system principals). These passwords are typically not sent across the network.
- These are created using:
kadmin: addprinc principal[/instance]and the password is then entered manually. Eg:addprinc kim
- These are created using:
- principals with randomly generated passwords (that never need be known by a human) and are typically sent over the network
- These are created using:
kadmin: addprinc -randkey principal[/instance]. The password is randomly generated. - These passwords need to be added to the keytab file using: '-+kadmin: ktadd [-k keytab_file] principal[/instance]. Eg
ktadd host/blackhole.dfusion.com.au
- These are created using:
Service Host configuration files and databases
To configure and administer a service host, the first thing to do is copy the krb5.conf file over to it. It does not normally need any other file or database copied over.
The krb5.conf file tells any host how to contact the KDC. It may also be possible to configure some service hosts to obtain their configuration information via DNS (using SRV and TXT records), however an explicit file seems safer.
Before continuing there is something important to understand that can be summarised as follows:
ONLY perform
kadmin: addprinc -randkey service/host.domain on the server that IS host.domain.The addprinc -randkey command does two things:
- adds the named identity into the master Kerberos DataBase (KDB) on whatever (remote) server the KDC is located.
- adds the identities (random) secret password into the local keytab file (typically
/etc/krb5/krb5.keytab)
Note: It is important on which server the
addprinc -randkey commands are typed.So for example:
- host/myhost.... should only be created on myhost (so the secret password gets put into myhost:/etc/krb5/krb5.keytab)
- nfs/nfshost.... should only be created on nfshost (so the secret password gets put into nfshost:/etc/krb5/krb5.keytab)
Thus on each server you probably ought to create a:
- host/myhost.... should only be created on myhost (so the secret password gets put into myhost:/etc/krb5/krb5.keytab)
- nfs/nfshost.... (the secret password gets put into nfshost:/etc/krb5/krb5.keytab)
If the KDC and NFS host happen to be the same machine then of course they will just be done together.
At some stage you may also need to create machine specific root identities just as you did for host/*. The distinction between use of host/ and root/ within applications is unclear (to me at least):
- root/myhost.... [-randkey] - representing the machine root (or root user). Human password or machine ???
To do the above on each server, login to the relevant server and do:
$ kadmin -p kim/admin kadmin: addprinc ... kadmin: ktadd ... kadmin: quit
The admin tool reads the krb5.conf file to find out how to contact the kdc.
If kadmin cannot be run on the relevant server for some reason, there are fiddly ways around creating a server specific keytab file on the kdc (using ktadd -k tmpfile) and then moving it to the server.
Client configuration files
A pure client only needs a krb5.conf file. It generally does not need any other configuration files or databases.
The krb5.conf file tells any host how to contact the KDC. Although it probably doesn't hurt to use the exact same config file as used on the KDC, a more minimal file may be used for simple clients. It may also be possible to configure some clients to obtain their configuration information via DNS (using SRV and TXT records).
An example of one minimal client file (from Apple OS X 10.5 (Leopard)) is:
minimal krb5.conf file
[libdefaults]
default_realm = DFUSION.COM.AU
dns_fallback = yes
[domain_realm]
.dfusion.com.au = DFUSION.COM.AU
[realms]
DFUSION.COM.AU = {
kdc = blackhole.dfusion.com.au:88
admin_server = blackhole.dfusion.com.au:749
kpasswd = blackhole.dfusion.com.au:464
}
This example happens to list the (default) port numbers explicitly.
Network Packet Dumps
If you are interested in the data actually going over the network then click on the [+] to expand the following sections.
Client <-> KDC Packets
[-]The following packet dumps were produced from Wireshark. The Kerberos packets are encapsulated in UDP packets as shown.
Note the double attempt for AS_REQ/AS_REP due to the server requiring pre-authentication is not discussed above.
AS_REQ (Attempt 1)
User Datagram Protocol, Src Port: 49779 (49779), Dst Port: kerberos (88)
Source port: 49779 (49779)
Destination port: kerberos (88)
Length: 202
Checksum: 0x8260 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos AS-REQ
Pvno: 5
MSG Type: AS-REQ (10)
KDC_REQ_BODY
Padding: 0
KDCOptions: 50800000 (Forwardable, Proxiable, Renewable)
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket
...1 .... .... .... .... .... .... .... = Proxiable: PROXIABLE tickets are allowed/requested
.... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... ...0 .... .... .... .... .... = Opt HW Auth: False
.... .... .... ..0. .... .... .... .... = Constrained Delegation: This is a normal request (no constrained delegation)
.... .... .... ...0 .... .... .... .... = Canonicalize: This is NOT a canonicalized ticket request
.... .... .... .... .... .... ..0. .... = Disable Transited Check: Transited checking is NOT disabled
.... .... .... .... .... .... ...0 .... = Renewable OK: We do NOT accept renewed tickets
.... .... .... .... .... .... .... 0... = Enc-Tkt-in-Skey: Do NOT encrypt the tkt inside the skey
.... .... .... .... .... .... .... ..0. = Renew: This is NOT a request to renew a ticket
.... .... .... .... .... .... .... ...0 = Validate: This is NOT a request to validate a postdated ticket
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Realm: DFUSION.COM.AU
Server Name (Unknown): krbtgt/DFUSION.COM.AU
Name-type: Unknown (0)
Name: krbtgt
Name: DFUSION.COM.AU
from: 2009-11-12 03:59:15 (UTC)
till: 2009-11-12 13:59:15 (UTC)
rtime: 2009-11-19 03:59:15 (UTC)
Nonce: 1257998355
Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: aes128-cts-hmac-sha1-96 (17)
Encryption type: des3-cbc-sha1 (16)
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-crc (1)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-md4 (2)
AS_REP (Rejection: ERR_PREAUTH_REQUIRED)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 49779 (49779)
Source port: kerberos (88)
Destination port: 49779 (49779)
Length: 268
Checksum: 0x0598 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos KRB-ERROR
Pvno: 5
MSG Type: KRB-ERROR (30)
ctime: 2009-11-12 03:59:15 (UTC)
stime: 2009-11-12 03:59:15 (UTC)
susec: 823415
error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25)
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Realm: DFUSION.COM.AU
Server Name (Unknown): krbtgt/DFUSION.COM.AU
Name-type: Unknown (0)
Name: krbtgt
Name: DFUSION.COM.AU
e-text: NEEDED_PREAUTH
e-data
padata: PA-ENC-TIMESTAMP PA-ENCTYPE-INFO2 PA-SAM-RESPONSE
Type: PA-ENC-TIMESTAMP (2)
Value: <MISSING>
Type: PA-ENCTYPE-INFO2 (19)
Value: 302A3005A0030201123005A0030201113005A00302011030... aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-c
bc-md5 des-cbc-crc
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: aes128-cts-hmac-sha1-96 (17)
Encryption type: des3-cbc-sha1 (16)
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-crc (1)
Type: PA-SAM-RESPONSE (13)
Value: <MISSING>
AS_REQ (Attempt 2)
User Datagram Protocol, Src Port: 49780 (49780), Dst Port: kerberos (88)
Source port: 49780 (49780)
Destination port: kerberos (88)
Length: 286
Checksum: 0x82b4 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos AS-REQ
Pvno: 5
MSG Type: AS-REQ (10)
padata: PA-ENC-TIMESTAMP
Type: PA-ENC-TIMESTAMP (2)
Value: 3041A003020112A23A0438C56EE2E4F7D012ACCEDA7103CA... aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
enc PA_ENC_TIMESTAMP: C56EE2E4F7D012ACCEDA7103CA31463A6F23BC8587F47DE0...
KDC_REQ_BODY
Padding: 0
KDCOptions: 50800000 (Forwardable, Proxiable, Renewable)
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket
...1 .... .... .... .... .... .... .... = Proxiable: PROXIABLE tickets are allowed/requested
.... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... ...0 .... .... .... .... .... = Opt HW Auth: False
.... .... .... ..0. .... .... .... .... = Constrained Delegation: This is a normal request (no constrained delegation)
.... .... .... ...0 .... .... .... .... = Canonicalize: This is NOT a canonicalized ticket request
.... .... .... .... .... .... ..0. .... = Disable Transited Check: Transited checking is NOT disabled
.... .... .... .... .... .... ...0 .... = Renewable OK: We do NOT accept renewed tickets
.... .... .... .... .... .... .... 0... = Enc-Tkt-in-Skey: Do NOT encrypt the tkt inside the skey
.... .... .... .... .... .... .... ..0. = Renew: This is NOT a request to renew a ticket
.... .... .... .... .... .... .... ...0 = Validate: This is NOT a request to validate a postdated ticket
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Realm: DFUSION.COM.AU
Server Name (Unknown): krbtgt/DFUSION.COM.AU
Name-type: Unknown (0)
Name: krbtgt
Name: DFUSION.COM.AU
from: 2009-11-12 03:59:15 (UTC)
till: 2009-11-12 13:59:15 (UTC)
rtime: 2009-11-19 03:59:15 (UTC)
Nonce: 1257998355
Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc des-cbc-md5 des-cbc-md4
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: aes128-cts-hmac-sha1-96 (17)
Encryption type: des3-cbc-sha1 (16)
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-crc (1)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-md4 (2)
Note the only real difference between AS_REQ Attempt 1 and this Attempt 2 is the following data added to Attempt 2
padata: PA-ENC-TIMESTAMP
Type: PA-ENC-TIMESTAMP (2)
Value: 3041A003020112A23A0438C56EE2E4F7D012ACCEDA7103CA... aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
enc PA_ENC_TIMESTAMP: C56EE2E4F7D012ACCEDA7103CA31463A6F23BC8587F47DE0...
AS_REP (Success)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 49780 (49780)
Source port: kerberos (88)
Destination port: 49780 (49780)
Length: 629
Checksum: 0xd478 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos AS-REP
Pvno: 5
MSG Type: AS-REP (11)
padata: PA-ENCTYPE-INFO2
Type: PA-ENCTYPE-INFO2 (19)
Value: 30073005A003020112 aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Unknown): krbtgt/DFUSION.COM.AU
Name-type: Unknown (0)
Name: krbtgt
Name: DFUSION.COM.AU
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 1
enc-part: D948436B6AD3805CEC4CFC4FCF9AA288368701284722C9F9...
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
enc-part: 21BA6C442FFAD05AAB830232FED02CE2E893A0712C1A4D85...
TGS_REQ
User Datagram Protocol, Src Port: 49783 (49783), Dst Port: kerberos (88)
Source port: 49783 (49783)
Destination port: kerberos (88)
Length: 626
Checksum: 0x8408 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos TGS-REQ
Pvno: 5
MSG Type: TGS-REQ (12)
padata: PA-TGS-REQ
Type: PA-TGS-REQ (1)
Value: 6E8201C8308201C4A003020105A10302010EA20703050000... AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 00000000
.0.. .... .... .... .... .... .... .... = Use Session Key: Do NOT use the session key to encrypt the ticket
..0. .... .... .... .... .... .... .... = Mutual required: Mutual authentication is NOT required
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Unknown): krbtgt/DFUSION.COM.AU
Name-type: Unknown (0)
Name: krbtgt
Name: DFUSION.COM.AU
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 1
enc-part: D948436B6AD3805CEC4CFC4FCF9AA288368701284722C9F9...
Authenticator aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Authenticator data: 859A4306DCBAC0E4E1B4D279DC335DADA9C59C54AFABC583...
KDC_REQ_BODY
Padding: 0
KDCOptions: 50810000 (Forwardable, Proxiable, Renewable, Canonicalize)
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket
...1 .... .... .... .... .... .... .... = Proxiable: PROXIABLE tickets are allowed/requested
.... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... ...0 .... .... .... .... .... = Opt HW Auth: False
.... .... .... ..0. .... .... .... .... = Constrained Delegation: This is a normal request (no constrained delegation)
.... .... .... ...1 .... .... .... .... = Canonicalize: This is a request for a CANONICALIZED ticket
.... .... .... .... .... .... ..0. .... = Disable Transited Check: Transited checking is NOT disabled
.... .... .... .... .... .... ...0 .... = Renewable OK: We do NOT accept renewed tickets
.... .... .... .... .... .... .... 0... = Enc-Tkt-in-Skey: Do NOT encrypt the tkt inside the skey
.... .... .... .... .... .... .... ..0. = Renew: This is NOT a request to renew a ticket
.... .... .... .... .... .... .... ...0 = Validate: This is NOT a request to validate a postdated ticket
Realm: DFUSION.COM.AU
Server Name (Principal): nfs/blackhole.dfusion.com.au
Name-type: Principal (1)
Name: nfs
Name: blackhole.dfusion.com.au
till: 2009-11-12 11:59:15 (UTC)
Nonce: 1257998381
Encryption Types: des-cbc-crc des-cbc-md5 des-cbc-md4
Encryption type: des-cbc-crc (1)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-md4 (2)
TGS_REP
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 49783 (49783)
Source port: kerberos (88)
Destination port: 49783 (49783)
Length: 609
Checksum: 0xe1a7 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos TGS-REP
Pvno: 5
MSG Type: TGS-REP (13)
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Principal): nfs/blackhole.dfusion.com.au
Name-type: Principal (1)
Name: nfs
Name: blackhole.dfusion.com.au
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 3
enc-part: 3B0A04F37361AFF188268DFC8308BB7F6CFB1081C9C1C841...
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
enc-part: B3E81D93B9325A0856B5BF3A47E831E9958672DE3BBB49D4...
TGS_REP (Session Key decrypted)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 49783 (49783)
Source port: kerberos (88)
Destination port: 49783 (49783)
Length: 609
Checksum: 0xe1a7 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Kerberos TGS-REP
Pvno: 5
MSG Type: TGS-REP (13)
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Principal): nfs/blackhole.dfusion.com.au
Name-type: Principal (1)
Name: nfs
Name: blackhole.dfusion.com.au
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 3
enc-part: 3B0A04F37361AFF188268DFC8308BB7F6CFB1081C9C1C841...
[Decrypted using: keytab principal nfs/blackhole.dfusion.com.au@DFUSION.COM.AU]
EncTicketPart
Padding: 0
Ticket Flags (Forwardable, Proxiable, Renewable, Pre-Auth, Transited Policy Checked)
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket
...1 .... .... .... .... .... .... .... = Proxiable: PROXIABLE tickets are allowed/requested
.... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated
.... ...0 .... .... .... .... .... .... = Invalid: This ticket is NOT invalid
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... .0.. .... .... .... .... .... = Initial: This ticket was granted by TGT and not as protocol
.... .... ..1. .... .... .... .... .... = Pre-Auth: The client was PRE-AUTHenticated
.... .... ...0 .... .... .... .... .... = HW-Auth: The client was NOT authenticated using hardware
.... .... .... 1... .... .... .... .... = Transited Policy Checked: Kdc has performed TRANSITED POLICY CHECKING
.... .... .... .0.. .... .... .... .... = Ok As Delegate: This ticket is NOT ok as a delegated ticket
key des-cbc-crc
Key type: des-cbc-crc (1)
Key value: EC47E978C6FC9762
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
TransitedEncoding DOMAIN-X500-COMPRESS
Type: DOMAIN-X500-COMPRESS (1)
Contents: <MISSING>
Authtime: 2009-11-17 03:57:02 (UTC)
Start time: 2009-11-17 08:20:50 (UTC)
End time: 2009-11-17 16:16:13 (UTC)
Renew-till: 2009-11-24 03:57:02 (UTC)
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
enc-part: B3E81D93B9325A0856B5BF3A47E831E9958672DE3BBB49D4...
Client <-> Service Host: AP_REQ/AP_REP examples using NFSv4
[-]These requests have a number of differences to earlier requests. First of all NFS uses RPC over TCP.
The Kerberos credentials are encapsulated in a protocol known as RPCSEC_GSS, which is a generalised security protocol that wraps/handles Kerberos as one option. Buried within the GSS wrapper is the actual AP_REQ/AP_REP shown as KRB5_AP_REQ and KRB5_AP_REP in the packet dumps.
AP_REQ - An NFSv4 NULL RPC call via TCP
Transmission Control Protocol, Src Port: 55236 (55236), Dst Port: nfs (2049), Seq: 1, Ack: 1, Len: 580
Source port: 55236 (55236)
Destination port: nfs (2049)
.... [TCP header data omitted] ...
Remote Procedure Call, Type:Call XID:0x4537961f
Fragment header: Last fragment, 576 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0010 0100 0000 = Fragment Length: 576
XID: 0x4537961f (1161270815)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 4
Procedure: NULL (0)
[The reply to this request is in frame 80]
Credentials
Flavor: RPCSEC_GSS (6)
Length: 20
GSS Version: 1
GSS Procedure: RPCSEC_GSS_INIT (1)
GSS Sequence Number: 0
GSS Service: rpcsec_gss_svc_none (1)
GSS Context: <EMPTY>
length: 0
contents: <EMPTY>
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System
[Program Version: 4]
[V4 Procedure: NULL (0)]
GSS Token: 000001FF608201FB06092A864886F71201020201006E8201...
GSS Token Length: 511
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01006E8201EA308201E6A003020105A10302010EA2070305...
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 20000000 (Mutual required)
.0.. .... .... .... .... .... .... .... = Use Session Key: Do NOT use the session key to encrypt the ticket
..1. .... .... .... .... .... .... .... = Mutual required: MUTUAL authentication is REQUIRED
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Principal): nfs/blackhole.dfusion.com.au
Name-type: Principal (1)
Name: nfs
Name: blackhole.dfusion.com.au
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 3
enc-part: 3B0A04F37361AFF188268DFC8308BB7F6CFB1081C9C1C841...
Authenticator des-cbc-crc
Encryption type: des-cbc-crc (1)
Authenticator data: CA02C66D4E51958415BC72F8CF8E7D3376892E61BFE2EB9B...
AP_REP - An NFSv4 NULL RPC reply via TCP
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 55236 (55236), Seq: 1, Ack: 581, Len: 208
Source port: nfs (2049)
Destination port: 55236 (55236)
.... [TCP header data omitted] ...
Remote Procedure Call, Type:Reply XID:0x4537961f
Fragment header: Last fragment, 204 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 1100 1100 = Fragment Length: 204
XID: 0x4537961f (1161270815)
Message Type: Reply (1)
[Program: NFS (100003)]
[Program Version: 4]
[Procedure: NULL (0)]
Reply State: accepted (0)
[This is a reply to a request in frame 78]
[Time from request: 0.032155000 seconds]
Verifier
Flavor: RPCSEC_GSS (6)
GSS Token: 00000025602306092A864886F71201020201010000FFFFFF...
GSS Token Length: 37
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01010000FFFFFFFF4A604A70DDC86EF623C36495D01F8111
krb5_tok_id: KRB5_GSS_GetMIC (0x0101)
krb5_sgn_alg: DES MAC MD5 (0x0000)
krb5_snd_seq: 4A604A70DDC86EF6
krb5_sgn_cksum: 23C36495D01F8111
Accept State: RPC executed successfully (0)
Network File System
[Program Version: 4]
[V4 Procedure: NULL (0)]
GSS Context: <DATA>
length: 4
contents: <DATA>
GSS Major Status: 0
GSS Minor Status: 0
GSS Sequence Window: 128
GSS Token: 00000072607006092A864886F71201020202006F61305FA0...
GSS Token Length: 114
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 02006F61305FA003020105A10302010FA2533051A0030201...
krb5_tok_id: KRB5_AP_REP (0x0002)
Kerberos AP-REP
Pvno: 5
MSG Type: AP-REP (15)
enc-part des-cbc-crc
Encryption type: des-cbc-crc (1)
enc-part: 7F1696287D0C94F50974772430F87994AD170D537772DB26...
Client <-> Service Host: AP_REQ/AP_REP examples using NFSv4 (decrypted)
[-]AP_REQ - An NFSv4 NULL RPC call via TCP (decrypted)
Transmission Control Protocol, Src Port: 52886 (52886), Dst Port: nfs (2049), Seq: 1, Ack: 1, Len: 580
Source port: 52886 (52886)
Destination port: nfs (2049)
.... [TCP header data omitted] ...
Remote Procedure Call, Type:Call XID:0x21f5304f
Fragment header: Last fragment, 576 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0010 0100 0000 = Fragment Length: 576
XID: 0x21f5304f (569716815)
Message Type: Call (0)
RPC Version: 2
Program: NFS (100003)
Program Version: 4
Procedure: NULL (0)
[The reply to this request is in frame 55]
Credentials
Flavor: RPCSEC_GSS (6)
Length: 20
GSS Version: 1
GSS Procedure: RPCSEC_GSS_INIT (1)
GSS Sequence Number: 0
GSS Service: rpcsec_gss_svc_none (1)
GSS Context: <EMPTY>
length: 0
contents: <EMPTY>
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System
[Program Version: 4]
[V4 Procedure: NULL (0)]
GSS Token: 000001FF608201FB06092A864886F71201020201006E8201...
GSS Token Length: 511
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01006E8201EA308201E6A003020105A10302010EA2070305...
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 20000000 (Mutual required)
.0.. .... .... .... .... .... .... .... = Use Session Key: Do NOT use the session key to encrypt the ticket
..1. .... .... .... .... .... .... .... = Mutual required: MUTUAL authentication is REQUIRED
Ticket
Tkt-vno: 5
Realm: DFUSION.COM.AU
Server Name (Principal): nfs/blackhole.dfusion.com.au
Name-type: Principal (1)
Name: nfs
Name: blackhole.dfusion.com.au
enc-part aes256-cts-hmac-sha1-96
Encryption type: aes256-cts-hmac-sha1-96 (18)
Kvno: 3
enc-part: F489B4BEC4EDB5376CB948A67973356F39A4F4E0A521D1A9...
[Decrypted using: keytab principal nfs/blackhole.dfusion.com.au@DFUSION.COM.AU]
EncTicketPart
Padding: 0
Ticket Flags (Forwardable, Proxiable, Renewable, Pre-Auth, Transited Policy Checked)
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..0. .... .... .... .... .... .... .... = Forwarded: This is NOT a forwarded ticket
...1 .... .... .... .... .... .... .... = Proxiable: PROXIABLE tickets are allowed/requested
.... 0... .... .... .... .... .... .... = Proxy: This ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate: We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This ticket is NOT postdated
.... ...0 .... .... .... .... .... .... = Invalid: This ticket is NOT invalid
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... .0.. .... .... .... .... .... = Initial: This ticket was granted by TGT and not as protocol
.... .... ..1. .... .... .... .... .... = Pre-Auth: The client was PRE-AUTHenticated
.... .... ...0 .... .... .... .... .... = HW-Auth: The client was NOT authenticated using hardware
.... .... .... 1... .... .... .... .... = Transited Policy Checked: Kdc has performed TRANSITED POLICY CHECKING
.... .... .... .0.. .... .... .... .... = Ok As Delegate: This ticket is NOT ok as a delegated ticket
key des-cbc-crc
Key type: des-cbc-crc (1)
Key value: EC47E978C6FC9762
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
TransitedEncoding DOMAIN-X500-COMPRESS
Type: DOMAIN-X500-COMPRESS (1)
Contents: <MISSING>
Authtime: 2009-11-17 03:57:02 (UTC)
Start time: 2009-11-17 08:20:50 (UTC)
End time: 2009-11-17 16:16:13 (UTC)
Renew-till: 2009-11-24 03:57:02 (UTC)
Authenticator des-cbc-crc
Encryption type: des-cbc-crc (1)
Authenticator data: 980ADBEB3DD9964DEB1DD3E5A0E71BF1EFC64445E8B391A9...
[Decrypted using: key learnt from frame 53]
Authenticator
Authenticator vno: 5
Client Realm: DFUSION.COM.AU
Client Name (Unknown): kim
Name-type: Unknown (0)
Name: kim
Checksum
Type: gssapi-8003 (32771)
checksum: 100000000000000000000000000000000000000032010000
Length: 16
Bnd: 00000000000000000000000000000000
.... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
.... .... .... .... .... .... ..1. .... = Integ: Integrity protection (signing) may be invoked
.... .... .... .... .... .... ...1 .... = Conf: Confidentiality (sealing) may be invoked
.... .... .... .... .... .... .... 0... = Sequence: Do NOT enable out-of-sequence detection
.... .... .... .... .... .... .... .0.. = Replay: Do NOT enable replay protection
.... .... .... .... .... .... .... ..1. = Mutual: Request that remote peer authenticates itself
.... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate
cusec: 92613
ctime: 2009-11-17 08:20:50 (UTC)
Subkey des-cbc-crc
Key type: des-cbc-crc (1)
Key value: B326E3D00BA2C943
Seq Number: 432091228
AP_REP - An NFSv4 NULL RPC reply via TCP (decrypted)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 52886 (52886), Seq: 1, Ack: 581, Len: 208
Source port: nfs (2049)
Destination port: 52886 (52886)
.... [TCP header data omitted] ...
Remote Procedure Call, Type:Reply XID:0x21f5304f
Fragment header: Last fragment, 204 bytes
1... .... .... .... .... .... .... .... = Last Fragment: Yes
.000 0000 0000 0000 0000 0000 1100 1100 = Fragment Length: 204
XID: 0x21f5304f (569716815)
Message Type: Reply (1)
[Program: NFS (100003)]
[Program Version: 4]
[Procedure: NULL (0)]
Reply State: accepted (0)
[This is a reply to a request in frame 53]
[Time from request: 0.042267000 seconds]
Verifier
Flavor: RPCSEC_GSS (6)
GSS Token: 00000025602306092A864886F71201020201010000FFFFFF...
GSS Token Length: 37
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 01010000FFFFFFFF5A1D3C7230853182963C6235B69CF63E
krb5_tok_id: KRB5_GSS_GetMIC (0x0101)
krb5_sgn_alg: DES MAC MD5 (0x0000)
krb5_snd_seq: 5A1D3C7230853182
krb5_sgn_cksum: 963C6235B69CF63E
Accept State: RPC executed successfully (0)
Network File System
[Program Version: 4]
[V4 Procedure: NULL (0)]
GSS Context: <DATA>
length: 4
contents: <DATA>
GSS Major Status: 0
GSS Minor Status: 0
GSS Sequence Window: 128
GSS Token: 00000072607006092A864886F71201020202006F61305FA0...
GSS Token Length: 114
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: 02006F61305FA003020105A10302010FA2533051A0030201...
krb5_tok_id: KRB5_AP_REP (0x0002)
Kerberos AP-REP
Pvno: 5
MSG Type: AP-REP (15)
enc-part des-cbc-crc
Encryption type: des-cbc-crc (1)
enc-part: CD8C24A1AED7AECE2AF041033AB95C4CD5D2ADF2A09BC998...
[Decrypted using: key learnt from frame 53]
EncAPRepPart
ctime: 2009-11-17 08:20:50 (UTC)
cusec: 92613
Subkey des-cbc-crc
Key type: des-cbc-crc (1)
Key value: B326E3D00BA2C943
Seq Number: 756163644
No comments:
Post a Comment