headers
Ran Canetti | 8 Aug 2002 17:02
Picon
Favicon

A new crypto forum at the IRTF


Folks,

this note is to announce the formation of a new IRTF Research Group, called
"Crypto Forum Research Group" (CFRG). The group is intended to answer the
need for a single forum where cryptographers, network security experts, and
protocol designers can exchange ideas and investigate the use of
cryptographic techniques for network protocols in general and for the IETF
in particular.

CFRG is of course NOT intended as a replacement for the work done at the
IETF Working Groups in standardizing actual protocols.  Rather, it the group
provides a forum where general techniques and tools can be developed and
scrutinized to the benefit of multiple Working Groups.

Apart from disseminating the understanding of cryptographic techniques
within the IETF, the outputs of CFRG are expected to come in the form of
informational RFCs (in the tradition of, e.g., RFCs 1321 [MD5] and 2104
[HMAC]).

You are cordially invited to join the mailing list and bring forth the
cryptographic question that deprived you of sleep lately.  The list is open.
To reduce spam, the chairs will moderate mails from non-members.

For Charter, more information, and subscription instructions, see
http://www.irtf.org/cfrg.

Best,
David Mcgrew and Ran Canetti, 
CFRG co-chairs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
owner-ietf-krb-wg | 8 Aug 2002 22:19

draft-ietf-krb-wg-krb-dns-locate-03.txt [was Re: draft-ietf-dhc-packetcable-02.txt

]
In-Reply-To: Message from "Douglas E. Engert" <deengert <at> anl.gov> 
   of "Tue, 30 Jul 2002 14:01:51 CDT." <3D46E29F.8DA02928 <at> anl.gov> 
Date: Thu, 08 Aug 2002 15:09:27 -0400
From: Thomas Narten <narten <at> us.ibm.com>
Sender: owner-ietf-krb-wg <at> achilles.ctd.anl.gov
Precedence: bulk

> 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

What is the status of this? I.e., is the WG going to ask the IESG to
advance it anytime soon? Or does it need more work?

Scanning it briefly, I see it seems to recommend using TXT records to
hold mapping information. I wonder if that aspect of the document will
prove to be controversial when it goes through Last Call.

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

This implies the document should hurry up and get finished, so it can
become an RFC. Right?

Thomas
Permalink | Reply | 0 comments |
headers
Ken Raeburn | 14 Aug 2002 00:05
Picon
Favicon

transited realm description in 2.7

After talking a bit with Matt Hur and others, I believe the
description of the transited realm checking needs a little
clarification.  The method of verification may be obvious to someone
who already understands the model used, but it isn't to someone who
doesn't.

This change doesn't describe the model in detail -- this draft
shouldn't become a tutorial on general security issues -- but I hope
gives enough info to point them in the right direction, for
implementation and maybe conceptually as well.

The last third or so of the first paragraph is new; the rest was in
the 02/21/02 version on Cliff's web page, as one paragraph.  (Well, I
also changed the possessive "KDC's" to the plural "KDCs".)

Comments?  Matt, does this clarify it enough?

    <h3>2.7 Transited Policy Checking</H3>

    In Kerberos, the application server is ultimately responsible for
    accepting or rejecting authentication and should check that only
    suitably trusted KDCs are relied upon to authenticate a principal.
    The transited field in the ticket identifies which KDCs were involved
    in the authentication process and an application server would normally
    check this field.  If any of these are untrusted to authenticate the
    indicated client principal (probably determined by a realm-based
    policy), the authentication attempt must be rejected.  The presence of
    trusted KDCs in this list does not provide any guarantee; an untrusted
    KDC may have fabricated the list.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ken Raeburn | 14 Aug 2002 00:17
Picon
Favicon

transited realm field updates, section 3.3.3.2

Just fixing a minor inconsistency, where one paragraph implies (by not
noting a special case) that the client's realm would be included when
two paragraphs later we say that it does not.

Ken

--- krbclar3-1.html	2002/08/13 22:09:24	1.1
+++ krbclar3-1.html	2002/08/13 22:15:59
 <at>  <at>  -866,7 +866,8  <at>  <at> 
 the request, subject to the constraints outlined above in the section
 describing the AS exchange.  The realm part of the client's identity
 will be taken from the ticket-granting ticket.  The name of the realm
-that issued the ticket-granting ticket will be added to the transited
+that issued the ticket-granting ticket, if it is not the realm of the
+client principal, will be added to the transited
 field of the ticket to be issued.  This is accomplished by reading the
 transited field from the ticket-granting ticket (which is treated as
 an unordered set of realm names), adding the new realm to the set,
Permalink | Reply | 0 comments |
headers
Martin Rex | 14 Aug 2002 17:41
Picon
Favicon

Re: transited realm description in 2.7

Ken Raeburn wrote:
> 
>     In Kerberos, the application server is ultimately responsible for
>     accepting or rejecting authentication and should check that only
>     suitably trusted KDCs are relied upon to authenticate a principal.
>     The transited field in the ticket identifies which KDCs were involved
>     in the authentication process and an application server would normally
>     check this field.  If any of these are untrusted to authenticate the
>     indicated client principal (probably determined by a realm-based
>     policy), the authentication attempt must be rejected.  The presence of
>     trusted KDCs in this list does not provide any guarantee; an untrusted
>     KDC may have fabricated the list.

