RE: draft-ietf-rap-rsvp-authsession documents

Bert, Steve, Eric, All,

Sorry for the late response. I just came back from an overseas meeting and 
the other co-authors were on vacation.
Please see my comments/questions below.

Cheers,
Louis-Nicolas

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: Monday, August 05, 2002 7:11 AM
> To: Rap-wg (E-mail)
> Subject: RE: draft-ietf-rap-rsvp-authsession documents
> 
> 
> OK, w.r.t. documents:
> 
>      draft-ietf-rap-rsvp-authsession-03.txt
>      draft-ietf-rap-session-auth-04.txt
> 
> it seems that the list of security related issues
> that I posted over a week ago now are the most serious
> items to address. Here are 2 more issues to take into
> account when you re-edit the docs:
> 
> - When you talk about:
> 
>       5  UNICODE_DN   X.500 Distinguished name as defined
>                       in RFC-2253 as a UNICODE string.
> 
>   we assume you mean a UTF-8 string?
>   Might be good to make that clear.

YES - That's what RFC-2253 specifies...I can clarify this in the draft.

> 
> - The replay protection that was added to rsvp-auth depends 
>   on some clock synchronization (when there isn't a policy
>   server). It would be good to specify that this requires
>   that the system be using NTP or GPS.

No problem. We specified NTP...I will make this clear also.

> 
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > Sent: vrijdag 26 juli 2002 22:59
> > To: Rap-wg (E-mail)
> > Cc: Steve Bellovin (E-mail); Eric Rescorla (E-mail)
> > Subject: FW: draft-ietf-rap-rsvp-authsession documents
> > 
> > 
> > Authors/WG, 
> > 
> > The documents 
> >     draft-ietf-rap-rsvp-authsession-03.txt
> >     draft-ietf-rap-session-auth-04.txt
> > were on the IESG agenda yesterday. 
> > 
> > I still have to collect some more feedback, so the below is 
> > incomplete.
> > 
> > But the security issues are the most serious concern, so here it is
> > for your response and corrections. I have added Steve Bellovin and
> > Eric Rescorla on the cc: list, so that when you respond, they can
> > also see the responses and react immediately/directly. 
> Steve and Eric
> > (as you can see below) have worked on the comments together.
> > 
> > Here we go:
> > 
> > --- comment from Steve
> > 
> > The new version is a lot better, and goes a long way towards 
> > resolving 
> > my objections.  But I don't think it specifies the authentication 
> > process clearly enough for people to implement from the spec. 
> >  I suspect
> > we can resolve this by email in the next couple of days.

I agree. Once we agree on the changes, I will provide an updated version.
Hopefully,
we can resolve all issues this week.

> > 
> > For shared secret and Kerberos, I *think* that the intent is 
> > the key is 
> > used only for an HMAC or similar algorithm such as a CBC-MAC.  That 
> > should be stated explicitly.  It should also state that the 
> expected 
> > length of the authentication data is a preconfigured parameter, and 
> > MUST match the data length in the message.  (There's an 
> attack if the 
> > data length is taken from the message; details are left as an 
> > exercise 
> > for the reader.)  
> > 
> > Be more explicit about what HMAC-MD5-96 means -- I don't 
> believe that 
> > that string is defined in 2104.  Why truncate to 96 bits? 

I simply followed what was specified in the COPS RFC (rfc 2748 SECTION
2.2.16) to encourage
re-use of what has been specified already. But, as you suggest in the text
below,
I am fine with 16 bytes.
 
> > It's secure 
> > -- but it's done in IPsec because of boundary alignment 
> > considerations.
> > 
> > Anyway -- the text should say something like this:
> > 
> > 
> > 	If AUTH_ENT_ID is of types AUTH_ENT_ID IPV4_ADDR, IPV6_ADDR,
> > 	FQDN, ASCII_DN, UNICODE_DN or URI, the receiver should use
> > 	the identity to consult a table keyed by that identity.  The
> > 	table should identify the cryptographic authentication algorithm
> > 	to be used and the expected length of the authentication data.
> > 	At a minimum, all implementations must support HMAC [RFC2104]
> > 	using the MD5 [RFC1321] hash algorithm with an output length of
> > 	16 bytes.  New algorithms may be added by the IETF standards
> > 	process.
> > 
> > 	If AUTH_ENT_ID is of type KRB_PRINCIPAL, a similar algorithm
> > 	table is consulted.  In this case, however, the key is taken
> > 	from the Kerberos ticket.  At a minimum, all implementations
> > 	must support the same HMAC hash described above.
> > 
> > 	Authentication is done as follows.  The entire message is
> > 	constructed, excluding the length, type, and subtype fields
> > 	of the AUTH DATA field.  Note that the message MUST include
> > 	either a START_TIME or a SESSION_ID (See Section 9), to prevent
> > 	replay attacks.  The output of the authentication algorithm,
> > 	plus appropriate header information, is appended to the message.
> > 
> > 	Verification is done by a similar process; however, the receiver
> > 	MUST verify that the indicated length of the authentication data
> > 	is consistent with the configured table entry.
> > 

