directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: ApOption vs ApOptions
Date Mon, 04 Jan 2016 04:16:05 GMT
Thanks for the review comments.

>> then where are the last 2 value coming from ?
I don't track relevant RFCs but just find below from MIT krb5 codes. Please note if trust
RFCs, then we may also need to check other RFCs (not just 4210).

#define AP_OPTS_RESERVED           0x80000000
#define AP_OPTS_USE_SESSION_KEY    0x40000000 /**< Use session key */
#define AP_OPTS_MUTUAL_REQUIRED    0x20000000 /**< Perform a mutual
                                                 authentication exchange */
#define AP_OPTS_ETYPE_NEGOTIATION  0x00000002
#define AP_OPTS_USE_SUBKEY         0x00000001 /**< Generate a subsession key
                                                 from the current session key
                                                 obtained from the
                                                 credentials */

>>, this class should be part of the Kerby-core module, and its name should be KerberosFlags
In fact all Kerberos types start with the base types in kerby-asn1 module. Sure if you'd like,
we can have KerberosFlags that simply extends Asn1Flags. Note Asn1Flags is also needed elsewhere


-----Original Message-----
From: Emmanuel L├ęcharny [] 
Sent: Monday, January 04, 2016 4:18 AM
Subject: ApOption vs ApOptions


I'm continuing my review of the kerby-core module (and I'll try to review a few classes every
day if I have some time at night...).

I have a question regarding the APOptions implementation. RFC 4120 defines it as :

APOptions       ::= KerberosFlags
        -- reserved(0),
        -- use-session-key(1),
        -- mutual-required(2)

This element is used in the AP-REQ structure :

        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (14),
        ap-options      [2] APOptions,
        ticket          [3] Ticket,
        authenticator   [4] EncryptedData -- Authenticator

We currently have 2 classes for that : ApOptions and ApOption (actually, this is an Enum).

- first, what is the ApOption Enum good for ? It's used in one place, in the TgsRequest class,
in the verifyAuthenticator() method :


- second, assuming the ApOptions class is just a container, and the ApOption the values that
it can contain, then where are the last 2 value coming from ? :

public enum ApOption implements EnumType {
    ETYPE_NEGOTIATION(0x00000002),           // Where is it coming from ?
    USE_SUBKEY(0x00000001);                  // Where is it coming from ?

- AFAICT, The ApOptions class extend the Asn1Flags class, which header is quite weird :

 KrbFlags   ::= BIT STRING (SIZE (32..MAX))
 -- minimum number of bits shall be sent,
 -- but no fewer than 32
public class Asn1Flags extends Asn1BitString {

IMO, this class should be part of the Kerby-core module, and its name should be KerberosFlags.

Thoights ?

View raw message