[Kdc-info] blasphemy

[Leif Johansson]

Ken Raeburn wrote:

>Leif Johansson <leifj at it.su.se> writes:
>  
>
>>    * Is the keyversion associated with the key or with the principal?
>>    
>>
>
>With the key -- or, perhaps, a set of keys.  We might want the model
>to reinforce "my key is at version 4 and supports triple-DES and RC4"
>rather than "my DES key is at version 4 and my AES key is at version
>5".  At least, I *think* that's the way it needs to work.  I haven't
>tried to really wrap my head around a way of making the second
>approach work, but I don't think it would.  But maybe the model
>doesn't necessarily need to reinforce that.
>
There are two issues here:

1. Separation of key-stuff from non-key stuff in the model.
2. Association of the key version to the keytype.

Issue 1 is a requirement of our work!  We need to be very careful  about 
what
attribute we associate with principals. If the version is associated 
with the keyset
then we probably need a new keyset object which has a 1-1 association 
with the
principal but is separate from it.

>
>Not associated with the principal -- if you want to rekey a service,
>you want to keep the old key around on the KDC a while so people can
>renew tickets previously issued.
>  
>
Good point!

>What "flags" do you imagine being associated with a key?
>At this level, isn't it appropriate to spell them out?
>  
>
Yes. I was thinking about (from hdb.asn1)

HDBFlags ::= BIT STRING {
        initial(0),             -- require as-req
        forwardable(1),         -- may issue forwardable
        proxiable(2),           -- may issue proxiable
        renewable(3),           -- may issue renewable
        postdate(4),            -- may issue postdatable
        server(5),              -- may be server
        client(6),              -- may be client
        invalid(7),             -- entry is invalid
        require-preauth(8),     -- must use preauth
        change-pw(9),           -- change password service
        require-hwauth(10),     -- must use hwauth
        ok-as-delegate(11),     -- as in TicketFlags
        user-to-user(12),       -- may use user-to-user auth
        immutable(13)           -- may not be deleted
}

But those are clearly associated with the pricipal.

>  
>
>>    * Is the auxilliary key data (I was thinking about AES
>>requirements) appropriate?
>>    
>>
>
>We need something like that, but I'm not sure how to store it.  All
>the KDC would care about would be the octet string form, but that's
>not what the admin system is going to care about.
>  
>
The admin system will have to understand how to encode the auxilliary data.
This is essentially the same discussion we had about policy recently. Isn't
a typed blob all you can hope to do in a general schema/model?

>  
>
>>    * What exactly goes into password policy?
>>    
>>
>
>Good question.  I'll try to get to looking over the LDAP password
>policy stuff soon, for some ideas.
>  
>
Good!

>Some random thoughts:
>
>I think there would be at least two categories of password-related
>policies: (1) when is a password change needed (including "now"); (2)
>what new passwords are allowed.  I don't know if they'd be entirely
>independent; "you chose a short password, so you're going to have to
>change it again tomorrow."  "When is a password change permitted"
>needs to be covered, but probably would fit in one of those two
>categories.
>
>Non-password policies and other info:
>
> - require preauth? what kind? handle for auxiliary data for preauth
>   system, which might or might not be associated with key version
>   numbers. (srp: probably associated with key and kvno; smart card:
>   not associated)
>
> - can initial tickets be issued for this principal?  (probably not
>   for many random service principals, in many environments)  boolean?
>
> - can service tickets be issued for this principal?  (probably not
>   for most user principals with relatively weak keys) boolean?
>
> - supported encryption types for service principals, since Kerberos
>   doesn't allow the client and server to negotiate.  MIT currently
>   overloads the set of service keys for this purpose, but they really
>   should be separate.
>  
>
Are these general enough to warrant specification in the model? Maybe...

>Principal aliases?
>  
>
Very good!

>(Sorry for the rambling, I'm trying to head home shortly, and just
>want to get some of this down so I don't forget it.  Let me know if
>I'm diving into too low a level of detail for the stuff we want.)
>  
>
No, great stuff.

       Cheers Leif