This text does clarify. I will input it your suggested text into the
appropriate sections of the next revision.


> > 
> > Much more needs to be said about generating signatures to 
> be verified 
> > via an X.509 certificate.  I'm not 100% certain which RFCs 
> need to be 
> > cited -- ekr or jis, can you fill in some details? -- but 
> > they probably 
> > include PKCS 1 and 7 (published as RFCs -- btw, there is an 
> obsolete 
> > RFC cited for PKIX).  I frankly don't recall if the preferred hash 
> > algorithm is in the X.509 certificate, though the public key 
> > algorithm 
> > used is implicit in the key type in the cert.  Similar 
> > concerns apply to
> > PGP_CERT, but I don't even know what to cite for it.
PGP_CERT: Maybe Eric can help out here also? If not, I will dig deeper into
this and provide the references and needed text.

> > 
> > --- here comes a response to the above from Eric
> > 
> > I agree that this is unsatisfactory, on several fronts:
> > (1) It only appears to be possible to pass a single certificate.
> > What about certificate chains?

We should support certificate chains. We define it as follows:
8  X509_V3_CERT        A chain of authorizing entity's X.509 V3  
                             digital certificates.

I can simply state this also in section 4.3 and reference
the appropriate RFCs (see comment below). 

> > (2) It doesn't actually SAY that a signature is what is present 
> > in the authentication data field, though I suppose we're supposed
> > to intuit that.
I though this was sort of straightforward. I can add a sentence specifying
that
a signature is present.

> > (3) It doesn't specify the digest algorithm.
> > 
> > In answer to your questions:
> > (1) It's necessary to reference PKCS-1 [RFC 2437] since 
> that describes
> > how to perform RSA signatures. (I'm assuming that they want to use
> > PKCS-1 rather than PSS or some other newfangled RSA padding
> > If DSS is to permitted they should also reference FIPS 186-2.

Will add a reference to RFC 2437.

> > 
> > (2) It's not necessary to reference PKCS-7 unless you're using
> > it as a certificate chain container. (See my comment about
> > chains above).

Yes, should be supported. Will add a reference to PKCS-7.

> > 
> > (3) In general, X.509v3 certificates do not carry preferred digest 
> > indicators. Either the digest name should be manually configured
> > or contained in the message. While it's technically possible
> > to discover what digest was used from the signature (it's in the
> > DigestInfo), generally APIs and hardware assume that you already
> > know. 

We would prefer to have this contained in the message. How should I specify
this?
Should I simply state that the preferred digest name is contained in the
certificate?
What do other applications using X.509v3 certificates specify?

> > 
> > 
> > Further more:
> > 
> > (1) Section 4.1 talks about "shared private keys". This is confusing
> > since "private key" is generally used to refer to the 
> private half of
> > an asymmetric key pair. I think this would be clearer if it talked
> > about "shared symmetric keys".

Agreed. Will make the change.

> > 
> > (2) The Kerberos authentication mechanism doesn't appear to contain
> > authentication data but instead merely the principal name. The text
> > here suggests that the authentication is interactive:
> > 
> >       An authorizing entity is configured to construct the 
> > AUTH_SESSION 
> >    policy element that designates use of the Kerberos 
> authentication 
> >    method (KRB_PRINCIPAL).  Upon reception of the RSVP request, the 
> >    router/PDP contacts the local KDC to request a ticket for the 
> >    authorizing entity (principal@realm). The router/PDP uses 
> > the ticket 
> >    to access the authorizing entity and obtain authentication 
> > data for 
> >    the message. 
> > 
> > That seems unusual. Wouldn't you want the authorizing 
> entity to send a
> > ticket, thus avoiding a round trip? Is the problem that the
> > authorizing entity can't guess the principal name of the router/PDP?
> > If so, how does he know it's right when the router/PDP asks for
> > authorization? What are the contents of the "authentication 
> data" that
> > the router/PDP obtains? This all seems quite hairy and 
> underspecified.

This is explained in section 9:
"If shared private keys are not a valid option, the Kerberos 
   authentication mechanism is reasonably well secured and efficient in 
   terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain 
   the principal@realm name of the authorizing entity. This is much 
   more efficient than the PKI authentication option. "
Does that answer your questions? Basically, since only the principal@realm
name is needed
the AUTH_SESSION is smaller in size (as compared to if it contained the
kerberos ticket). 




> > 
> > 
> 
>