I know that interrealm trust and transited fields are a longstanding
Kerberos protocol feature, but for Kerberos implementations that
offer GSS-API to application services this simply doesn't apply.

GSS-API-based application servers are ultimately unable to check
transited fields.  This should be mentioned here one might think
about adding implementation guidelines around this feature into
the next rev of the Kerberos 5 gssapi mechanism...

> 
>     While the end server ultimately decides whether
>     authentication is valid, the KDC for the end server's realm may apply
>     a realm specific policy for validating the transited field and
>     accepting credentials for cross-realm authentication.  When the KDC
>     applies such checks and accepts such cross-realm authentication it
>     will set the TRANSITED-POLICY-CHECKED flag in the service tickets it
>     issues based on the cross-realm TGT.  A client may request that the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Raeburn | 14 Aug 2002 19:59
Picon
Favicon

Re: transited realm description in 2.7

Martin Rex <martin.rex <at> sap.com> writes:
> I know that interrealm trust and transited fields are a longstanding
> Kerberos protocol feature, but for Kerberos implementations that
> offer GSS-API to application services this simply doesn't apply.

Sure it does.  "Application" in this context doesn't mean only the
GSSAPI application code, it includes the GSS krb5 mechanism itself,
and supporting configuration information (e.g., where's your keytab
file stored? where are your credentials stored?).

> Having the local realm's KDC verify transited fields (and optionally
> apply fancy policies) looks like the only option for (protecting)
> GSS-API based services.

Perhaps the configuration information will say that the KDC must have
set the T-P-C flag for cross-realm credentials to be trusted.  Perhaps
not.

Ken
Permalink | Reply | 0 comments |
headers
Ken Raeburn | 14 Aug 2002 20:24
Picon
Favicon

Re: KRB-WG 54th IETF Meeting Minutes

"Douglas E. Engert" <deengert <at> anl.gov> writes:

>    We will
>    likely hold an interim meeting between now and the Atlanta IETF to
>    resolve any remaining issues on clarifications and continue
>    progress on the Kerberos extensions document.  The date and venue of
>    such an interim meeting will be discussed and announced to the
>    working group mailing list.

So, what's going on with this?  I've heard nothing about it except
this announcement.

An update on the crypto draft:

I've been talking off and on with some people (mostly MIT and
Microsoft) about AES, and the possibility of using CBC mode with
ciphertext stealing for AES, what crypto draft changes might be
helpful, would it be compliant with NIST recommendations, etc.  Some
small changes to the proposed "simplified profile" in the crypto draft
will allow using CBC+CTS without having to define a complete new
profile.  I hope to get new drafts out soon.

The Microsoft folks and I have been thinking about AES for GSSAPI, but
we haven't talked much about it in a while (mostly my fault, busy with
other things), and I'm not even sure if we're both thinking along the
same lines.  I haven't had much chance to write up my ideas.

Ken
(Continue reading)

Permalink | Reply | 9 comments |
headers
Clifford Neuman | 14 Aug 2002 22:16
Picon
Favicon

Re: Proposed Interim krb-wg meeting

I think that we should hold another interim meeting.  MIT is OK with
me if more of the people are in/near that location.  I would think
sometime around mid to later September would be best, possibly early
October. I think two days is about right.

Cliff
Permalink | Reply | 0 comments |
headers
Douglas E. Engert | 14 Aug 2002 22:13
Favicon

Proposed Interim krb-wg meeting

Cliff,
You proposed an meeting of the krb-wg before Atlanta (November 17-21) to edit the 
Clarifications. 

If we have a meeting, we should hold it such that we could edit Clarifications
and submit a draft, so it was available for Atlanta. This means the meeting must be
done by about November 1.

Some questions to the WG:

  o Do we need an interim meeting? (We only seem to get things done when pushed,
    a meeting would push the WG to get moving.) 

  o Should other WG business be discussed? Extensions? (I would like to keep the meeting
    focused on editing the Clarifications with discussions of extensions as required 
    for the Clarifications. This would also keep us focused with a smaller group, as 
    only those involved with Clarifications would need attend.) 

  o Who would attend? (I believe that Cliff, Sam, Ken and Tom need to be present.)

  o Where? ISI, or MIT are possibilities. (If at MIT 3 of the 4 above are already
    there. Cliff, is that a problem? We could even have it at ANL outside Chicago.) 

  o When and how long? Any good dates?  Some time in October, for two days?       

Ken Raeburn wrote:
> 
> "Douglas E. Engert" <deengert <at> anl.gov> writes:
> 
> >    We will
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sam Hartman | 14 Aug 2002 22:22
Picon
Favicon

Re: Proposed Interim krb-wg meeting

>>>>> "Douglas" == Douglas E Engert <deengert <at> anl.gov> writes:

    Douglas>   o Should other WG business be discussed? Extensions? (I
    Douglas> would like to keep the meeting focused on editing the
    Douglas> Clarifications with discussions of extensions as required
    Douglas> for the Clarifications. This would also keep us focused
    Douglas> with a smaller group, as only those involved with
    Douglas> Clarifications would need attend.)

I am hard-pressed to find enough open issues with clarifications to
have this meeting; perhaps I just don't know.  If we need a meeting to
motivate ourselves, at least one other item should be on the agenda.
If you don't want extensions on the agenda, then please consider one
of the following:

* What we're doing about dictionary attacks and preauth

* PKCross in a non-extensions world

Thanks,

--Sam
Permalink | Reply | 1 comment |

Gmane