Subject: Re: draft-ietf-dhc-packetcable-02.txt

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 30 Jul 2002 14:01:51 -0500

I am going to pass on your note to the krb-wg, who should have additional comments.

You should also look at:  
" Distributing Kerberos KDC and Realm Information with DNS"
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-krb-dns-locate-03.txt

Which describes how to find a KDC using DNS. I should point out that
W2K, MIT and I think Hiemdal all have this implemented.  

Thomas Narten wrote:
> 
> Hi Kerberos/Kink Chairs:
> 
> The DHC WG is working on a document that relates to work that
> Cablelabs (a consortia of vendors doing IP over Cable Modem work) is
> doing with regards to configuring VoIP. In reviewing it, I find that
> it includes some kerberos-specific configuration, something I don't
> believe has been done via DHC before.
> 
> I (as one of the ADs for the Internet Area where the DHC WG is homed)
> would appreciate it if you could review (or point me to someone who
> might be able review) the kerberos-related stuff that is being
> proposed. I'd like to know if what they are doing makes sense, or
> whether there are some underlying security issues that need more
> thought, e.g., if DHC (possibly with no authentication) is used to
> configure some of the kerberos-related behavior (e.g., see Section 8.5
> below).
> 
> I've include some of the relevant text below for ease of reference.
> 
> There is some urgency associated with this, in that cablelabs wants
> the document completed in August in order to meet its deadlines. I'm
> trying to understand whether the Kerberos-related stuff is OK and
> whether I can go ahead and advance the document.
> 
> Thomas
> 
>    8.4. TSP's Kerberos Realm Name Sub-Option
> 
>    The PacketCable architecture requires an MTA to authenticate itself
>    to the TSP's network via the Kerberos protocol.  A Kerberos Realm
>    name is required at the MTA to permit a DNS lookup for the address of
>    the TSP's Kerberos Key Distribution Center (KDC) entity.
> 
>    The Kerberos Realm name is an FQDN.  The sub-option is encoded as
>    follows:
> 
> 
> 
> 
> 
>   Beser & Duffy         Expires December 2002                       7
>   Internet Draft  DHCP Option for CableLabs Clients         June 2002
> 
>        Code   Len   Kerberos Realm Name
>       +-----+-----+-----+-----+   +-----+
>       |  6  |  n  |  k1 |  k2 |...|  kn |
>       +-----+-----+-----+-----+   +-----+
> 
> 
>    8.5. TSP's Ticket Granting Server Utilization Sub-Option
> 
>    This sub-option encodes a boolean value which indicates whether an
>    MTA should or should not utilize a TGT (Ticket Granting Ticket) when
>    obtaining a service ticket for one of the PacketCable application
>    servers. The encoding is as follows:
> 
>        Code   Len   Value
>       +-----+-----+-----+
>       |  7  |  1  | 1/0 |
>       +-----+-----+-----+
> 
>    The length MUST be 1.  The last octet contains a Boolean value which
>    MUST be either 0 or 1.  A value of 1 MUST be interpreted as true.  A
>    value of 0 MUST be interpreted as false.
> 
> 
>    8.6. TSP's Provisioning Timer Sub-Option
> 
>    The provisioning timer defines the maximum time allowed for the MTA
>    provisioning process to complete. If this timer expires before the
>    MTA has completed the provisioning process, the MTA should reset the
>    timer and re-start its provisioning process from the beginning.
> 
>    The sub-option length MUST be 1 and a value between 1 and 30
>    (minutes, inclusive) MUST be used. If any other value is specified,
>    the MTA MUST treat the sub-option as non-populated.
> 
>        Code   Len    Value
>       +-----+-----+---------+
>       |  8  |  1  | (1..30) |
>       +-----+-----+---------+
> 
> 
>    8.7. TSP's AS-REQ/AS-REP Backoff and Retry
> 
>    This sub-option configures an MTA's Kerberos AS-REQ/AS_REP timeout,
>    backoff, and retry mechanism.
> 
>    The encoding of this sub-option is depicted below:
> 
>       Code Len   Nom Timeout     Max Timeout     Max Retries
>       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>       |10 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
>       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
>    The length octet of this sub-option MUST contain the value 12.
> 
> 
>   Beser & Duffy         Expires December 2002                       8
>   Internet Draft  DHCP Option for CableLabs Clients         June 2002
> 
>    The length octet MUST be followed by 4 octets containing the AS-
>    REQ/AS-REP nominal (initial) timeout value.  This value is a 32 bit
>    unsigned quantity, in units of seconds, encoded per network byte
>    ordering rules.
> 
>    The next 4 octets MUST contain the AS-REQ/AS-REP maximum timeout
>    value.  This value is a 32 bit unsigned quantity, in units of
>    seconds, encoded per network byte ordering rules.
> 
>    The final 4 octets MUST contain the AS-REQ/AS-REP maximum retry
>    count.  This value is a 32 bit unsigned quantity encoded per network
>    byte ordering rules.
> 
> 
>    8.8. TSP's AP-REQ/AP-REP Backoff and Retry
> 
>    This sub-option configures an MTA's Kerberos AP-REQ/AP_REP timeout,
>    backoff, and retry mechanism.
> 
>    The encoding of this sub-option is depicted below:
> 
>       Code Len   Nom Timeout     Max Timeout     Max Retries
>       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>       |11 |12 |n1 |n2 |n3 |n4 |m1 |m2 |m3 |m4 |r1 |r2 |r3 |r4 |
>       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> 
>    The length octet of this sub-option MUST contain the value 12.
> 
>    The length octet MUST be followed by 4 octets containing the AP-
>    REQ/AP-REP nominal (initial) timeout value.  This value is a 32 bit
>    unsigned quantity, in units of seconds, encoded per network byte
>    ordering rules.
> 
>    The next 4 octets MUST contain the AP-REQ/AP-REP maximum timeout
>    value.  This value is a 32 bit unsigned quantity, in units of
>    seconds, encoded per network byte ordering rules.
> 
>    The final 4 octets MUST contain the AP-REQ/AP-REP maximum retry
>    count.  This value is a 32 bit unsigned quantity encoded per network
>    byte ordering rules.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444